Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp3388807ybd; Fri, 28 Jun 2019 07:48:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqzGNkyskXUr29zESvssTltQVLMO9c5ZXiNvEQvosUzIhskQboa0Adu7iNaVR2Iu8OxiYDPX X-Received: by 2002:a17:90a:bf0e:: with SMTP id c14mr12994662pjs.55.1561733338828; Fri, 28 Jun 2019 07:48:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561733338; cv=none; d=google.com; s=arc-20160816; b=ED9L9bc0L+XQm9wdcwdHwVMA1HwyGJeUdfIOnMWGXbUVqHXUMX5EmN2/nssUfUQyqq /frhOCUA9GTKHrxJIUkioRVDGpG+lVccuHZDs5YosUTwl3CIcbTjxskLHlY5KOzzxkhe h2uHHaRcUJHGaB9JvrR/5pr45mlAMkMS/bz6+7djdABW69urDaEDyeoaZ7NidKQnEtUn WXx6TnLKH8l7q+adlq6kPFW4ZvGi6XbFdZX2EYFvd8zSb9vGJ0bXzaAhhJdIWdKrwc/a XRqNsA3VBzwmqCfwWfSIZASLv8b1FJNO/TJrOdsaLZVvXy3JDtgKZIX/kZt/Ha6a1rmG 27Wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=4+9BQ/9qN/HEB5jYhHOcTVXcrlmUmZtAOZVfYv7/QOA=; b=NCPfm/B0tpgNlx1FsRmRDzMNYrsT+v8YAfNFP1QSGTMOpUx5Z4c1VyfkqvZXiO5R4N 5dU0jL8z7MD5LldfHZsNmXj49jV9cwwrtt8D36Q82lDuxGXV65Zf/UOajashtJIu+1+b OVNPJK0v239QDP9Bva+ECD0BloUtAnwQS+3nIltz6jusQ9lj8w57by2/8mnU8Uoc2auN jkdCGLwg/nO6A6SYcTJJWHoUSOS9af2/JlAaJ/X60g9+Pu9bwMqTFk7PBKF2L5pPcq7C dCpdTtkIATHIqragCuGrIpGxu/eBTpgzk12Pixqd4nng46BHHR4C23NP8KJboV/Incsp Jh5Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ofGc0v9h; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w185si2706662pfb.170.2019.06.28.07.48.42; Fri, 28 Jun 2019 07:48:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ofGc0v9h; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726860AbfF1Osg (ORCPT + 99 others); Fri, 28 Jun 2019 10:48:36 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:42957 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726785AbfF1Osf (ORCPT ); Fri, 28 Jun 2019 10:48:35 -0400 Received: by mail-pf1-f194.google.com with SMTP id q10so3094435pff.9 for ; Fri, 28 Jun 2019 07:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=4+9BQ/9qN/HEB5jYhHOcTVXcrlmUmZtAOZVfYv7/QOA=; b=ofGc0v9hZZwUxfhb5r0SX5BCHeOcj3Ym+G17847226BPeApHLQt5lHVJGZPjPCl6mJ R9yEA1WaiRHbrYKbycxmjkd9zcIuG73DJH0UQtlrraeon+eWgyD9ND/T5MTW0MQaCyTR T/8ILMD0OYRqTF/FvjRgFsB3BtZtKPQ5aqUdQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=4+9BQ/9qN/HEB5jYhHOcTVXcrlmUmZtAOZVfYv7/QOA=; b=t4LfAfKNQqhstwmCvcpwXU/fFs+eRaPlV08lJ8U0m2ZK+5Lm5zM9kRLYxfFXdoRQEG T3Ya+iqFjYi/etWGgkZYd8hCDBqC2UY1IDBQvCSJUueKLiKhd14k3MDJH2dWt8Ifgidz SmXvtXT/RO7tQIPC+akJkoNidDlira5jTw0SANv8UfD6MJqkwAqKtdVuENVkdV8ysUy/ dgeL9s4ft+fig/LKpryngFCMtmj0ElYRm/f9I4w4pGIKre5WCi5XJYmy4DV6Iw1FYFlL lge1dHsEzvi4tZyJt4PzZpCFqAPKxgjiVPk1wsRH9zyh5A+W1KtdFdOHjAKGOZWiNb4n wHWw== X-Gm-Message-State: APjAAAUZyAEnf2/ASWaqUK1my10IhSQ6LoxFvReh0q80A/RvH9kE855F 4FlF9nC8C9pocsuoHFe+LoHqcw== X-Received: by 2002:a17:90a:29c5:: with SMTP id h63mr13123809pjd.83.1561733315036; Fri, 28 Jun 2019 07:48:35 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id b11sm2896176pfd.18.2019.06.28.07.48.33 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 28 Jun 2019 07:48:33 -0700 (PDT) Date: Fri, 28 Jun 2019 07:48:33 -0700 From: Kees Cook To: Arnd Bergmann Cc: James Morris , "Serge E. Hallyn" , James Smart , Dick Kennedy , "James E . J . Bottomley" , "Martin K . Petersen" , Larry Finger , Florian Schilhabel , Greg Kroah-Hartman , "David S . Miller" , Wensong Zhang , Simon Horman , Julian Anastasov , Pablo Neira Ayuso , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org, netdev@vger.kernel.org, lvs-devel@vger.kernel.org, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, Ard Biesheuvel , Masahiro Yamada , Alexander Potapenko , Andrew Morton , Michal Hocko , Thomas Gleixner , linux-security-module@vger.kernel.org Subject: Re: [PATCH 1/4] [v2] structleak: disable STRUCTLEAK_BYREF in combination with KASAN_STACK Message-ID: <201906280748.910641F1DD@keescook> References: <20190628123819.2785504-1-arnd@arndb.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190628123819.2785504-1-arnd@arndb.de> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 28, 2019 at 02:37:46PM +0200, Arnd Bergmann wrote: > The combination of KASAN_STACK and GCC_PLUGIN_STRUCTLEAK_BYREF > leads to much larger kernel stack usage, as seen from the warnings > about functions that now exceed the 2048 byte limit: > > drivers/media/i2c/tvp5150.c:253:1: error: the frame size of 3936 bytes is larger than 2048 bytes > drivers/media/tuners/r820t.c:1327:1: error: the frame size of 2816 bytes is larger than 2048 bytes > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16552:1: error: the frame size of 3144 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] > fs/ocfs2/aops.c:1892:1: error: the frame size of 2088 bytes is larger than 2048 bytes > fs/ocfs2/dlm/dlmrecovery.c:737:1: error: the frame size of 2088 bytes is larger than 2048 bytes > fs/ocfs2/namei.c:1677:1: error: the frame size of 2584 bytes is larger than 2048 bytes > fs/ocfs2/super.c:1186:1: error: the frame size of 2640 bytes is larger than 2048 bytes > fs/ocfs2/xattr.c:3678:1: error: the frame size of 2176 bytes is larger than 2048 bytes > net/bluetooth/l2cap_core.c:7056:1: error: the frame size of 2144 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] > net/bluetooth/l2cap_core.c: In function 'l2cap_recv_frame': > net/bridge/br_netlink.c:1505:1: error: the frame size of 2448 bytes is larger than 2048 bytes > net/ieee802154/nl802154.c:548:1: error: the frame size of 2232 bytes is larger than 2048 bytes > net/wireless/nl80211.c:1726:1: error: the frame size of 2224 bytes is larger than 2048 bytes > net/wireless/nl80211.c:2357:1: error: the frame size of 4584 bytes is larger than 2048 bytes > net/wireless/nl80211.c:5108:1: error: the frame size of 2760 bytes is larger than 2048 bytes > net/wireless/nl80211.c:6472:1: error: the frame size of 2112 bytes is larger than 2048 bytes > > The structleak plugin was previously disabled for CONFIG_COMPILE_TEST, > but meant we missed some bugs, so this time we should address them. > > The frame size warnings are distracting, and risking a kernel stack > overflow is generally not beneficial to performance, so it may be best > to disallow that particular combination. This can be done by turning > off either one. I picked the dependency in GCC_PLUGIN_STRUCTLEAK_BYREF > and GCC_PLUGIN_STRUCTLEAK_BYREF_ALL, as this option is designed to > make uninitialized stack usage less harmful when enabled on its own, > but it also prevents KASAN from detecting those cases in which it was > in fact needed. > > KASAN_STACK is currently implied by KASAN on gcc, but could be made a > user selectable option if we want to allow combining (non-stack) KASAN > with GCC_PLUGIN_STRUCTLEAK_BYREF. > > Note that it would be possible to specifically address the files that > print the warning, but presumably the overall stack usage is still > significantly higher than in other configurations, so this would not > address the full problem. > > I could not test this with CONFIG_INIT_STACK_ALL, which may or may not > suffer from a similar problem. > > Fixes: 81a56f6dcd20 ("gcc-plugins: structleak: Generalize to all variable types") > Signed-off-by: Arnd Bergmann Acked-by: Kees Cook -Kees > --- > [v2] do it for both GCC_PLUGIN_STRUCTLEAK_BYREF and GCC_PLUGIN_STRUCTLEAK_BYREF_ALL. > --- > security/Kconfig.hardening | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening > index a1ffe2eb4d5f..af4c979b38ee 100644 > --- a/security/Kconfig.hardening > +++ b/security/Kconfig.hardening > @@ -61,6 +61,7 @@ choice > config GCC_PLUGIN_STRUCTLEAK_BYREF > bool "zero-init structs passed by reference (strong)" > depends on GCC_PLUGINS > + depends on !(KASAN && KASAN_STACK=1) > select GCC_PLUGIN_STRUCTLEAK > help > Zero-initialize any structures on the stack that may > @@ -70,9 +71,15 @@ choice > exposures, like CVE-2017-1000410: > https://git.kernel.org/linus/06e7e776ca4d3654 > > + As a side-effect, this keeps a lot of variables on the > + stack that can otherwise be optimized out, so combining > + this with CONFIG_KASAN_STACK can lead to a stack overflow > + and is disallowed. > + > config GCC_PLUGIN_STRUCTLEAK_BYREF_ALL > bool "zero-init anything passed by reference (very strong)" > depends on GCC_PLUGINS > + depends on !(KASAN && KASAN_STACK=1) > select GCC_PLUGIN_STRUCTLEAK > help > Zero-initialize any stack variables that may be passed > -- > 2.20.0 > -- Kees Cook