Re: [PATCH] x86: fix early boot crash on gcc-10
From: Arvind Sankar
Date: Mon Mar 16 2020 - 16:40:06 EST
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
>