linux-kernel - Re: [PATCH v2] efistub: Only link libstub to final vmlinux

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] [day] [month] [year] [list]

Message-ID: <rhnei6wovxmoqs36wdysomfsul3faxtmgde73wrrqdt3qo3b2j@akd7vzne76rq>
Date: Tue, 14 Oct 2025 09:47:55 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Huacai Chen <chenhuacai@...nel.org>, 
	Tiezhu Yang <yangtiezhu@...ngson.cn>, loongarch@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org, 
	linux-riscv@...ts.infradead.org, linux-efi@...r.kernel.org, linux-kbuild@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] efistub: Only link libstub to final vmlinux

On Mon, Oct 13, 2025 at 04:36:49PM +0200, Ard Biesheuvel wrote:
> On Mon, 13 Oct 2025 at 16:09, Huacai Chen <chenhuacai@...nel.org> wrote:
> > On Sat, Oct 11, 2025 at 11:59 PM Ard Biesheuvel <ardb@...nel.org> wrote:
> > > It is an objtool issue in essence.
> > >
> > > The generated code looks like this
> > >
> > > 9000000001743080: ff b7 fe 57   bl      -332 <__efistub_kernel_entry_address>
> > > 9000000001743084: 26 03 c0 28   ld.d    $a2, $s2, 0
> > > 9000000001743088: 87 00 15 00   move    $a3, $a0
> > > 900000000174308c: 04 04 80 03   ori     $a0, $zero, 1
> > > 9000000001743090: c5 02 15 00   move    $a1, $fp
> > > 9000000001743094: e1 00 00 4c   jirl    $ra, $a3, 0
> > >
> > > 9000000001743098 <__efistub_exit_boot_func>:
> > > 9000000001743098: 63 c0 ff 02   addi.d  $sp, $sp, -16
> > >
> > > There is nothing wrong with this code, given that the indirect call is
> > > to a __noreturn function, and so the fact that it falls through into
> > > __efistub_exit_boot_func() is not a problem.
> > >
> > > Even though the compiler does nothing wrong here, it would be nice if
> > > it would emit some kind of UD or BRK instruction after such a call, if
> > > only to make the backtrace more reliable. But the code is fine, and
> > > objtool simply does not have the information it needs to determine
> > > that the indirect call is of a variety that never returns.
> > So the best way is to fix the objtool?
> >
> 
> I think the best solution is to fix the compiler, and ensure that call
> instructions are always followed by some undefined or debug/break
> opcode. This works around this problem, but it also ensures that the
> return address does not point to the wrong function, which may cause
> confusion in backtraces.

I think the compiler folks will say that's working as designed.  The
whole point of __noreturn is to eliminate unecessary code after the
call.

Unwinders are already designed to handle that case anyway.

If you don't want to optimize out the code after the call then just
remove the __noreturn annotation from the function pointer.

> > > So I don't mind fixing it in the code, but only for LoongArch, given
> > > that the problem does not exist on arm64 or RISC-V.
> > You believe this problem won't exist even if they add objtool support
> > (because their objtool will be sane)?
> >
> 
> It depends on the compiler.

I don't think so, all compilers do this...

My suggestion (which prompted this v2 patch) was to move the libstub
code out of vmlinux.o (but still keep it in vmlinux), to make it
consistent with what x86 already does.

The idea is that libstub code doesn't belong in vmlinux.o because it's
not a part of the kernel proper, and doesn't need to be validated or
modified by objtool for any reason.

-- 
Josh