linux-kernel - Re: v4.10: kernel stack frame pointer .. has bad value (null)

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]

Message-ID: <CA+55aFw8ZVHtTDT8jCCtwP=oZFVKnDZVa3bMFdzt6+sGqFNeKw@mail.gmail.com>
Date:   Wed, 8 Mar 2017 10:25:01 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     Andy Lutomirski <luto@...capital.net>, Pavel Machek <pavel@....cz>,
        kernel list <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Lutomirski <luto@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        Brian Gerst <brgerst@...il.com>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        Peter Anvin <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: v4.10: kernel stack frame pointer .. has bad value (null)

On Wed, Mar 8, 2017 at 9:37 AM, Josh Poimboeuf <jpoimboe@...hat.com> wrote:
>
> It does seem to make it bigger.  With Pavel's config on gcc 6, if I add
> -maccumulate-outgoing-args:
>
> That's 3.8% more text on x86-32.

That's even more than I expected.  I would have expected the
-mregparm=3 to catch so much of our stack setup that it wouldn't be
all that noticeable. But apparently we just have a ton of functions
with more than 3 arguments.

> (FWIW, on x86-64, the size difference is negligible.)

Yeah, I seriously hope we've actively tried to avoid the more than six
argument calling conventions. The mm code had some that grew over
time, but most of that got converted to passing a pointer to a
descriptor structure instead (ie "struct vm_fault" etc models).

> As it turns out, when optimizing for size, gcc seems to ignore
> -maccumulate-outgoing-args completely.  So I guess we would have to live
> with both cases anyway.  Which means I'll need to make the unwinder
> smart enough to deal with it.
>
> But that brings up another question.  If -maccumulate-outgoing-args is
> ignored with CONFIG_CC_OPTIMIZE_FOR_SIZE=y, wouldn't using that option
> break the things which require -maccumulate-outgoing-args?
>
> So, looking deeper at the various reasons this flag is enabled, they
> seem to be mostly obsolete.

Good.

> - CONFIG_FUNCTION_GRAPH_TRACER sets it on x86-32 because of a gcc bug
>   where the stack gets aligned before the mcount call.  This issue
>   should be mostly obsolete as most modern compilers now have -mfentry.
>   We could make it dependent on CC_USING_FENTRY.

Yeah. At some point we might even upgrade the compiler requirements to
no longer accept the mcount model.

I think the fentry model is gcc-4.6.0 and up. Currently I guess we
support gcc-3.2+, which is fairly ridiculous considering that 4.6.0 is
from March, 2011. So it's over five years ago already.

gcc-3.2.0 is from 2002, I think. At some point you just have to say
"caring about a 15 year old compiler is ridiculous"

The main reason we have fairly aggressively supported old compilers
tends to be some odder architectures that don't have good support, so
people use various random "this works for me" versions.

We could easily make the gcc version checks much more strict on x86, I suspect.

> - CONFIG_JUMP_LABEL sets it on x86-32 because of a bug in gcc <= 4.5.1
>   which has since been fixed with
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46226.  We could probably
>   make it gcc-version-dependent.

Looks like we could just use the FENTRY test, since that's more recent.

> - x86-64 sets it to apparently make the no-longer-in-tree DWARF unwinder
>   happy with older versions of gcc.

Ok. Since it's not as big of a deal on x86-64 I guess we don't care,
but on the other hand it would probably then be better to aim to
switch away from it entirely and just put that whole sorry thing
behind us.

> So it looks like -maccumulate-outgoing-args isn't actually needed in
> most cases.

That would be lovely indeed.

                  Linus