linux-kernel - Re: [PATCH] xtensa: Increase size of gcc stack frame check

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, 13 Sep 2021 09:11:36 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     David Laight <David.Laight@...LAB.COM>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     Masahiro Yamada <masahiroy@...nel.org>,
        "linux-xtensa@...ux-xtensa.org" <linux-xtensa@...ux-xtensa.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Chris Zankel <chris@...kel.net>,
        Max Filippov <jcmvbkbc@...il.com>
Subject: Re: [PATCH] xtensa: Increase size of gcc stack frame check

On 9/13/21 8:57 AM, David Laight wrote:
> From: Guenter Roeck
>> Sent: 12 September 2021 03:53
>>
>> xtensa frame size is larger than the frame size for almost all other
>> architectures. This results in more than 50 "the frame size of <n> is
>> larger than 1024 bytes" errors when trying to build xtensa:allmodconfig.
>>
>> Increase frame size for xtensa to 1536 bytes to avoid compile errors
>> due to frame size limits.
> 
> Have you done anything to check what happens at run-time?
> I'd guess that the deepest stack use is inside printk() in
> some obscure error path.
> 
> In reality all these 1k+ stack frames need killing
> rather than the limit for the compiler warning increased.
> 
> While it may be sensible for a system call entry function
> so allocate a reasonable size buffer on stack (as poll()
> and sendmsg() probably do) allocating big buffers way
> down the call stack could easily cause stack overflow.
> Even a 1k stack frame is huge.
> 

The functions I checked typically have pretty large local data
(like, more than 700-800 bytes). The errors are only observed
with xtensa:allmodconfig test builds. While it may be arguable
if those functions really need that much data on the stack, it
is unreasonable to assume that all those errors (again, more
than 50) are ever going to get fixed, especially since the errors
are only seen with xtensa and not with any other architecture
(including parisc; setting a stack limit of 1024 works just fine
with that architecture, at least with gcc 11.x). So the realistic
options are:

1) accept this or a similar patch
2) stop build testing xtensa:allmodconfig
3) Manually disable CONFIG_WERROR when test building xtensa:allmodconfig

As it looks like, I'll probably implement option 3) in my test builds.
I planned to start doing that around v5.15-rc4/rc5, but I may do it
earlier if it is becoming obvious that the now-errors won't get fixed.

Guenter