linux-kernel - Re: div_u64/do_div stack size usage, was Re: [v3] block: Removed a warning while compiling with a cross compiler for parisc

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:   Thu, 8 Jul 2021 13:37:17 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Helge Deller <deller@....de>
Cc:     Abd-Alrhman Masalkhi <abd.masalkhi@...il.com>,
        Christoph Hellwig <hch@...radead.org>,
        Jens Axboe <axboe@...nel.dk>,
        Bernardo Innocenti <bernie@...eler.com>,
        Parisc List <linux-parisc@...r.kernel.org>,
        linux-block <linux-block@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Dan Carpenter <dan.carpenter@...cle.com>
Subject: Re: div_u64/do_div stack size usage, was Re: [v3] block: Removed a
 warning while compiling with a cross compiler for parisc

On Thu, Jul 8, 2021 at 11:30 AM Helge Deller <deller@....de> wrote:
> On 7/7/21 10:39 PM, Arnd Bergmann wrote:
> >> [PATCH] parisc: Increase gcc stack frame check to 2048 for 32- and 64-bit
> >>
> >> parisc uses much bigger frames than other architectures, so increase the
> >> stack frame check value to 2048 to avoid compiler warnings.
> >
> > I think setting it to 2048 is rather excessive,
>
> Since parisc needs roughly twice the frame (and stack) size as x86,
> 2048 seemed logical since that's the double of what's used on x86.
> Of course we can reduce it, e.g. to 1536.

But it doesn't use twice as much for large functions at all. The stack
frame for a small function is much larger, so you need a larger kernel
stack to allow for deely nested call chains, but the frame for single
function with large variables is only a bit larger as most of it is used up
by those variables.

> > and it would make you miss other real bugs. What I suggested was to
> > change the defconfig to use CONFIG_CC_OPTIMIZE_FOR_SIZE instead.
>
> But then you still will see those warnings in case you choose to not
> optize for size.

Right, and I would consider that a good thing: this warning is for a real
(though fairly harmless) bug that has already been fixed with newer
toolchains, so anyone that runs into the bug should probably see the
warning for it. Doubling the limit would effectively prevent similar bugs
from being noticed, and they could be in performance-critical code
or cause an actual stack overrun.

I can think of two other, more directed workarounds:

- change block/Makefile to add -Os to the cflags for this one file in
  known-broken configurations (parisc with old gcc and -O2),
  to be removed in a few years when gcc-10 becomes the minimum
  supported version

- add a warning that points to the gcc bug (if someone has a link)
  when building an affected configuration, and let users decide to
  either change their setup (using -Os or a newer compiler) or to
  ignore the warning.

> or bad coding, e.g. huge local variables

That's what I meant with 'kernel bug'.

       Arnd