linux-kernel - Re: Remaining randconfig objtool warnings, linux-next-20200428

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 28 Apr 2020 15:38:55 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>
Subject: Re: Remaining randconfig objtool warnings, linux-next-20200428

On Tue, Apr 28, 2020 at 10:19:46PM +0200, Arnd Bergmann wrote:
> On Tue, Apr 28, 2020 at 6:10 PM Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> > On Tue, Apr 28, 2020 at 04:49:15PM +0200, Arnd Bergmann wrote:
> > > ==> build/x86/0xFD7B7323_defconfig/log <==
> > > arch/x86/entry/entry_64.o: warning: objtool: .entry.text+0x991: unreachable instruction
> >
> > This warning looks correct, did you make a change to entry_64.S?
> 
> I bisected my local patches and found that I had a local hack that turned
> off CONFIG_RETPOLINE for testing something unrelated. I can reproduce
> it on linux-next with this patch:
> 
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -447,8 +447,7 @@ config GOLDFISH
>         depends on X86_GOLDFISH
> 
>  config RETPOLINE
> -       bool "Avoid speculative indirect branches in kernel"
> -       default y
> +       def_bool n
>         select STACK_VALIDATION if HAVE_STACK_VALIDATION
>         help
>           Compile kernel with the retpoline compiler options to guard against

Thanks, that worked.

This one makes no sense to me.  It looks like the assembler is inserting
a jump as part of the alignment padding???  WTH.

0000000000000980 <common_spurious>:
     980:	48 83 04 24 80       	addq   $0xffffffffffffff80,(%rsp)
     985:	e8 00 00 00 00       	callq  98a <common_spurious+0xa>
			986: R_X86_64_PLT32	interrupt_entry-0x4
     98a:	e8 00 00 00 00       	callq  98f <common_spurious+0xf>
			98b: R_X86_64_PLT32	smp_spurious_interrupt-0x4
     98f:	eb 7e                	jmp    a0f <ret_from_intr>
     991:	eb 6d                	jmp    a00 <common_interrupt>
     993:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
     99a:	00 00 00 00 
     99e:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
     9a5:	00 00 00 00 
     9a9:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
     9b0:	00 00 00 00 
     9b4:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
     9bb:	00 00 00 00 
     9bf:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
     9c6:	00 00 00 00 
     9ca:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
     9d1:	00 00 00 00 
     9d5:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
     9dc:	00 00 00 00 
     9e0:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
     9e7:	00 00 00 00 
     9eb:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
     9f2:	00 00 00 00 
     9f6:	66 2e 0f 1f 84 00 00 	nopw   %cs:0x0(%rax,%rax,1)
     9fd:	00 00 00 

0000000000000a00 <common_interrupt>:
     a00:	48 83 04 24 80       	addq   $0xffffffffffffff80,(%rsp)

-- 
Josh