lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 6 Mar 2017 11:38:00 +0100 From: Arnd Bergmann <arnd@...db.de> To: Arend Van Spriel <arend.vanspriel@...adcom.com> Cc: kasan-dev <kasan-dev@...glegroups.com>, Andrey Ryabinin <aryabinin@...tuozzo.com>, Alexander Potapenko <glider@...gle.com>, Dmitry Vyukov <dvyukov@...gle.com>, Networking <netdev@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-media@...r.kernel.org, linux-wireless <linux-wireless@...r.kernel.org>, kernel-build-reports@...ts.linaro.org, "David S . Miller" <davem@...emloft.net> Subject: Re: [PATCH 07/26] brcmsmac: reduce stack size with KASAN On Mon, Mar 6, 2017 at 10:16 AM, Arend Van Spriel <arend.vanspriel@...adcom.com> wrote: > On 2-3-2017 17:38, Arnd Bergmann wrote: >> The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put an object >> on the stack, which will each require a redzone with KASAN and lead to possible >> stack overflow: >> >> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy': >> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: warning: the frame size of 6312 bytes is larger than 1000 bytes [-Wframe-larger-than=] > > Looks like this warning text ended up in the wrong commit message. Got > me confused for a sec :-p What's wrong about the warning? >> This marks the two functions as noinline_for_kasan, avoiding the problem entirely. > > Frankly I seriously dislike annotating code for the sake of some > (dynamic) memory analyzer. To me the whole thing seems rather > unnecessary. If the code passes the 2048 stack limit without KASAN it > would seem the limit with KASAN should be such that no warning is given. > I suspect that it is rather difficult to predict the additional size of > the instrumentation code and on some systems there might be a real issue > with increased stack usage. The frame sizes don't normally change that much. There are a couple of drivers like brcmsmac that repeatedly call an inline function which has a local variable that it passes by reference to an extern function. While normally those variables share a stack location, KASAN forces each instance to its own location and adds (in this case) 80 bytes of redzone around it to detect out-of-bounds access. While most drivers are fine with a 1500 byte warning limit, increasing the limit to 7kb would silence brcmsmac (unless more registers are accessed from wlc_phy_workarounds_nphy) but also risk a stack overflow to go unnoticed. Arnd
Powered by blists - more mailing lists