Re: [PATCH for-4.22] xen/x86: Always strip xen.efi

[Frediano Ziglio <freddy77@xxxxxxxxx>]

On Thu, 11 Jun 2026 at 16:18, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 08.06.2026 19:31, Andrew Cooper wrote:
> > From: Frediano Ziglio <frediano.ziglio@xxxxxxxxxx>
> >
> > xen.efi with debugging symbols is ~45MB, down to ~9.3MB when stripped.
> > Multiple firmwares (as seen by QubesOS, Trenchboot, and XenServer) are 
> > unable
> > to boot xen.efi when debugging symbols are included.
> >
> > Either way, having debug symbols by default is abnormal and contrary to how
> > the non-EFI path works.
>
> I'm not happy with how things are put here. There's nothing abnormal about
> including about anything. What is abnormal is the manufacturing of a 32-bit
> ELF binary from a 64-bit one by mkelf32, to please bootloaders. An EFI
> binary should be permitted to include whatever data it wants, and firmware
> should be able to load it as long as memory permits. I don't expect you
> mean to indicate that problematic systems don't have 45Mb available at boot.
>
> Including debug info can be a waste of I/O bandwidth and memory, when the
> loader doesn't skip loading those .debug_* sections (for valid or bogus
> reasons).
>

One reason, at least for secure boot, is to compute the hash of the
file. The hash includes almost everything, excluding the header
checksum, the signature section header and the signature section (all
that must be read too).

> > Produce xen-syms.efi unconditionally, just like xen-syms.  If
> > CONFIG_DEBUG_INFO is enabled, these will contain debug symbols, and if not,
> > then not.  When xen-syms is processed by mkelf32, the debug symbols are 
> > simply
> > discarded.  For xen-syms.efi, call $(STRIP) to produce xen.efi.
> >
> > Some old versions of binutils ld managed to produce efi files which the
> > matching version of strip couldn't process.  This includes Binutils 2.26
> > included in Ubuntu 16.04.  Delete the workaround for this bug, and require a
> > less broken toolchain.
>
> And we're certain newer versions of strip don't do any harm to the binaries?
> Already towards Frediano's posting I said that having looked at how things
> work there, I'm far from certain.
>

Yes, software contains bugs and in this area binutils has quite a
history. What we know for sure is that a specific problem has been
fixed. Are all the bugs fixed? Probably not. I don't see a valid
reason to wait to have some kind of "bug free" version.

> Jan
>

Frediano