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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20200428220353.uepo455bj76sym4k@treble>
Date:   Tue, 28 Apr 2020 17:03:53 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Arnd Bergmann <arnd@...db.de>,
        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 11:55:54PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 28, 2020 at 03:38:55PM -0500, Josh Poimboeuf wrote:
> > 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 
> 
> binutils.git/gas/configure/tc-i386.c:i386_generate_nops
> 
> When there's too many NOPs (as here) it generates a JMP across the NOPS.
> It makes some sort of sense, at some point executing NOPs is going to be
> more expensive than a branch.. But shees..

Urgh.  Even if I tell it specifically to pad with NOPs, it still does
this "trick".  I have no idea how to deal with this in objtool.

-- 
Josh