netdev - Re: [PATCH 07/26] brcmsmac: reduce stack size with KASAN

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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