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:   Tue, 14 Sep 2021 07:02:52 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Max Filippov <jcmvbkbc@...il.com>
Cc:     David Laight <David.Laight@...lab.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        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>
Subject: Re: [PATCH] xtensa: Increase size of gcc stack frame check

On 9/14/21 12:04 AM, Max Filippov wrote:
> On Mon, Sep 13, 2021 at 9:11 AM Guenter Roeck <linux@...ck-us.net> wrote:
>> 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
> 
> That's not what I observe. If I build allmodconfig on v5.15-rc1
> for arm with gcc-8.3 I get 69 of them.
> 

Interesting. I had used gcc 11.2. Anyway, arm:allmodconfig sets
the limit to 2048 for me, for both gcc 8.3 and 11.2, due to
GCC_PLUGIN_LATENT_ENTROPY=y. But you are right, if I disable
GCC_PLUGIN_LATENT_ENTROPY and set the frame size to 1024,
I get lots of frame size errors on arm as well.

>> (including parisc; setting a stack limit of 1024 works just fine
>> with that architecture, at least with gcc 11.x). So the realistic
> 
> This comparison is a bit biased because allmodconfig on xtensa
> enables KASAN which is not supported by the parisc. Disabling
> KASAN roughly halves the size of stack frames for a few
> instances that I've checked.
> 

It wasn't meant to be biased or unbiased, just a (surprising)
observation. Maybe there is some configuration in parisc that
is not enabled with allmodconfig which increases the frame size.

I still don't think that those stack limit warnings (now errors)
will ever get fixed. Which is the point I was trying to make,
and your observation that the stack frames are really that large
because of KASAN just makes that argument stronger.

Other than that, it is not my call to make that to do with this
patch. If you think that it is inappropriate, by all means
reject it.

Thanks,
Guenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ