From patchwork Fri Jun 28 12:37:46 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 168075 Delivered-To: patch@linaro.org Received: by 2002:a92:4782:0:0:0:0:0 with SMTP id e2csp3649178ilk; Fri, 28 Jun 2019 05:39:39 -0700 (PDT) X-Google-Smtp-Source: APXvYqx+z6MHbh4PCfcXh6bNzNWV3qNHjecEv3i1Uz+/omyxRotST6qH7un/e5oV/rss7JheGlAx X-Received: by 2002:a17:902:968c:: with SMTP id n12mr11942799plp.59.1561725578994; Fri, 28 Jun 2019 05:39:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561725578; cv=none; d=google.com; s=arc-20160816; b=tboJ1/3fHNLJwt6X4tARu26O8n5uysal/cKz++j4YlCushwSDdilxhujY3RmJSM0as KJMoIiC+WvwenkS8Mbk6ujvVYO+k+84hbNApMhkCPSaEtUaK6iuKN5KyfUZ0CzU2r0Jc 4qnNKc2wpsQLrKaDnno9KU9MR4ra5GkD5l6wxzRTqcdBwkEDZDK4ck7+UM8Xu8KOpt9z RfZlKOLP9EerJ2NZ6FzOWDH5FucketqAUVXX3rSssYN0iMFMWnFp2v/JRaQ7zZQOCTsZ 0IFvyixv8AYWrFZIfFfil6VJs3ObPpfPq6hLPDm/ukiBQZ0es5OHKzkEpimv/A3cMqcZ Uh9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=nff3XZWiPJ+iGq+oeWxQOPy25dfAmAdQcpKfoOitJoU=; b=rc/jzQN74ISvpYBN0ekpKc7uXsejY9oE0S4R9CTNoqulh2sAZ63xJieeqLWlpPalbz RS9ejdzDx5UBeDqigOdmnexiOE6iHqTqH7ixJmQXzoCWAfo3W8JnNublchDYRk+krAcz d4M+CrLPxy9arm5m8u84gJPu2toeIQFU0SKq9phegzNeUDrzqf5MuM+WeX0D2r2NpBCv ykFxe59YEBTdAQ2zSo8eJlqXR0A7+8inpRa3aPXuTrdnjazlIIvzkOPQ5PcQJu2sTJsP /aHSkQPgB8HHZzCbVGxKecq1eZT/KkRdh70oDtNPwTW/ujPE3POvUwVRGCHW2/DiaY21 lt3A== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h1si2085141pld.439.2019.06.28.05.39.38; Fri, 28 Jun 2019 05:39:38 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727084AbfF1Mjh (ORCPT + 30 others); Fri, 28 Jun 2019 08:39:37 -0400 Received: from mout.kundenserver.de ([217.72.192.75]:58439 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726675AbfF1Mjg (ORCPT ); Fri, 28 Jun 2019 08:39:36 -0400 Received: from threadripper.lan ([149.172.19.189]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.145]) with ESMTPA (Nemesis) id 1MSbp1-1i9oCT1Vaz-00Syc4; Fri, 28 Jun 2019 14:38:36 +0200 From: Arnd Bergmann To: Kees Cook , James Morris , "Serge E. Hallyn" Cc: 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 , Arnd Bergmann , Masahiro Yamada , Alexander Potapenko , Andrew Morton , Michal Hocko , Thomas Gleixner , linux-security-module@vger.kernel.org Subject: [PATCH 1/4] [v2] structleak: disable STRUCTLEAK_BYREF in combination with KASAN_STACK Date: Fri, 28 Jun 2019 14:37:46 +0200 Message-Id: <20190628123819.2785504-1-arnd@arndb.de> X-Mailer: git-send-email 2.20.0 MIME-Version: 1.0 X-Provags-ID: V03:K1:Vyv7hDWAtsub/JNqLOHsg4FkzINNTOEYL230tDKN/RItqenQapP gyiBCpoLRRoTqs8Tv2p30vIpq0szU20cz8WHVZAjO+wDA1cj9+wZTfO8K4w5U23pnLNweti UywkJH8BUfN6F1OQXF9XsDDZcZtuJH4mRwHl7vS8Crfb6pptLcNlGI4ZF0Y6qEGx/xprLOw 3JJuBgcheAN7frqGyD/ng== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1; V03:K0:hCq8JItJh8A=:onuXm76BFuVcDFqRETOYkg MtmPnl8+G4vcDKCWOcOBqIwlOGi23HDTrEy1N2iM59a8glWED6at9+xN5y070TSqE0F74f5Bp SG6oYbbB8UDm3jlsYCu4oElgMn80THtjNnFdcKdCHyaBlaVtvkU7NCXkVh4O/2jppR3D8tSbB NhDDlCDWofUbrSnIF7sbuz/JZwrrOo30UDP6JD6l+8gLfCwjR9RBtMUh76ESFfy9vUGaqlpI2 x5QNSlqT2uFQ8CtPKhaBorUssjMKG1C3Jzz1ivMBDLDCkEKN3/rJ16yRUjtNVoKzVJCFy9/vM Njg89iGc2HhaQR9EElUOXKdNypG2lkuoixugjYhI+FEsRi6J6jPqAgL/GsRD+wj5NYVan393T x/OJDB1MtoCErAkNCeQtN+S4UZlTsGP/neFdqAG/RcsdcjktiPUZhw9PWKzHHOZ17Erp1lF+K HHIuvo3LVNWSCKk2Db2RWCYWSroITpsS5zUZMvNj0yC/Cmurp81cwCXsVe6RzlNoBKUkqtnau t6uOPEhloDMMgxKksXBitbTPaG4vSVZnHSLStJRfV67Xk+LtyIHrrvU+5Koezdsypn457AiF4 8GnQKZWviq2xLyRkSPaTL2o5G9ohCYKa6AwRDJpsMLVj30s09byWPoS+7O8pdcH4N2CbOLlag XOaT19Ih6zHEsveSXAncAy+o55MhMno3iNzFdCME5MQ9sQOSBSTXNdD9W9fUEzNCrw83/TIFK 4Pu9RqEacN2PYZhmmiTscWmrBRdsNgqikx+SQA== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- [v2] do it for both GCC_PLUGIN_STRUCTLEAK_BYREF and GCC_PLUGIN_STRUCTLEAK_BYREF_ALL. --- security/Kconfig.hardening | 7 +++++++ 1 file changed, 7 insertions(+) -- 2.20.0 Acked-by: Kees Cook 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 From patchwork Fri Jun 28 12:37:47 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 168076 Delivered-To: patch@linaro.org Received: by 2002:a92:4782:0:0:0:0:0 with SMTP id e2csp3649695ilk; Fri, 28 Jun 2019 05:40:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqwRhgVep/bXQJpvZIBvBF9mP8soz29grqOqoL+dZIn90InkiqcF5EeLIXYeLopQD+bd6oOq X-Received: by 2002:a63:5656:: with SMTP id g22mr9420083pgm.280.1561725606197; Fri, 28 Jun 2019 05:40:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561725606; cv=none; d=google.com; s=arc-20160816; b=VxVMCG8MsT/Hat157DluadWrBAeSQmPLnmVc1RmbvTd3vsbihrdQDHPu5btKdjnhau wlMB70SzmkqgVdW8FKIaImHYoCURFSFhJ/zka1I8ab5j1rAcdSR/6ofUFKQB9pDt+cyt hnUwZRIkqnx7U5B71XsQZcNjPR7H89Ar7h3n+mrVsSSPUkBf65XervTYq+DAT5K9sN7/ qS0WlY18h2+kBKS97AecsJtkGoYEPjwsJnjJag4t3eNQdFx+9Pf5gEKeSu1Wd++P17kw 6csy3xKOhH+i4Q1xEG1ErKrWPgBNveGig20LfSNxLxiWWvtQe1YhFWlQzu4ZJzvFLvan ugzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=sliLDlf4LDTH55cjmJACsoKpJ97ma1HQjTXk0RzTObk=; b=0V6Srw6Rhq5U22WwNzI+I2TYFPd91w/BMadSEAUcOMYOfwrXgjzCTQOYfxtX+81/dL Y5eG/xrgbYmeYBr+oiH/2NlbHDDy7yrv7DoLdmVXqtZZ3YgpeEtRJfRFJu1saivxWzFj 8duiNbjLElLi0olXWyQzTHRU04tpysRw/N6f7pcm9vMNcOhAMH9joaQqgCzkaHuGgFDF U03CGLojpQ+Jr5GrMEKTJ4EROgAJUMYTun+GcPFrVc3oZqN8ufCpGfCznQQiYwFsmAg/ SqDhNw+oEEQWetFCdFKoxBB+uyOX5rO6rl+9o3w1MrebMW9GGtZmdl1GY8poh3icKueW Hklg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z25si1984572pgk.415.2019.06.28.05.40.05; Fri, 28 Jun 2019 05:40:06 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727190AbfF1MkE (ORCPT + 30 others); Fri, 28 Jun 2019 08:40:04 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:48763 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726657AbfF1MkE (ORCPT ); Fri, 28 Jun 2019 08:40:04 -0400 Received: from threadripper.lan ([149.172.19.189]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.145]) with ESMTPA (Nemesis) id 1MDyoU-1hoZvO22oG-009wgv; Fri, 28 Jun 2019 14:38:46 +0200 From: Arnd Bergmann To: Kees Cook , James Smart , Dick Kennedy , "James E.J. Bottomley" , "Martin K. Petersen" Cc: Larry Finger , Florian Schilhabel , Greg Kroah-Hartman , "David S . Miller" , Wensong Zhang , Simon Horman , Julian Anastasov , Pablo Neira Ayuso , James Morris , 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 , Arnd Bergmann , Hannes Reinecke , Willy Tarreau , Silvio Cesare Subject: [PATCH 2/4] lpfc: reduce stack size with CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE Date: Fri, 28 Jun 2019 14:37:47 +0200 Message-Id: <20190628123819.2785504-2-arnd@arndb.de> X-Mailer: git-send-email 2.20.0 In-Reply-To: <20190628123819.2785504-1-arnd@arndb.de> References: <20190628123819.2785504-1-arnd@arndb.de> MIME-Version: 1.0 X-Provags-ID: V03:K1:Qw9p6hkVU7HnncabkXeSvgIHyGWrL89skKuFPCZp3XZbO0Z/qwl 1txNbL56ftqBS+LSOFslqsBvdmgKMoeVtc5vuNivf1x/Hgk6rdCltSSlwKzmDFARiFbxpMX roYZhrbFZPwCnH+YIDcrmlNv2/P2KB3uedb28TyWkruxxYcA0Q1WSTYI4p6fuQr+G8WWl4m wiD8C2ren7CMMLl/vSCeQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1; V03:K0:9p1MTuBuyDk=:YXzyCRUwn7APpAve3hKlPe nHF/oYpPvH043PpJDzBpYbX2thxZmSSswnsnQpSbKxZE0R21NYvE9cirR5tNGpYsMPnG7Bmqf NEJC8eMuHqYBXCdLHZaYKx4R+OcBtChRxmBPINgjkDR1Ukgntc1i1KRu2vK7It9BjLl9hTxE3 VW3wpunjSw68XQygDWLce0WU5vqFUynqGlJoQU/ZWFmrLgfkcQ/VkReLIPd6ftdq/F/2GXDwH QJyQKqHBt8OV+QmK9Hf9nWZNKA5/hqg/HXgaaFuYtm8xOiyxOPzYrdc84CmTQv5orBgkpMDq2 Rr7+PRFtp4CpCfi5obaWPlYtNxM5HKOPiPsv73te1dzJ1rUXKahVqHWVvvfD83y/c7+u4VDS9 5c091tcVi4cTXpP5grNjAI5gI32I9XsT4rs5/NwyIocG855f58pbttER2oGEG08eNP0+/kEeE 0YYB4yBmdBwCD+9fUMV4BPOLb9EbfqVgXVcacGY0GxgkcJqyFzAq2xpZQAyWVKfKiSxhTGnO5 uUCIJ/XQ8CjIxPLLJRwY0lDEIhwFNwyTm3CRoC+iCykFcwHxHcltBSItZud14OzT4E0YYUPFl 25wylPZDPavUJfd3p6KLltj+UyklBcFquHz5rDz/UyaDjrdeHEdDZwPH7lLD8P7AYmtrKBhA5 2qiLUdYwCVy54dXnj8DB1vY+tMlW7Sx1UVpyEFBTCFalY0iDP2tJOw6N7eRtmRNjFEuG8rK3E yZDWdccDiFt4fe8agM+/UPXd9XeUaSmH7WyzIg== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The lpfc_debug_dump_all_queues() function repeatedly calls into lpfc_debug_dump_qe(), which has a temporary 128 byte buffer. This was fine before the introduction of CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE because each instance could occupy the same stack slot. However, now they each get their own copy, which leads to a huge increase in stack usage as seen from the compiler warning: drivers/scsi/lpfc/lpfc_debugfs.c: In function 'lpfc_debug_dump_all_queues': drivers/scsi/lpfc/lpfc_debugfs.c:6474:1: error: the frame size of 1712 bytes is larger than 100 bytes [-Werror=frame-larger-than=] Avoid this by not marking lpfc_debug_dump_qe() as inline so the compiler can choose to emit a static version of this function when it's needed or otherwise silently drop it. As an added benefit, not inlining multiple copies of this function means we save several kilobytes of .text section, reducing the file size from 47kb to 43. It is somewhat unusual to have a function that is static but not inline in a header file, but this does not cause problems here because it is only used by other inline functions. It would however seem reasonable to move all the lpfc_debug_dump_* functions into lpfc_debugfs.c and not mark them inline as a later cleanup. Fixes: 81a56f6dcd20 ("gcc-plugins: structleak: Generalize to all variable types") Signed-off-by: Arnd Bergmann --- drivers/scsi/lpfc/lpfc_debugfs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.20.0 Reviewed-by: James Smart diff --git a/drivers/scsi/lpfc/lpfc_debugfs.h b/drivers/scsi/lpfc/lpfc_debugfs.h index 2322ddb085c0..34070874616d 100644 --- a/drivers/scsi/lpfc/lpfc_debugfs.h +++ b/drivers/scsi/lpfc/lpfc_debugfs.h @@ -330,7 +330,7 @@ enum { * This function dumps an entry indexed by @idx from a queue specified by the * queue descriptor @q. **/ -static inline void +static void lpfc_debug_dump_qe(struct lpfc_queue *q, uint32_t idx) { char line_buf[LPFC_LBUF_SZ]; From patchwork Fri Jun 28 12:37:49 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 168077 Delivered-To: patch@linaro.org Received: by 2002:a92:4782:0:0:0:0:0 with SMTP id e2csp3650143ilk; Fri, 28 Jun 2019 05:40:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqzmiWc5pb+tNqKtgEvBi7u8am3xp3LNFrYo+DMbpBvtjx9DQRdEQ8PUmoPnxPJxAmcR+M+p X-Received: by 2002:a17:90a:2190:: with SMTP id q16mr12596080pjc.23.1561725632186; Fri, 28 Jun 2019 05:40:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561725632; cv=none; d=google.com; s=arc-20160816; b=wWTmSSjCu+h3n0IM2RqIWuGP480k6p9MA8Sp3UiLZrr1aHNKNncykhIKVSES/ca0kB rmaYsUUeLNozwhMYC4YB7/azbxu6+FBm3xWJW2jZDVMe4Ccjo+3J+nlSy/MWxi7WU1D0 LuHMLG0kRi1bDV3CV9aEN4Zzk8X+OFvrC+9woePJFPEI0r7d10DRnahudDOr2KjkJ0iR RwpoT8uYno2jJQt1xf0B88+is+P/XqzKV+tuZty3GD1A5vZsGgtYpsQ/6ij6FJLzdYOu eXlXyneCRj9q3rHXzVnytSVJJOmacB2+XhfGe9SirNn0jUR5iboazHmmaQKa9ollJ/L/ +rKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=hT9Aj3DGXHLOd4xMERlta8y5CN4HM2DdpRnRMzWJkFg=; b=GkKTreeHJhXi8Q0pa9TsYVPjyGcd3H0klBadqgcJXCjYjQ5gV8muof200kyjXyy2o4 xGVOInkFgXiWwyI9MgEgT0SmNFv/kvPBZeM4tN6Ss/Rg+mp88uwxTgDAZPfrjpEHSiq8 h74peiDKMAc5Kt3xKhwW3UaxLN7Czkg/mMHSIyyi8Xhsk9Uw4olBS2erOMWwBR5/b/pj 8KUUhEHERs1Mei1X36cy9Qxwx2rVLQYmFRxnheSWwZwWWu7jk9Kr2KVTAnteYwiBb39S kEHH3Ng9pSc9Imeb1hl0XFVKivbi+xNITllbJ2ONkSjM5zeWZes4ChfarfmNf5v6S2fI G/nQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i36si1911487pgl.491.2019.06.28.05.40.31; Fri, 28 Jun 2019 05:40:32 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727223AbfF1Mka (ORCPT + 30 others); Fri, 28 Jun 2019 08:40:30 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:39671 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726657AbfF1Mk3 (ORCPT ); Fri, 28 Jun 2019 08:40:29 -0400 Received: from threadripper.lan ([149.172.19.189]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.145]) with ESMTPA (Nemesis) id 1MV6G0-1i5h3x3iFi-00SAKd; Fri, 28 Jun 2019 14:39:28 +0200 From: Arnd Bergmann To: Kees Cook , Wensong Zhang , Simon Horman , Julian Anastasov , "David S. Miller" , Alexey Kuznetsov , Hideaki YOSHIFUJI , Pablo Neira Ayuso , Jozsef Kadlecsik , Florian Westphal Cc: James Smart , Dick Kennedy , "James E . J . Bottomley" , "Martin K . Petersen" , Larry Finger , Florian Schilhabel , Greg Kroah-Hartman , James Morris , 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 , Arnd Bergmann Subject: [PATCH 4/4] ipvs: reduce kernel stack usage Date: Fri, 28 Jun 2019 14:37:49 +0200 Message-Id: <20190628123819.2785504-4-arnd@arndb.de> X-Mailer: git-send-email 2.20.0 In-Reply-To: <20190628123819.2785504-1-arnd@arndb.de> References: <20190628123819.2785504-1-arnd@arndb.de> MIME-Version: 1.0 X-Provags-ID: V03:K1:HCGQWJM/jgYLfWjkaZqUrv2qOxBWq7KQGIVbLhAN9vz4+rQGEsU 1e0OEfxV5X+IxxkESa/8ED8gQbJJZo1mFkHnxx4cuEdIFDG2E6kEU56AXXqllNDwrTx7Yqi rPQt0sWJJxsy/lqIVMY+IjOW7kDLES10VVBg99qKA3iWFFY1Bk9L4yVzcmIqkKZI6W1ghPE yyqN2UtepcKHX4ktJndTA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1; V03:K0:UFQTEIQsdI8=:4JSGSxh9Lq4IgSj6RbZGvw dFcGEbvKr9mbkRrkz56cKH8qN/i/cn7SspmrlOXlaHRNqZ/Ds/WiCiUXhgJGt/cK9A5c3YD7i oHjmFLpmqBSbCmuAWd5nndcufQKSo/Z+8KGa+YIFeZG4I2s6D3cfpNQR3Cov1U9Ni3aUm0uZb JIg0Zlz3z1X098a1zAm3KZ0Ko71tKEkNAbZamovoh/jLWPcD994C83G8iDf+Dta1wHAyRN3qw rSxWNTEYAsrlsmL9oeVbhZvD1Qer3DMh0/GMHwPCPeFhTcxCRLFjNZN1IeupJ/dsRsUHmyjIq GX8kB9g68EykZBIf2YkVRP+gKEYjVyI60WMudiPqV3hHsFiaY23lYQojGI6Uk34cKqjmgZfIg ncK2yWIFM5jeqQ05m7KNm2gaeAtwyqnlSX9Qr6/tqGnyQzdn2vDx+MeQJEwTnvZ8XDKwsNSve ndhLiulAGkKmSxi01Ff4tbjxThCRZdsaYr93bZ2ajCxZDXGE48o4tfsRK3or067qr5RyhYCeM BGTW+9FvvP1oeNNjuLeaUBmSIfrltlp5zBP4CBkvVv/VeqY7R68gaA0eAB5DI8PWCa89CplBL OW53sIBE0YKUXFN1QsL+o5iXlGUBo80cTSZNF4+YjcDlGLajgqLn3ll+Xj6kmI+HhkbrdAc0a FdIOGG520qWOR2RY+0oxwPZ3lgPR/iDfEqCg1g4gICWNnHpAorIYwzv7nNigCNMWnwr8DMdSw QyZdHAipo9ZCGX3CyMxOhlXbJ86PESqFHUSsHQ== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org With the new CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL option, the stack usage in the ipvs debug output grows because each instance of IP_VS_DBG_BUF() now has its own buffer of 160 bytes that add up rather than reusing the stack slots: net/netfilter/ipvs/ip_vs_core.c: In function 'ip_vs_sched_persist': net/netfilter/ipvs/ip_vs_core.c:427:1: error: the frame size of 1052 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] net/netfilter/ipvs/ip_vs_core.c: In function 'ip_vs_new_conn_out': net/netfilter/ipvs/ip_vs_core.c:1231:1: error: the frame size of 1048 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] net/netfilter/ipvs/ip_vs_ftp.c: In function 'ip_vs_ftp_out': net/netfilter/ipvs/ip_vs_ftp.c:397:1: error: the frame size of 1104 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] net/netfilter/ipvs/ip_vs_ftp.c: In function 'ip_vs_ftp_in': net/netfilter/ipvs/ip_vs_ftp.c:555:1: error: the frame size of 1200 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] Since printk() already has a way to print IPv4/IPv6 addresses using the %pIS format string, use that instead, combined with a macro that creates a local sockaddr structure on the stack. These will still add up, but the stack frames are now under 200 bytes. Signed-off-by: Arnd Bergmann --- I'm not sure this actually does what I think it does. Someone needs to verify that we correctly print the addresses here. I've also only added three files that caused the warning messages to be reported. There are still a lot of other instances of IP_VS_DBG_BUF() that could be converted the same way after the basic idea is confirmed. --- include/net/ip_vs.h | 71 +++++++++++++++++++-------------- net/netfilter/ipvs/ip_vs_core.c | 44 ++++++++++---------- net/netfilter/ipvs/ip_vs_ftp.c | 20 +++++----- 3 files changed, 72 insertions(+), 63 deletions(-) -- 2.20.0 diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h index 3759167f91f5..3dfbeef67be6 100644 --- a/include/net/ip_vs.h +++ b/include/net/ip_vs.h @@ -227,6 +227,16 @@ static inline const char *ip_vs_dbg_addr(int af, char *buf, size_t buf_len, sizeof(ip_vs_dbg_buf), addr, \ &ip_vs_dbg_idx) +#define IP_VS_DBG_SOCKADDR4(fam, addr, port) \ + (struct sockaddr*)&(struct sockaddr_in) \ + { .sin_family = (fam), .sin_addr = (addr)->in, .sin_port = (port) } +#define IP_VS_DBG_SOCKADDR6(fam, addr, port) \ + (struct sockaddr*)&(struct sockaddr_in6) \ + { .sin6_family = (fam), .sin6_addr = (addr)->in6, .sin6_port = (port) } +#define IP_VS_DBG_SOCKADDR(fam, addr, port) (fam == AF_INET ? \ + IP_VS_DBG_SOCKADDR4(fam, addr, port) : \ + IP_VS_DBG_SOCKADDR6(fam, addr, port)) + #define IP_VS_DBG(level, msg, ...) \ do { \ if (level <= ip_vs_get_debug_level()) \ @@ -251,6 +261,7 @@ static inline const char *ip_vs_dbg_addr(int af, char *buf, size_t buf_len, #else /* NO DEBUGGING at ALL */ #define IP_VS_DBG_BUF(level, msg...) do {} while (0) #define IP_VS_ERR_BUF(msg...) do {} while (0) +#define IP_VS_DBG_SOCKADDR(fam, addr, port) NULL #define IP_VS_DBG(level, msg...) do {} while (0) #define IP_VS_DBG_RL(msg...) do {} while (0) #define IP_VS_DBG_PKT(level, af, pp, skb, ofs, msg) do {} while (0) @@ -1244,31 +1255,31 @@ static inline void ip_vs_control_del(struct ip_vs_conn *cp) { struct ip_vs_conn *ctl_cp = cp->control; if (!ctl_cp) { - IP_VS_ERR_BUF("request control DEL for uncontrolled: " - "%s:%d to %s:%d\n", - IP_VS_DBG_ADDR(cp->af, &cp->caddr), - ntohs(cp->cport), - IP_VS_DBG_ADDR(cp->af, &cp->vaddr), - ntohs(cp->vport)); + pr_err("request control DEL for uncontrolled: " + "%pISp to %pISp\n", + IP_VS_DBG_SOCKADDR(cp->af, &cp->caddr, + ntohs(cp->cport)), + IP_VS_DBG_SOCKADDR(cp->af, &cp->vaddr, + ntohs(cp->vport))); return; } - IP_VS_DBG_BUF(7, "DELeting control for: " - "cp.dst=%s:%d ctl_cp.dst=%s:%d\n", - IP_VS_DBG_ADDR(cp->af, &cp->caddr), - ntohs(cp->cport), - IP_VS_DBG_ADDR(cp->af, &ctl_cp->caddr), - ntohs(ctl_cp->cport)); + IP_VS_DBG(7, "DELeting control for: " + "cp.dst=%pISp ctl_cp.dst=%pISp\n", + IP_VS_DBG_SOCKADDR(cp->af, &cp->caddr, + ntohs(cp->cport)), + IP_VS_DBG_SOCKADDR(cp->af, &ctl_cp->caddr, + ntohs(ctl_cp->cport))); cp->control = NULL; if (atomic_read(&ctl_cp->n_control) == 0) { - IP_VS_ERR_BUF("BUG control DEL with n=0 : " - "%s:%d to %s:%d\n", - IP_VS_DBG_ADDR(cp->af, &cp->caddr), - ntohs(cp->cport), - IP_VS_DBG_ADDR(cp->af, &cp->vaddr), - ntohs(cp->vport)); + pr_err("BUG control DEL with n=0 : " + "%pISp to %pISp\n", + IP_VS_DBG_SOCKADDR(cp->af, &cp->caddr, + ntohs(cp->cport)), + IP_VS_DBG_SOCKADDR(cp->af, &cp->vaddr, + ntohs(cp->vport))); return; } @@ -1279,22 +1290,22 @@ static inline void ip_vs_control_add(struct ip_vs_conn *cp, struct ip_vs_conn *ctl_cp) { if (cp->control) { - IP_VS_ERR_BUF("request control ADD for already controlled: " - "%s:%d to %s:%d\n", - IP_VS_DBG_ADDR(cp->af, &cp->caddr), - ntohs(cp->cport), - IP_VS_DBG_ADDR(cp->af, &cp->vaddr), - ntohs(cp->vport)); + pr_err("request control ADD for already controlled: " + "%pISp to %pISp\n", + IP_VS_DBG_SOCKADDR(cp->af, &cp->caddr, + ntohs(cp->cport)), + IP_VS_DBG_SOCKADDR(cp->af, &cp->vaddr, + ntohs(cp->vport))); ip_vs_control_del(cp); } - IP_VS_DBG_BUF(7, "ADDing control for: " - "cp.dst=%s:%d ctl_cp.dst=%s:%d\n", - IP_VS_DBG_ADDR(cp->af, &cp->caddr), - ntohs(cp->cport), - IP_VS_DBG_ADDR(cp->af, &ctl_cp->caddr), - ntohs(ctl_cp->cport)); + IP_VS_DBG(7, "ADDing control for: " + "cp.dst=%pISp ctl_cp.dst=%pISp\n", + IP_VS_DBG_SOCKADDR(cp->af, &cp->caddr, + ntohs(cp->cport)), + IP_VS_DBG_SOCKADDR(cp->af, &ctl_cp->caddr, + ntohs(ctl_cp->cport))); cp->control = ctl_cp; atomic_inc(&ctl_cp->n_control); diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c index f662f198b458..0277cd3c5446 100644 --- a/net/netfilter/ipvs/ip_vs_core.c +++ b/net/netfilter/ipvs/ip_vs_core.c @@ -51,7 +51,6 @@ #include #include - EXPORT_SYMBOL(register_ip_vs_scheduler); EXPORT_SYMBOL(unregister_ip_vs_scheduler); EXPORT_SYMBOL(ip_vs_proto_name); @@ -294,11 +293,11 @@ ip_vs_sched_persist(struct ip_vs_service *svc, #endif snet.ip = src_addr->ip & svc->netmask; - IP_VS_DBG_BUF(6, "p-schedule: src %s:%u dest %s:%u " - "mnet %s\n", - IP_VS_DBG_ADDR(svc->af, src_addr), ntohs(src_port), - IP_VS_DBG_ADDR(svc->af, dst_addr), ntohs(dst_port), - IP_VS_DBG_ADDR(svc->af, &snet)); + IP_VS_DBG(6, "p-schedule: src %pISp dest %pISp " + "mnet %pIS\n", + IP_VS_DBG_SOCKADDR(svc->af, src_addr, ntohs(src_port)), + IP_VS_DBG_SOCKADDR(svc->af, dst_addr, ntohs(dst_port)), + IP_VS_DBG_SOCKADDR(svc->af, &snet, 0)); /* * As far as we know, FTP is a very complicated network protocol, and @@ -566,12 +565,12 @@ ip_vs_schedule(struct ip_vs_service *svc, struct sk_buff *skb, } } - IP_VS_DBG_BUF(6, "Schedule fwd:%c c:%s:%u v:%s:%u " - "d:%s:%u conn->flags:%X conn->refcnt:%d\n", + IP_VS_DBG(6, "Schedule fwd:%c c:%pISp v:%pISp " + "d:%pISp conn->flags:%X conn->refcnt:%d\n", ip_vs_fwd_tag(cp), - IP_VS_DBG_ADDR(cp->af, &cp->caddr), ntohs(cp->cport), - IP_VS_DBG_ADDR(cp->af, &cp->vaddr), ntohs(cp->vport), - IP_VS_DBG_ADDR(cp->daf, &cp->daddr), ntohs(cp->dport), + IP_VS_DBG_SOCKADDR(cp->af, &cp->caddr, ntohs(cp->cport)), + IP_VS_DBG_SOCKADDR(cp->af, &cp->vaddr, ntohs(cp->vport)), + IP_VS_DBG_SOCKADDR(cp->daf, &cp->daddr, ntohs(cp->dport)), cp->flags, refcount_read(&cp->refcnt)); ip_vs_conn_stats(cp, svc); @@ -885,8 +884,8 @@ static int handle_response_icmp(int af, struct sk_buff *skb, /* Ensure the checksum is correct */ if (!skb_csum_unnecessary(skb) && ip_vs_checksum_complete(skb, ihl)) { /* Failed checksum! */ - IP_VS_DBG_BUF(1, "Forward ICMP: failed checksum from %s!\n", - IP_VS_DBG_ADDR(af, snet)); + IP_VS_DBG(1, "Forward ICMP: failed checksum from %pISp!\n", + IP_VS_DBG_SOCKADDR(af, snet, 0)); goto out; } @@ -1219,13 +1218,13 @@ struct ip_vs_conn *ip_vs_new_conn_out(struct ip_vs_service *svc, ip_vs_conn_stats(cp, svc); /* return connection (will be used to handle outgoing packet) */ - IP_VS_DBG_BUF(6, "New connection RS-initiated:%c c:%s:%u v:%s:%u " - "d:%s:%u conn->flags:%X conn->refcnt:%d\n", - ip_vs_fwd_tag(cp), - IP_VS_DBG_ADDR(cp->af, &cp->caddr), ntohs(cp->cport), - IP_VS_DBG_ADDR(cp->af, &cp->vaddr), ntohs(cp->vport), - IP_VS_DBG_ADDR(cp->af, &cp->daddr), ntohs(cp->dport), - cp->flags, refcount_read(&cp->refcnt)); + IP_VS_DBG(6, "New connection RS-initiated:%c c:%pISp v:%pISp " + "d:%pISp conn->flags:%X conn->refcnt:%d\n", + ip_vs_fwd_tag(cp), + IP_VS_DBG_SOCKADDR(cp->af, &cp->caddr, ntohs(cp->cport)), + IP_VS_DBG_SOCKADDR(cp->af, &cp->vaddr, ntohs(cp->vport)), + IP_VS_DBG_SOCKADDR(cp->af, &cp->daddr, ntohs(cp->dport)), + cp->flags, refcount_read(&cp->refcnt)); LeaveFunction(12); return cp; } @@ -1931,7 +1930,6 @@ static int ip_vs_in_icmp_v6(struct netns_ipvs *ipvs, struct sk_buff *skb, } #endif - /* * Check if it's for virtual services, look it up, * and send it on its way... @@ -1960,10 +1958,10 @@ ip_vs_in(struct netns_ipvs *ipvs, unsigned int hooknum, struct sk_buff *skb, int hooknum != NF_INET_LOCAL_OUT) || !skb_dst(skb))) { ip_vs_fill_iph_skb(af, skb, false, &iph); - IP_VS_DBG_BUF(12, "packet type=%d proto=%d daddr=%s" + IP_VS_DBG(12, "packet type=%d proto=%d daddr=%pIS" " ignored in hook %u\n", skb->pkt_type, iph.protocol, - IP_VS_DBG_ADDR(af, &iph.daddr), hooknum); + IP_VS_DBG_SOCKADDR(af, &iph.daddr, 0), hooknum); return NF_ACCEPT; } /* ipvs enabled in this netns ? */ diff --git a/net/netfilter/ipvs/ip_vs_ftp.c b/net/netfilter/ipvs/ip_vs_ftp.c index cf925906f59b..d57dcc2b4396 100644 --- a/net/netfilter/ipvs/ip_vs_ftp.c +++ b/net/netfilter/ipvs/ip_vs_ftp.c @@ -306,9 +306,9 @@ static int ip_vs_ftp_out(struct ip_vs_app *app, struct ip_vs_conn *cp, &start, &end) != 1) return 1; - IP_VS_DBG_BUF(7, "EPSV response (%s:%u) -> %s:%u detected\n", - IP_VS_DBG_ADDR(cp->af, &from), ntohs(port), - IP_VS_DBG_ADDR(cp->af, &cp->caddr), 0); + IP_VS_DBG(7, "EPSV response (%pISp) -> %pISp detected\n", + IP_VS_DBG_SOCKADDR(cp->af, &from, ntohs(port)), + IP_VS_DBG_SOCKADDR(cp->af, &cp->caddr, 0)); } else { return 1; } @@ -510,15 +510,15 @@ static int ip_vs_ftp_in(struct ip_vs_app *app, struct ip_vs_conn *cp, &to, &port, cp->af, &start, &end) == 1) { - IP_VS_DBG_BUF(7, "EPRT %s:%u detected\n", - IP_VS_DBG_ADDR(cp->af, &to), ntohs(port)); + IP_VS_DBG(7, "EPRT %pISp detected\n", + IP_VS_DBG_SOCKADDR(cp->af, &to, ntohs(port))); /* Now update or create a connection entry for it */ - IP_VS_DBG_BUF(7, "protocol %s %s:%u %s:%u\n", - ip_vs_proto_name(ipvsh->protocol), - IP_VS_DBG_ADDR(cp->af, &to), ntohs(port), - IP_VS_DBG_ADDR(cp->af, &cp->vaddr), - ntohs(cp->vport)-1); + IP_VS_DBG(7, "protocol %s %pISp %pISp\n", + ip_vs_proto_name(ipvsh->protocol), + IP_VS_DBG_SOCKADDR(cp->af, &to, ntohs(port)), + IP_VS_DBG_SOCKADDR(cp->af, &cp->vaddr, + ntohs(cp->vport)-1)); } else { return 1; }