linux-kernel - Re: [PATCH] x86: fix early boot crash on gcc-10

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, 16 Mar 2020 16:40:01 -0400
From:   Arvind Sankar <nivedita@...m.mit.edu>
To:     Jakub Jelinek <jakub@...hat.com>
Cc:     Arvind Sankar <nivedita@...m.mit.edu>,
        Borislav Petkov <bp@...en8.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Sergei Trofimovich <slyfox@...too.org>,
        linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Andy Lutomirski <luto@...nel.org>, x86@...nel.org
Subject: Re: [PATCH] x86: fix early boot crash on gcc-10

On Mon, Mar 16, 2020 at 09:08:55PM +0100, Jakub Jelinek wrote:
> On Mon, Mar 16, 2020 at 03:53:41PM -0400, Arvind Sankar wrote:
> > > /*
> > >  * Initialize the stackprotector canary value.
> > >  *
> > >  * NOTE: this must only be called from functions that never return,
> > >  * and it must always be inlined.
> > >  */
> > > static __always_inline void boot_init_stack_canary(void)
> > 
> > Ugh, gcc10 tail-call optimizes the cpu_startup_entry call, and so checks
> > the canary before jumping out. The xen one will need to have stack
> > protector disabled too. It doesn't optimize the arch_call_rest_init call
> > in start_kernel for some reason, but we should probably disable it there
> > too.
> 
> If you mark cpu_startup_entry with __attribute__((noreturn)), then gcc won't
> tail call it.

So I've actually noticed this before -- what's the reason we don't
tail-call optimize calls to noreturn functions? The code remains a call
with nothing after it, but wouldn't a jump still be better? Or if it has
to be a call, at least an undefined opcode or int 3 after the call in
case it was erroneously annotated and returns anyway?

objtool apparently doesn't like what gcc does when calling noreturn
functions, complains about control falling through to next function.
Though it isn't good enough to detect that that's happening even in
start_secondary because there's some cold code following the call :)

init/main.o: warning: objtool: rest_init() falls through to next function kernel_init()

> If you don't, you could add asm (""); after the call to avoid the tail call
> too.
> > 
> >      a06:       0f ae f8                sfence
> >      a09:       48 8b 44 24 08          mov    0x8(%rsp),%rax
> >      a0e:       65 48 2b 04 25 28 00    sub    %gs:0x28,%rax
> >      a15:       00 00
> >      a17:       75 1b                   jne    a34 <start_secondary+0x164>
> >      a19:       48 83 c4 10             add    $0x10,%rsp
> >      a1d:       bf 8d 00 00 00          mov    $0x8d,%edi
> >      a22:       5b                      pop    %rbx
> >      a23:       e9 00 00 00 00          jmpq   a28 <start_secondary+0x158>
> >                         a24: R_X86_64_PLT32     cpu_startup_entry-0x4
> >      a28:       0f 01 1d 00 00 00 00    lidt   0x0(%rip)        # a2f <start_secondary+0x15f>
> >                         a2b: R_X86_64_PC32      debug_idt_descr-0x4
> >      a2f:       e9 cc fe ff ff          jmpq   900 <start_secondary+0x30>
> >      a34:       e8 00 00 00 00          callq  a39 <start_secondary+0x169>
> >                         a35: R_X86_64_PLT32     __stack_chk_fail-0x4
> 
> 	Jakub
>