Message-ID: <CAMj1kXF+hDJy0vRWNgwoijHxvA-scvhGODMj9A3dv19v3jf2yw@mail.gmail.com>
Date: Thu, 16 Oct 2025 16:52:20 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Josh Poimboeuf <jpoimboe@...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 Tue, 14 Oct 2025 at 18:47, Josh Poimboeuf <jpoimboe@...nel.org> wrote:
>
> 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.
>

This is because x86 links the EFI stub into the decompressor, not into vmlinux.

> 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.
>

I don't see a reason to change this on architectures that a) do not
use objtool and b) link the EFI stub into vmlinux. If LoongArch wants
to change this, that is fine, but that still does not mean it needs to
change on other architectures too.

EFI related boot errors are a nightmare to debug, and I will be the
one getting the reports when this regresses arm64 on hardware that 2
people on the planet have access to.

Powered by blists - more mailing lists