linux-kernel - Re: "relocation to !ENDBR" objtool warnings

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: <20241218084729.mluqut2jqp57ckwa@jpoimboe>
Date: Wed, 18 Dec 2024 00:47:29 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: "relocation to !ENDBR" objtool warnings

On Tue, Dec 17, 2024 at 10:09:56AM +0100, Arnd Bergmann wrote:
> On Tue, Dec 17, 2024, at 09:54, Arnd Bergmann wrote:
> >
> > 00000000000000f0 <stpcpy>:
> >   f0:   66 66 2e 0f 1f 84 00    data16 cs nopw 0x0(%rax,%rax,1)
> >   f7:   00 00 00 00 
> >   fb:   0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)
> >  100:   f3 0f 1e fa             endbr64
> 
> 
> I had one more look at the assembler file created by gcc and found
> that this is a 16-byte nop:
> 
>         .align 16
>         .globl  stpcpy
>         .type   stpcpy, @function
> stpcpy:
>         .p2align 5
>         endbr64
> .L30:
>         movzbl  (%rsi), %eax    # MEM[(const char *)src_8 + -1B], _1
>         movq    %rdi, %rdx      # dest, <retval>
>         addq    $1, %rsi        #, src
>         addq    $1, %rdi        #, dest
>         movb    %al, -1(%rdi)   # _1, MEM[(char *)dest_9 + -1B]
>         testb   %al, %al        # _1
>         jne     .L30    #,
>         movq    %rdx, %rax      # <retval>,
>         xorl    %edx, %edx      #
>         xorl    %esi, %esi      #
>         xorl    %edi, %edi      #
>         ret
>         .size   stpcpy, .-stpcpy
>         .align 16
> 
> No idea why it got inserted here, or why it only shows up in these
> two functions. Having a nop before the endbr is a compiler bug, right?

Yeah, looks like a bug to me.

-- 
Josh