Message-ID: <CANBHLUikrwQS2UcMa1Ryde3r8mPSTCL1WrObF1qKa+o-=MjN=A@mail.gmail.com>
Date: Sun, 26 Oct 2025 23:05:41 +0000
From: Dimitri John Ledkov <dimitri.ledkov@...gut.co.uk>
To: Nathan Chancellor <nathan@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org, 
	masahiroy@...nel.org, arnd@...db.de, linux-kbuild@...r.kernel.org, 
	legion@...nel.org, nsc@...nel.org
Subject: Re: [PATCH] kbuild: align modinfo section for Secureboot Authenticode
 EDK2 compat

On Sun, 26 Oct 2025 at 21:56, Nathan Chancellor <nathan@...nel.org> wrote:
>
> Hi Dimitri,
>
> On Sun, Oct 26, 2025 at 08:21:00PM +0000, Dimitri John Ledkov wrote:
> > Previously linker scripts would always generate vmlinuz that has sections
> > aligned. And thus padded (correct Authenticode calculation) and unpadded
>
> Was this something that was guaranteed to happen or did it just always
> happen by coincidence? Is there a way to enforce this?

I don't believe this was ever guaranteed, but out of convenience /
performance / compatibility various sections are aligned and padded
already. Thus it is possible that it was an unwritten contract that
all kernels' sections so far have been padded/aligned on many if not
all UEFI platforms.

>From time to time, roughly every 3-5 years since 2012, I experience
this class of bugs in various EFI tooling and/or projects. In all
cases projects agree to produce aligned&padded binaries.
Because it is almost no cost to do so, and it prevents head-scratching
debugging.

I don't know of a good way to enforce this, the pesign tool is a good
way to check this -> as it implements the known padded/nopadding
options to calculate the hashes. Maybe some pefile walk script can be
written to validate/test sections at the end of the kernel build. If
such a tool exists, it would be useful for gnu-efi, grub,
systemd-boot, fwupd, and all kernels.

>
> > calculation would be same. As in https://github.com/rhboot/pesign userspace
> > tool would produce the same authenticode digest for both of the following
> > commands:
> >
> >     pesign --padding --hash --in ./arch/x86_64/boot/bzImage
> >     pesign --nopadding --hash --in ./arch/x86_64/boot/bzImage
> >
> > The commit 3e86e4d74c04 ("kbuild: keep .modinfo section in
> > vmlinux.unstripped") added .modinfo section of variable length. Depending
> > on kernel configuration it may or may not be aligned.
> >
> > All userspace signing tooling correctly pads such section to calculation
> > spec compliant authenticode digest.
>
> I might be missing something here but .modinfo should not be in the
> final vmlinux since it gets stripped out via the strip_relocs rule in
> scripts/Makefile.vmlinux. Does this matter because an unaligned .modinfo
> section could potentially leave sections after it in the linker scripts
> unaligned as well?

I am out of my depth here as well, but yes I too am surprised how the
change in question affected the binary.
Note that .modinfo doesn't declare 0 VMA address, and if one sets it
as .modinfo 0 => linking fails due to overlap.
Thus yes, my naive understanding is that presence of this unaligned
section pushed something else to start on an unaligned address, and
that itself was not padded.
Or maybe strip doesn't recalculate things..... but then is it really
strip at this point if we want it to move sections about and
align/padd them, sounds more like linker script at this point.

When I look with objdump at two vmlinux the working and non-working
one, they look almost identical with nothing standing out. But of
course I only see the top level pefile

Possibly a better way to do this is to indeed have dedicated linker
scripts for uncompressed image with extra metadata and debug info;
uncompressed image without extra metadata/debug; compressed image with
debug info; compressed image without debug info => as direct link
targets, rather than link - then - strip.

>
> > However, if bzImage is not further processed and is attempted to be loaded
> > directly by EDK2 firmware, it calculates unpadded Authenticode digest and
>
> Could this affect other bootloaders as well?

Yes. It can affect lots of tooling that works with EFI binaries such
as signing tools, efivars creation tooling, parsing/wrapper tools,
bootloaders, and boot firmware. Given how niche all of this is, and
because the majority of EFI binaries are padded & aligned, it is
highly unusual when an unagling and/or unpadded one is encountered.

> I noticed this report about
> rEFInd and pointed them here in case it was related:
>
> https://lore.kernel.org/CAB95QARfqSUNJCCgyPcTPu0-hk10e-sOVVMrnpKd6OdV_PHrGA@mail.gmail.com/
>
> > fails to correct accept/reject such kernel builds even when propoer
> > Authenticode values are enrolled in db/dbx. One can say EDK2 requires
> > aligned/padded kernels in Secureboot.
> >
> > Thus add ALIGN(8) to the .modinfo section, to esure kernels irrespective of
> > modinfo contents can be loaded by all existing EDK2 firmware builds.
> >
> > Fixes: 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped")
>
> I took this change via the Kbuild tree for 6.18-rc1 so I can pick this
> up for kbuild-fixes or Arnd can take this if he has anything pending for
> fixes in the asm-generic tree.
>

This would be very appreciated. Thank you.

> > Cc: stable@...r.kernel.org
> > Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@...gut.co.uk>
> > ---
> >  include/asm-generic/vmlinux.lds.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> > index 8a9a2e732a65b..e04d56a5332e6 100644
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -832,7 +832,7 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
> >
> >  /* Required sections not related to debugging. */
> >  #define ELF_DETAILS                                                  \
> > -             .modinfo : { *(.modinfo) }                              \
> > +             .modinfo : { *(.modinfo) . = ALIGN(8); }                \
> >               .comment 0 : { *(.comment) }                            \
> >               .symtab 0 : { *(.symtab) }                              \
> >               .strtab 0 : { *(.strtab) }                              \
> > --
> > 2.51.0
> >

-- 
Regards,

Dimitri.

Powered by blists - more mailing lists