linux-kernel - Re: gcc-10: kernel stack is corrupted and fails to boot

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-next>] [day] [month] [year] [list]

Date:   Thu, 14 May 2020 01:22:34 -0400
From:   Arvind Sankar <nivedita@...m.mit.edu>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Borislav Petkov <bp@...e.de>, Arnd Bergmann <arnd@...db.de>,
        Arvind Sankar <nivedita@...m.mit.edu>,
        Kalle Valo <kvalo@...eaurora.org>,
        linux-wireless <linux-wireless@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: gcc-10: kernel stack is corrupted and fails to boot

On Wed, May 13, 2020 at 09:52:07PM -0700, Linus Torvalds wrote:
> On Wed, May 13, 2020, 20:50 Andy Lutomirski <luto@...capital.net> wrote:
> 
> >
> > LTO isn’t a linker taking regular .o files full of regular machine
> > code and optimizing it. That’s nuts.
> >
> 
> Yeah, you're right. I wear originally thinking just an optimizing
> assembler, and then started thinking about link-time optimizations in that
> sense, but it was wrong to then go from that to LTO which has a very
> specific meaning.
> 
> We do have assemblers that do some optimizations, but they tend to all be
> at the single instruction level (eg things like turning "add $128" into
> "sub $-128" which fits in a byte constant).
> 
>     Linus
> 
> >

The gcc docs [1,2] at least don't inspire much confidence that this will
continue working with plain asm("") though:

"Note that GCC’s optimizers can move asm statements relative to other
code, including across jumps."
...
"Note that the compiler can move even volatile asm instructions relative
to other code, including across jump instructions."

Even if we don't include an instruction in it I think it should at least
have a memory clobber, to stop the compiler from deciding that it can be
moved before the call so it can do the tail-call optimization.

[1] https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Basic-Asm
[2] https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Volatile