Message-ID: <jxfb5a2c2qber623l2gwewirwod54bbgfnvt7t7f3jah2ea33g@2uyhy3auzmpx>
Date: Fri, 17 Oct 2025 10:05:13 -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 Fri, Oct 17, 2025 at 06:26:47PM +0200, Ard Biesheuvel wrote:
> On Fri, 17 Oct 2025 at 18:22, Josh Poimboeuf <jpoimboe@...nel.org> wrote:
> >
> > On Fri, Oct 17, 2025 at 01:00:17PM +0200, Ard Biesheuvel wrote:
> > > On Thu, 16 Oct 2025 at 17:49, Josh Poimboeuf <jpoimboe@...nel.org> wrote:
> > > >
> > > > On Thu, Oct 16, 2025 at 04:52:20PM +0200, Ard Biesheuvel wrote:
> > > > > On Tue, 14 Oct 2025 at 18:47, Josh Poimboeuf <jpoimboe@...nel.org> wrote:
> > > > > > 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.
> > > >
> > > > The idea was to have more consistency, so vmlinux.o never has libstub,
> > > > regardless of arch, but that's your call.
> > > >
> > >
> > > The code in libstub ends up in .init.text, which will be mapped
> > > executable during boot on architectures that incorporate it into
> > > vmlinux.
> > >
> > > If objtool validation is never needed for such code, on the basis that
> > > it is not actually called even though it is present, then I think that
> > > is fine.
> > >
> > > For the other architectures, I don't have any objections in principle,
> > > I'm just being cautious due to the regression risk.
> > >
> > > > I'd still propose we keep the KBUILD_VMLINUX_LIBS_PRELINK mechanism to
> > > > allow other arches to opt in as needed.
> > > >
> > >
> > > Again, no objection in principle. To me, it just seems a lot of churn
> > > just to avoid having to teach objtool about indirect calls to noreturn
> > > functions.
> >
> > Well, one of these days we will need to do that with some kind of
> > compiler -fannotate-noreturn feature or plugin or whatever, but this was
> > more about "why are we validating libstub code anyway, it doesn't seem
> > necessary and x86 doesn't do it, so lets make them consistent".
> >
> 
> Sure. So objtool validation is not needed even if the code is
> incorporated into vmlinux, and therefore mapped executable at boot?
> I.e., objtool does not check for gadgets or other things that may be
> problematic even if they are never called directly from reachable
> code?

Well, boot-time gadgets aren't really a thing.  And, as you said,
libstub is in .init.text, so it gets freed (and presumably mapped
non-executable) during boot, so we don't have to worry about any gadgets
hanging around in memory after the fact.

That said, objtool also generates ORC metadata, so in addition to
security-type things, it also cares about any code that might show up on
a stack trace during a boot-time warning/oops.  So it *does* care about
.init.text code in that sense.

But IIUC, the libstub code runs *very* early, and wouldn't show up in a
stack trace anyway, because there are no traces of it on the stack once
it branches to head.S code (which doesn't save the link register).

-- 
Josh

Powered by blists - more mailing lists