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

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

[Andrew Cooper]

From: Frediano Ziglio <frediano.ziglio@citrix.com>

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.

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.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Teddy Astie <teddy.astie@vates.tech>
CC: Frediano Ziglio <frediano.ziglio@citrix.com>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
CC: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
CC: Daniel P. Smith <dpsmith@apertussolutions.com>

For 4.22.  This was posted previously as

  https://lore.kernel.org/xen-devel/20251208133945.61375-1-frediano.ziglio@citrix.com/T/#u

but merged the two patches and rewritten the commit message to make it clear
that failing to strip xen.efi is causing boot failures.

Previously xen.efi.elf was produced but it's unclear why, and unnecessaerily
different, so I've dropped it.

While this does want backporting, it can't be.  Xen 4.21 and older still build
test with Ubuntu 16.04 and choke
---
 .gitignore            |  1 +
 CHANGELOG.md          |  3 +++
 docs/misc/efi.pandoc  |  8 +-------
 xen/Kconfig.debug     |  9 ++-------
 xen/Makefile          | 19 -------------------
 xen/arch/x86/Makefile | 11 ++++-------
 xen/arch/x86/arch.mk  |  7 -------
 7 files changed, 11 insertions(+), 47 deletions(-)

diff --git a/.gitignore b/.gitignore
index bfc7bdf043c3..49e2c6961768 100644
--- a/.gitignore
+++ b/.gitignore
@@ -224,6 +224,7 @@ tools/flask/policy/xenpolicy-*
 xen/xen
 xen/suppression-list.txt
 xen/xen-syms
+xen/xen-syms.efi
 xen/xen-syms.map
 xen/xen.*
 
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 5cf19372a361..71d1e9ab8c69 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -14,6 +14,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
  - On x86:
    - Enable pf-fixup option by default for PVH dom0.
    - The libxenguest bzImage loader now uses the system liblz4 library.
+   - The install-time environment variable INSTALL_EFI_STRIP no longer exists.
+     xen.efi is always stripped, while the symbols remain available in
+     xen-syms.efi.
 
 ### Added
  - Support for per-domain Xenstore quota in C xenstored (includes
diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc
index 8198a7f063cf..0a3fd67076fc 100644
--- a/docs/misc/efi.pandoc
+++ b/docs/misc/efi.pandoc
@@ -20,13 +20,7 @@ Xen to load the configuration file even if multiboot modules are found.
 Once built, `make install-xen` will place the resulting binary directly into
 the EFI boot partition, provided `EFI_VENDOR` is set in the environment (and
 `EFI_MOUNTPOINT` is overridden as needed, should the default of `/boot/efi` not
-match your system). When built with debug info, the binary can be quite large.
-Setting `INSTALL_EFI_STRIP=1` in the environment will cause it to be stripped
-of debug info in the process of installing. `INSTALL_EFI_STRIP` can also be set
-to any combination of options suitable to pass to `strip`, in case the default
-ones don't do. The xen.efi binary will also be installed in `/usr/lib64/efi/`,
-unless `EFI_DIR` is set in the environment to override this default. This
-binary will not be stripped in the process.
+match your system).
 
 The binary itself will require a configuration file (names with the `.efi`
 extension of the binary's name replaced by `.cfg`, and - until an existing
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index d900d926c555..fcd3fc3d36cf 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -147,12 +147,7 @@ config DEBUG_INFO
 	  Say Y here if you want to build Xen with debug information. This
 	  information is needed e.g. for doing crash dump analysis of the
 	  hypervisor via the "crash" tool.
-	  Saying Y will increase the size of the xen-syms and xen.efi
-	  binaries. In case the space on the EFI boot partition is rather
-	  limited, you may want to install a stripped variant of xen.efi in
-	  the EFI boot partition (look for "INSTALL_EFI_STRIP" in
-	  docs/misc/efi.pandoc for more information - when not using
-	  "make install-xen" for installing xen.efi, stripping needs to be
-	  done outside the Xen build environment).
+	  Saying Y will increase the size of the xen-syms and xen-syms.efi
+	  binaries.
 
 endmenu
diff --git a/xen/Makefile b/xen/Makefile
index 1f11610b5f68..0f9b56fc399d 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -493,22 +493,6 @@ endif
 .PHONY: _build
 _build: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
 
-# Strip
-#
-# INSTALL_EFI_STRIP, if defined, will cause xen.efi to be stripped before it
-# is installed. If INSTALL_EFI_STRIP is '1', then the default option(s) below
-# will be used. Otherwise, INSTALL_EFI_STRIP value will be used as the
-# option(s) to the strip command.
-ifdef INSTALL_EFI_STRIP
-
-ifeq ($(INSTALL_EFI_STRIP),1)
-efi-strip-opt := --strip-debug --keep-file-symbols
-else
-efi-strip-opt := $(INSTALL_EFI_STRIP)
-endif
-
-endif
-
 .PHONY: _install
 _install: D=$(DESTDIR)
 _install: T=$(notdir $(TARGET))
@@ -535,9 +519,6 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
 		ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi; \
 		ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T).efi; \
 		if [ -n '$(EFI_MOUNTPOINT)' -a -n '$(EFI_VENDOR)' ]; then \
-			$(if $(efi-strip-opt), \
-			     $(STRIP) $(efi-strip-opt) -p -o $(TARGET).efi.stripped $(TARGET).efi && \
-			     $(INSTALL_DATA) $(TARGET).efi.stripped $(D)$(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi ||) \
 			$(INSTALL_DATA) $(TARGET).efi $(D)$(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi; \
 		elif [ "$(D)" = "$(patsubst $(shell cd $(XEN_ROOT) && pwd)/%,%,$(D))" ]; then \
 			echo 'EFI installation only partially done (EFI_VENDOR not set)' >&2; \
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 47dd6c50fe88..01ed7302202e 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -196,10 +196,7 @@ note_file_option ?= $(note_file)
 
 extra-$(XEN_BUILD_PE) += efi.lds
 ifeq ($(XEN_BUILD_PE),y)
-$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds $(obj)/efi/relocs-dummy.o $(obj)/efi/mkreloc
-ifeq ($(CONFIG_DEBUG_INFO),y)
-	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),echo,:) "Will strip debug info from $(@F)"
-endif
+$(TARGET)-syms.efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds $(obj)/efi/relocs-dummy.o $(obj)/efi/mkreloc
 	$(objtree)/tools/symbols $(all_symbols) --source-name=$(@F).S --empty \
 		> $(dot-target).0s.S
 	$(MAKE) $(build)=$(@D) .$(@F).0s.o
@@ -233,10 +230,10 @@ endif
 	$(NM) -pa --format=sysv $@ \
 		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
 		> $@.map
-ifeq ($(CONFIG_DEBUG_INFO),y)
-	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O elf64-x86-64 $@ $@.elf
-endif
 	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
+
+$(TARGET).efi: $(TARGET)-syms.efi
+	$(STRIP) $< -o $@
 ifeq ($(CONFIG_XEN_IBT),y)
 	$(SHELL) $(srctree)/tools/check-endbr.sh $@
 endif
diff --git a/xen/arch/x86/arch.mk b/xen/arch/x86/arch.mk
index cd0602a79aaf..199adc1a0967 100644
--- a/xen/arch/x86/arch.mk
+++ b/xen/arch/x86/arch.mk
@@ -95,13 +95,6 @@ EFI_LDFLAGS := $(patsubst -m%,-mi386pep,$(LDFLAGS)) --subsystem=10 --enable-long
 LD_PE_check_cmd = $(call ld-option,$(EFI_LDFLAGS) --image-base=0x100000000 -o $(efi-check).efi $(efi-check).o)
 XEN_BUILD_PE := $(LD_PE_check_cmd)
 
-# If the above failed, it may be merely because of the linker not dealing well
-# with debug info. Try again with stripping it.
-ifeq ($(CONFIG_DEBUG_INFO)-$(XEN_BUILD_PE),y-n)
-EFI_LDFLAGS += --strip-debug
-XEN_BUILD_PE := $(LD_PE_check_cmd)
-endif
-
 ifeq ($(XEN_BUILD_PE),y)
 
 # Check if the linker produces fixups in PE by default

base-commit: 37df17d2f903503c619713eb01e488f2cb1a257f
-- 
2.39.5

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

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 9916 bytes --]

On Mon, Jun 08, 2026 at 06:31:08PM +0100, Andrew Cooper wrote:
> From: Frediano Ziglio <frediano.ziglio@citrix.com>
> 
> 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.
> 
> 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.

While I see Ubuntu 16.04 dropped, how is the "require a less broken
toolchain" addressed? By implicitly disabling xen.efi build on broken
toolchain? Maybe README should have a note about needing newer Binutils
for xen.efi? Currently it says just Binutils 2.25. There is a section
about optional build deps, maybe add there something like "GNU Binutils
X.Y (required for building xen.efi)", if the version is known, or at
least "GNU Binutils capable of producing non-broken PE files (required
for building xen.efi)" if the version is not known.

> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Teddy Astie <teddy.astie@vates.tech>
> CC: Frediano Ziglio <frediano.ziglio@citrix.com>
> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> CC: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> CC: Daniel P. Smith <dpsmith@apertussolutions.com>
> 
> For 4.22.  This was posted previously as
> 
>   https://lore.kernel.org/xen-devel/20251208133945.61375-1-frediano.ziglio@citrix.com/T/#u
> 
> but merged the two patches and rewritten the commit message to make it clear
> that failing to strip xen.efi is causing boot failures.
> 
> Previously xen.efi.elf was produced but it's unclear why, and unnecessaerily
> different, so I've dropped it.
> 
> While this does want backporting, it can't be.  Xen 4.21 and older still build
> test with Ubuntu 16.04 and choke
> ---
>  .gitignore            |  1 +
>  CHANGELOG.md          |  3 +++
>  docs/misc/efi.pandoc  |  8 +-------
>  xen/Kconfig.debug     |  9 ++-------
>  xen/Makefile          | 19 -------------------
>  xen/arch/x86/Makefile | 11 ++++-------
>  xen/arch/x86/arch.mk  |  7 -------
>  7 files changed, 11 insertions(+), 47 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index bfc7bdf043c3..49e2c6961768 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -224,6 +224,7 @@ tools/flask/policy/xenpolicy-*
>  xen/xen
>  xen/suppression-list.txt
>  xen/xen-syms
> +xen/xen-syms.efi
>  xen/xen-syms.map
>  xen/xen.*
>  
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 5cf19372a361..71d1e9ab8c69 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -14,6 +14,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>   - On x86:
>     - Enable pf-fixup option by default for PVH dom0.
>     - The libxenguest bzImage loader now uses the system liblz4 library.
> +   - The install-time environment variable INSTALL_EFI_STRIP no longer exists.
> +     xen.efi is always stripped, while the symbols remain available in
> +     xen-syms.efi.
>  
>  ### Added
>   - Support for per-domain Xenstore quota in C xenstored (includes
> diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc
> index 8198a7f063cf..0a3fd67076fc 100644
> --- a/docs/misc/efi.pandoc
> +++ b/docs/misc/efi.pandoc
> @@ -20,13 +20,7 @@ Xen to load the configuration file even if multiboot modules are found.
>  Once built, `make install-xen` will place the resulting binary directly into
>  the EFI boot partition, provided `EFI_VENDOR` is set in the environment (and
>  `EFI_MOUNTPOINT` is overridden as needed, should the default of `/boot/efi` not
> -match your system). When built with debug info, the binary can be quite large.
> -Setting `INSTALL_EFI_STRIP=1` in the environment will cause it to be stripped
> -of debug info in the process of installing. `INSTALL_EFI_STRIP` can also be set
> -to any combination of options suitable to pass to `strip`, in case the default
> -ones don't do. The xen.efi binary will also be installed in `/usr/lib64/efi/`,
> -unless `EFI_DIR` is set in the environment to override this default. This
> -binary will not be stripped in the process.
> +match your system).
>  
>  The binary itself will require a configuration file (names with the `.efi`
>  extension of the binary's name replaced by `.cfg`, and - until an existing
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> index d900d926c555..fcd3fc3d36cf 100644
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -147,12 +147,7 @@ config DEBUG_INFO
>  	  Say Y here if you want to build Xen with debug information. This
>  	  information is needed e.g. for doing crash dump analysis of the
>  	  hypervisor via the "crash" tool.
> -	  Saying Y will increase the size of the xen-syms and xen.efi
> -	  binaries. In case the space on the EFI boot partition is rather
> -	  limited, you may want to install a stripped variant of xen.efi in
> -	  the EFI boot partition (look for "INSTALL_EFI_STRIP" in
> -	  docs/misc/efi.pandoc for more information - when not using
> -	  "make install-xen" for installing xen.efi, stripping needs to be
> -	  done outside the Xen build environment).
> +	  Saying Y will increase the size of the xen-syms and xen-syms.efi
> +	  binaries.
>  
>  endmenu
> diff --git a/xen/Makefile b/xen/Makefile
> index 1f11610b5f68..0f9b56fc399d 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -493,22 +493,6 @@ endif
>  .PHONY: _build
>  _build: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
>  
> -# Strip
> -#
> -# INSTALL_EFI_STRIP, if defined, will cause xen.efi to be stripped before it
> -# is installed. If INSTALL_EFI_STRIP is '1', then the default option(s) below
> -# will be used. Otherwise, INSTALL_EFI_STRIP value will be used as the
> -# option(s) to the strip command.
> -ifdef INSTALL_EFI_STRIP
> -
> -ifeq ($(INSTALL_EFI_STRIP),1)
> -efi-strip-opt := --strip-debug --keep-file-symbols
> -else
> -efi-strip-opt := $(INSTALL_EFI_STRIP)
> -endif
> -
> -endif
> -
>  .PHONY: _install
>  _install: D=$(DESTDIR)
>  _install: T=$(notdir $(TARGET))
> @@ -535,9 +519,6 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
>  		ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi; \
>  		ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T).efi; \
>  		if [ -n '$(EFI_MOUNTPOINT)' -a -n '$(EFI_VENDOR)' ]; then \
> -			$(if $(efi-strip-opt), \
> -			     $(STRIP) $(efi-strip-opt) -p -o $(TARGET).efi.stripped $(TARGET).efi && \
> -			     $(INSTALL_DATA) $(TARGET).efi.stripped $(D)$(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi ||) \
>  			$(INSTALL_DATA) $(TARGET).efi $(D)$(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi; \
>  		elif [ "$(D)" = "$(patsubst $(shell cd $(XEN_ROOT) && pwd)/%,%,$(D))" ]; then \
>  			echo 'EFI installation only partially done (EFI_VENDOR not set)' >&2; \
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index 47dd6c50fe88..01ed7302202e 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -196,10 +196,7 @@ note_file_option ?= $(note_file)
>  
>  extra-$(XEN_BUILD_PE) += efi.lds
>  ifeq ($(XEN_BUILD_PE),y)
> -$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds $(obj)/efi/relocs-dummy.o $(obj)/efi/mkreloc
> -ifeq ($(CONFIG_DEBUG_INFO),y)
> -	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),echo,:) "Will strip debug info from $(@F)"
> -endif
> +$(TARGET)-syms.efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds $(obj)/efi/relocs-dummy.o $(obj)/efi/mkreloc
>  	$(objtree)/tools/symbols $(all_symbols) --source-name=$(@F).S --empty \
>  		> $(dot-target).0s.S
>  	$(MAKE) $(build)=$(@D) .$(@F).0s.o
> @@ -233,10 +230,10 @@ endif
>  	$(NM) -pa --format=sysv $@ \
>  		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
>  		> $@.map
> -ifeq ($(CONFIG_DEBUG_INFO),y)
> -	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O elf64-x86-64 $@ $@.elf
> -endif
>  	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
> +
> +$(TARGET).efi: $(TARGET)-syms.efi
> +	$(STRIP) $< -o $@
>  ifeq ($(CONFIG_XEN_IBT),y)
>  	$(SHELL) $(srctree)/tools/check-endbr.sh $@
>  endif
> diff --git a/xen/arch/x86/arch.mk b/xen/arch/x86/arch.mk
> index cd0602a79aaf..199adc1a0967 100644
> --- a/xen/arch/x86/arch.mk
> +++ b/xen/arch/x86/arch.mk
> @@ -95,13 +95,6 @@ EFI_LDFLAGS := $(patsubst -m%,-mi386pep,$(LDFLAGS)) --subsystem=10 --enable-long
>  LD_PE_check_cmd = $(call ld-option,$(EFI_LDFLAGS) --image-base=0x100000000 -o $(efi-check).efi $(efi-check).o)
>  XEN_BUILD_PE := $(LD_PE_check_cmd)
>  
> -# If the above failed, it may be merely because of the linker not dealing well
> -# with debug info. Try again with stripping it.
> -ifeq ($(CONFIG_DEBUG_INFO)-$(XEN_BUILD_PE),y-n)
> -EFI_LDFLAGS += --strip-debug
> -XEN_BUILD_PE := $(LD_PE_check_cmd)
> -endif
> -
>  ifeq ($(XEN_BUILD_PE),y)
>  
>  # Check if the linker produces fixups in PE by default
> 
> base-commit: 37df17d2f903503c619713eb01e488f2cb1a257f
> -- 
> 2.39.5
> 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Oleksii Kurochko]

On 6/8/26 7:31 PM, Andrew Cooper wrote:
> From: Frediano Ziglio <frediano.ziglio@citrix.com>
> 
> 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.
> 
> 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.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Teddy Astie <teddy.astie@vates.tech>
> CC: Frediano Ziglio <frediano.ziglio@citrix.com>
> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> CC: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> CC: Daniel P. Smith <dpsmith@apertussolutions.com>
> 
> For 4.22.  This was posted previously as
> 
>    https://lore.kernel.org/xen-devel/20251208133945.61375-1-frediano.ziglio@citrix.com/T/#u
> 
> but merged the two patches and rewritten the commit message to make it clear
> that failing to strip xen.efi is causing boot failures.
> 
> Previously xen.efi.elf was produced but it's unclear why, and unnecessaerily
> different, so I've dropped it.
> 
> While this does want backporting, it can't be.  Xen 4.21 and older still build
> test with Ubuntu 16.04 and choke
> ---

LGTM to be in 4.22:
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

and ...

>   .gitignore            |  1 +
>   CHANGELOG.md          |  3 +++>   docs/misc/efi.pandoc  |  8 +-------
>   xen/Kconfig.debug     |  9 ++-------
>   xen/Makefile          | 19 -------------------
>   xen/arch/x86/Makefile | 11 ++++-------
>   xen/arch/x86/arch.mk  |  7 -------
>   7 files changed, 11 insertions(+), 47 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index bfc7bdf043c3..49e2c6961768 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -224,6 +224,7 @@ tools/flask/policy/xenpolicy-*
>   xen/xen
>   xen/suppression-list.txt
>   xen/xen-syms
> +xen/xen-syms.efi
>   xen/xen-syms.map
>   xen/xen.*
>   
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 5cf19372a361..71d1e9ab8c69 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -14,6 +14,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>    - On x86:
>      - Enable pf-fixup option by default for PVH dom0.
>      - The libxenguest bzImage loader now uses the system liblz4 library.
> +   - The install-time environment variable INSTALL_EFI_STRIP no longer exists.
> +     xen.efi is always stripped, while the symbols remain available in
> +     xen-syms.efi.

...
  Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> # CHANGELOG.md

Thanks.

~ Oleksii

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

[Roger Pau Monné]

On Mon, Jun 08, 2026 at 06:31:08PM +0100, Andrew Cooper wrote:
> From: Frediano Ziglio <frediano.ziglio@citrix.com>
> 
> 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.
> 
> 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.

We should then bump the minimum required GNU binutils version in the
README, as strip is also part of the binutils suite itself?

> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Teddy Astie <teddy.astie@vates.tech>
> CC: Frediano Ziglio <frediano.ziglio@citrix.com>
> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> CC: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> CC: Daniel P. Smith <dpsmith@apertussolutions.com>
> 
> For 4.22.  This was posted previously as
> 
>   https://lore.kernel.org/xen-devel/20251208133945.61375-1-frediano.ziglio@citrix.com/T/#u
> 
> but merged the two patches and rewritten the commit message to make it clear
> that failing to strip xen.efi is causing boot failures.
> 
> Previously xen.efi.elf was produced but it's unclear why, and unnecessaerily
> different, so I've dropped it.
> 
> While this does want backporting, it can't be.  Xen 4.21 and older still build
> test with Ubuntu 16.04 and choke
> ---
>  .gitignore            |  1 +
>  CHANGELOG.md          |  3 +++
>  docs/misc/efi.pandoc  |  8 +-------
>  xen/Kconfig.debug     |  9 ++-------
>  xen/Makefile          | 19 -------------------
>  xen/arch/x86/Makefile | 11 ++++-------
>  xen/arch/x86/arch.mk  |  7 -------
>  7 files changed, 11 insertions(+), 47 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index bfc7bdf043c3..49e2c6961768 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -224,6 +224,7 @@ tools/flask/policy/xenpolicy-*
>  xen/xen
>  xen/suppression-list.txt
>  xen/xen-syms
> +xen/xen-syms.efi
>  xen/xen-syms.map
>  xen/xen.*
>  
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 5cf19372a361..71d1e9ab8c69 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -14,6 +14,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>   - On x86:
>     - Enable pf-fixup option by default for PVH dom0.
>     - The libxenguest bzImage loader now uses the system liblz4 library.
> +   - The install-time environment variable INSTALL_EFI_STRIP no longer exists.
> +     xen.efi is always stripped, while the symbols remain available in
> +     xen-syms.efi.

This is not x86-only, AFAICT ARM also seems to have a rune to generate
a xen.efi image, which will be affected by the removal of
INSTALL_EFI_STRIP?

>  
>  ### Added
>   - Support for per-domain Xenstore quota in C xenstored (includes
> diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc
> index 8198a7f063cf..0a3fd67076fc 100644
> --- a/docs/misc/efi.pandoc
> +++ b/docs/misc/efi.pandoc
> @@ -20,13 +20,7 @@ Xen to load the configuration file even if multiboot modules are found.
>  Once built, `make install-xen` will place the resulting binary directly into
>  the EFI boot partition, provided `EFI_VENDOR` is set in the environment (and
>  `EFI_MOUNTPOINT` is overridden as needed, should the default of `/boot/efi` not
> -match your system). When built with debug info, the binary can be quite large.
> -Setting `INSTALL_EFI_STRIP=1` in the environment will cause it to be stripped
> -of debug info in the process of installing. `INSTALL_EFI_STRIP` can also be set
> -to any combination of options suitable to pass to `strip`, in case the default
> -ones don't do. The xen.efi binary will also be installed in `/usr/lib64/efi/`,
> -unless `EFI_DIR` is set in the environment to override this default. This
> -binary will not be stripped in the process.
> +match your system).
>  
>  The binary itself will require a configuration file (names with the `.efi`
>  extension of the binary's name replaced by `.cfg`, and - until an existing
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> index d900d926c555..fcd3fc3d36cf 100644
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -147,12 +147,7 @@ config DEBUG_INFO
>  	  Say Y here if you want to build Xen with debug information. This
>  	  information is needed e.g. for doing crash dump analysis of the
>  	  hypervisor via the "crash" tool.
> -	  Saying Y will increase the size of the xen-syms and xen.efi
> -	  binaries. In case the space on the EFI boot partition is rather
> -	  limited, you may want to install a stripped variant of xen.efi in
> -	  the EFI boot partition (look for "INSTALL_EFI_STRIP" in
> -	  docs/misc/efi.pandoc for more information - when not using
> -	  "make install-xen" for installing xen.efi, stripping needs to be
> -	  done outside the Xen build environment).
> +	  Saying Y will increase the size of the xen-syms and xen-syms.efi
> +	  binaries.
>  
>  endmenu
> diff --git a/xen/Makefile b/xen/Makefile
> index 1f11610b5f68..0f9b56fc399d 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -493,22 +493,6 @@ endif
>  .PHONY: _build
>  _build: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
>  
> -# Strip
> -#
> -# INSTALL_EFI_STRIP, if defined, will cause xen.efi to be stripped before it
> -# is installed. If INSTALL_EFI_STRIP is '1', then the default option(s) below
> -# will be used. Otherwise, INSTALL_EFI_STRIP value will be used as the
> -# option(s) to the strip command.
> -ifdef INSTALL_EFI_STRIP
> -
> -ifeq ($(INSTALL_EFI_STRIP),1)
> -efi-strip-opt := --strip-debug --keep-file-symbols
> -else
> -efi-strip-opt := $(INSTALL_EFI_STRIP)
> -endif
> -
> -endif
> -
>  .PHONY: _install
>  _install: D=$(DESTDIR)
>  _install: T=$(notdir $(TARGET))
> @@ -535,9 +519,6 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
>  		ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi; \
>  		ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T).efi; \
>  		if [ -n '$(EFI_MOUNTPOINT)' -a -n '$(EFI_VENDOR)' ]; then \
> -			$(if $(efi-strip-opt), \
> -			     $(STRIP) $(efi-strip-opt) -p -o $(TARGET).efi.stripped $(TARGET).efi && \
> -			     $(INSTALL_DATA) $(TARGET).efi.stripped $(D)$(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi ||) \
>  			$(INSTALL_DATA) $(TARGET).efi $(D)$(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi; \
>  		elif [ "$(D)" = "$(patsubst $(shell cd $(XEN_ROOT) && pwd)/%,%,$(D))" ]; then \
>  			echo 'EFI installation only partially done (EFI_VENDOR not set)' >&2; \
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index 47dd6c50fe88..01ed7302202e 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -196,10 +196,7 @@ note_file_option ?= $(note_file)
>  
>  extra-$(XEN_BUILD_PE) += efi.lds
>  ifeq ($(XEN_BUILD_PE),y)
> -$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds $(obj)/efi/relocs-dummy.o $(obj)/efi/mkreloc
> -ifeq ($(CONFIG_DEBUG_INFO),y)
> -	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),echo,:) "Will strip debug info from $(@F)"
> -endif
> +$(TARGET)-syms.efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds $(obj)/efi/relocs-dummy.o $(obj)/efi/mkreloc
>  	$(objtree)/tools/symbols $(all_symbols) --source-name=$(@F).S --empty \
>  		> $(dot-target).0s.S
>  	$(MAKE) $(build)=$(@D) .$(@F).0s.o
> @@ -233,10 +230,10 @@ endif
>  	$(NM) -pa --format=sysv $@ \
>  		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
>  		> $@.map
> -ifeq ($(CONFIG_DEBUG_INFO),y)
> -	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O elf64-x86-64 $@ $@.elf
> -endif
>  	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
> +
> +$(TARGET).efi: $(TARGET)-syms.efi
> +	$(STRIP) $< -o $@

I'm not that good with Makefiles, but don't we need a similar
adjustment to strip the .efi generated for ARM?

Thanks, Roger.

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

[Andrew Cooper]

On 08/06/2026 9:01 pm, Marek Marczykowski-Górecki wrote:
> On Mon, Jun 08, 2026 at 06:31:08PM +0100, Andrew Cooper wrote:
>> From: Frediano Ziglio <frediano.ziglio@citrix.com>
>>
>> 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.
>>
>> 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.
> While I see Ubuntu 16.04 dropped, how is the "require a less broken
> toolchain" addressed? By implicitly disabling xen.efi build on broken
> toolchain? Maybe README should have a note about needing newer Binutils
> for xen.efi? Currently it says just Binutils 2.25. There is a section
> about optional build deps, maybe add there something like "GNU Binutils
> X.Y (required for building xen.efi)", if the version is known, or at
> least "GNU Binutils capable of producing non-broken PE files (required
> for building xen.efi)" if the version is not known.

xen.efi has never had any relation to the README minimum toolchain version.

It has always probed the toolchain, and silently turned itself off it
doesn't like the result.  In this case, we drop one of the "lets work
around this bug different" checks which ends up excluding the problem
revision.

If you prefer, I could re-split the patch, and state on the first patch
that it's a prerequisite to be able to use $(STRIP) in the second patch ?

binutils' PE+ support is horribly buggy and Xen is the only user in this
area.  At some point, 2.46 (practically bleeding edge) is going to be
required, seeing as it's the first version of bintuils where we don't
need to hexedit the PE+ header in order to satisfy the signing process.

~Andrew

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

[Andrew Cooper]

On 09/06/2026 5:30 pm, Roger Pau Monné wrote:
> On Mon, Jun 08, 2026 at 06:31:08PM +0100, Andrew Cooper wrote:
>> From: Frediano Ziglio <frediano.ziglio@citrix.com>
>>
>> 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.
>>
>> 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.
> We should then bump the minimum required GNU binutils version in the
> README, as strip is also part of the binutils suite itself?
>
>> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> CC: Jan Beulich <jbeulich@suse.com>
>> CC: Roger Pau Monné <roger.pau@citrix.com>
>> CC: Teddy Astie <teddy.astie@vates.tech>
>> CC: Frediano Ziglio <frediano.ziglio@citrix.com>
>> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>> CC: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
>> CC: Daniel P. Smith <dpsmith@apertussolutions.com>
>>
>> For 4.22.  This was posted previously as
>>
>>   https://lore.kernel.org/xen-devel/20251208133945.61375-1-frediano.ziglio@citrix.com/T/#u
>>
>> but merged the two patches and rewritten the commit message to make it clear
>> that failing to strip xen.efi is causing boot failures.
>>
>> Previously xen.efi.elf was produced but it's unclear why, and unnecessaerily
>> different, so I've dropped it.
>>
>> While this does want backporting, it can't be.  Xen 4.21 and older still build
>> test with Ubuntu 16.04 and choke
>> ---
>>  .gitignore            |  1 +
>>  CHANGELOG.md          |  3 +++
>>  docs/misc/efi.pandoc  |  8 +-------
>>  xen/Kconfig.debug     |  9 ++-------
>>  xen/Makefile          | 19 -------------------
>>  xen/arch/x86/Makefile | 11 ++++-------
>>  xen/arch/x86/arch.mk  |  7 -------
>>  7 files changed, 11 insertions(+), 47 deletions(-)
>>
>> diff --git a/.gitignore b/.gitignore
>> index bfc7bdf043c3..49e2c6961768 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -224,6 +224,7 @@ tools/flask/policy/xenpolicy-*
>>  xen/xen
>>  xen/suppression-list.txt
>>  xen/xen-syms
>> +xen/xen-syms.efi
>>  xen/xen-syms.map
>>  xen/xen.*
>>  
>> diff --git a/CHANGELOG.md b/CHANGELOG.md
>> index 5cf19372a361..71d1e9ab8c69 100644
>> --- a/CHANGELOG.md
>> +++ b/CHANGELOG.md
>> @@ -14,6 +14,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>>   - On x86:
>>     - Enable pf-fixup option by default for PVH dom0.
>>     - The libxenguest bzImage loader now uses the system liblz4 library.
>> +   - The install-time environment variable INSTALL_EFI_STRIP no longer exists.
>> +     xen.efi is always stripped, while the symbols remain available in
>> +     xen-syms.efi.
> This is not x86-only, AFAICT ARM also seems to have a rune to generate
> a xen.efi image, which will be affected by the removal of
> INSTALL_EFI_STRIP?

x86 and ARM are entirely different, with x86 being the weird one.

ARM, like every other systems codebase trying to do EFI, is a raw binary
with hand-coded MZ/PE+ headers.  In our case, it's deliberately a
polygot which is both EFI and Linux zImage.

Notice how the rule is this:

$(TARGET): $(TARGET)-syms
        $(OBJCOPY) -O binary -S $< $@
ifeq ($(CONFIG_ARM_64),y)
        ln -sf $(@F) $@.efi
endif

~Andrew

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

[Roger Pau Monné]

On Mon, Jun 08, 2026 at 06:31:08PM +0100, Andrew Cooper wrote:
> From: Frediano Ziglio <frediano.ziglio@citrix.com>
> 
> 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.
> 
> 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.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.

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

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 2723 bytes --]

On Tue, Jun 09, 2026 at 05:56:10PM +0100, Andrew Cooper wrote:
> On 08/06/2026 9:01 pm, Marek Marczykowski-Górecki wrote:
> > On Mon, Jun 08, 2026 at 06:31:08PM +0100, Andrew Cooper wrote:
> >> From: Frediano Ziglio <frediano.ziglio@citrix.com>
> >>
> >> 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.
> >>
> >> 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.
> > While I see Ubuntu 16.04 dropped, how is the "require a less broken
> > toolchain" addressed? By implicitly disabling xen.efi build on broken
> > toolchain? Maybe README should have a note about needing newer Binutils
> > for xen.efi? Currently it says just Binutils 2.25. There is a section
> > about optional build deps, maybe add there something like "GNU Binutils
> > X.Y (required for building xen.efi)", if the version is known, or at
> > least "GNU Binutils capable of producing non-broken PE files (required
> > for building xen.efi)" if the version is not known.
> 
> xen.efi has never had any relation to the README minimum toolchain version.
> 
> It has always probed the toolchain, and silently turned itself off it
> doesn't like the result.  In this case, we drop one of the "lets work
> around this bug different" checks which ends up excluding the problem
> revision.

Ok, in that case

Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

> If you prefer, I could re-split the patch, and state on the first patch
> that it's a prerequisite to be able to use $(STRIP) in the second patch ?
> 
> binutils' PE+ support is horribly buggy and Xen is the only user in this
> area.  At some point, 2.46 (practically bleeding edge) is going to be
> required, seeing as it's the first version of bintuils where we don't
> need to hexedit the PE+ header in order to satisfy the signing process.
> 
> ~Andrew

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Jan Beulich]

On 08.06.2026 19:31, Andrew Cooper wrote:
> From: Frediano Ziglio <frediano.ziglio@citrix.com>
> 
> 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).

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

Jan

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

[Jan Beulich]

On 11.06.2026 16:38, Jan Beulich wrote:
> On 08.06.2026 19:31, Andrew Cooper wrote:
>> 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.

I should have added: An option may be to link twice: Once with debug info
included, and once with it stripped. Personally I trust the linker creating
the various headers, including the section ones, more than strip's (or
objcopy's). Yet then I can only repeat my observation that linking PE+ from
ELF inputs looks to be significantly slower than linking ELF -> ELF.

Jan

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

[Jan Beulich]

On 11.06.2026 16:38, Jan Beulich wrote:
> On 08.06.2026 19:31, Andrew Cooper wrote:
>> From: Frediano Ziglio <frediano.ziglio@citrix.com>
>>
>> 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.

Meanwhile it occurred to me to further ask: How would unified images work
on such systems imposing size restrictions? They're pretty likely to be
yet larger, especially if the initrd is rather big.

Jan

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

[Frediano Ziglio]

On Thu, 11 Jun 2026 at 15:42, Jan Beulich <jbeulich@suse.com> wrote:
>
> On 11.06.2026 16:38, Jan Beulich wrote:
> > On 08.06.2026 19:31, Andrew Cooper wrote:
> >> 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.
>
> I should have added: An option may be to link twice: Once with debug info
> included, and once with it stripped. Personally I trust the linker creating
> the various headers, including the section ones, more than strip's (or
> objcopy's). Yet then I can only repeat my observation that linking PE+ from
> ELF inputs looks to be significantly slower than linking ELF -> ELF.
>
> Jan
>

That was also attempted. See previous versions. And no, it does not work.

Frediano

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

[Jan Beulich]

On 16.06.2026 16:07, Frediano Ziglio wrote:
> On Thu, 11 Jun 2026 at 15:42, Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 11.06.2026 16:38, Jan Beulich wrote:
>>> On 08.06.2026 19:31, Andrew Cooper wrote:
>>>> 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.
>>
>> I should have added: An option may be to link twice: Once with debug info
>> included, and once with it stripped. Personally I trust the linker creating
>> the various headers, including the section ones, more than strip's (or
>> objcopy's). Yet then I can only repeat my observation that linking PE+ from
>> ELF inputs looks to be significantly slower than linking ELF -> ELF.
> 
> That was also attempted. See previous versions. And no, it does not work.

How exactly does it not work? When stripping debug info while linking (as
we now do for the first two passes), the resulting image should be both
small enough and correct. What am I missing? The only caveat I'm aware of
is the Eclair scan, where we should avoid doing any work for the
"auxiliary" linking step (the one not producing the binary that's actually
going to be used for running Xen).

Jan

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

[Frediano Ziglio]

On Thu, 11 Jun 2026 at 16:18, Jan Beulich <jbeulich@suse.com> wrote:
>
> On 08.06.2026 19:31, Andrew Cooper wrote:
> > From: Frediano Ziglio <frediano.ziglio@citrix.com>
> >
> > 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

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

[Frediano Ziglio]

On Tue, 16 Jun 2026 at 15:15, Jan Beulich <jbeulich@suse.com> wrote:
>
> On 16.06.2026 16:07, Frediano Ziglio wrote:
> > On Thu, 11 Jun 2026 at 15:42, Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 11.06.2026 16:38, Jan Beulich wrote:
> >>> On 08.06.2026 19:31, Andrew Cooper wrote:
> >>>> 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.
> >>
> >> I should have added: An option may be to link twice: Once with debug info
> >> included, and once with it stripped. Personally I trust the linker creating
> >> the various headers, including the section ones, more than strip's (or
> >> objcopy's). Yet then I can only repeat my observation that linking PE+ from
> >> ELF inputs looks to be significantly slower than linking ELF -> ELF.
> >
> > That was also attempted. See previous versions. And no, it does not work.
>
> How exactly does it not work? When stripping debug info while linking (as
> we now do for the first two passes), the resulting image should be both
> small enough and correct. What am I missing? The only caveat I'm aware of
> is the Eclair scan, where we should avoid doing any work for the
> "auxiliary" linking step (the one not producing the binary that's actually
> going to be used for running Xen).
>
> Jan

One thing I remember was the build-id was not the same and debugging
tools could not work.

Frediano

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

[Frediano Ziglio]

On Tue, 16 Jun 2026 at 15:28, Frediano Ziglio <freddy77@gmail.com> wrote:
>
> On Tue, 16 Jun 2026 at 15:15, Jan Beulich <jbeulich@suse.com> wrote:
> >
> > On 16.06.2026 16:07, Frediano Ziglio wrote:
> > > On Thu, 11 Jun 2026 at 15:42, Jan Beulich <jbeulich@suse.com> wrote:
> > >>
> > >> On 11.06.2026 16:38, Jan Beulich wrote:
> > >>> On 08.06.2026 19:31, Andrew Cooper wrote:
> > >>>> 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.
> > >>
> > >> I should have added: An option may be to link twice: Once with debug info
> > >> included, and once with it stripped. Personally I trust the linker creating
> > >> the various headers, including the section ones, more than strip's (or
> > >> objcopy's). Yet then I can only repeat my observation that linking PE+ from
> > >> ELF inputs looks to be significantly slower than linking ELF -> ELF.
> > >
> > > That was also attempted. See previous versions. And no, it does not work.
> >
> > How exactly does it not work? When stripping debug info while linking (as
> > we now do for the first two passes), the resulting image should be both
> > small enough and correct. What am I missing? The only caveat I'm aware of
> > is the Eclair scan, where we should avoid doing any work for the
> > "auxiliary" linking step (the one not producing the binary that's actually
> > going to be used for running Xen).
> >
> > Jan
>
> One thing I remember was the build-id was not the same and debugging
> tools could not work.
>

Another reason was that the generated binary with debug information
was not working with various tools anyway (gdb complained about it and
also binutils again for converting to ELF to use other tools like I
think live patching).
About this I'm less sure about.

Frediano

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

[Jan Beulich]

On 16.06.2026 16:28, Frediano Ziglio wrote:
> On Tue, 16 Jun 2026 at 15:15, Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 16.06.2026 16:07, Frediano Ziglio wrote:
>>> On Thu, 11 Jun 2026 at 15:42, Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 11.06.2026 16:38, Jan Beulich wrote:
>>>>> On 08.06.2026 19:31, Andrew Cooper wrote:
>>>>>> 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.
>>>>
>>>> I should have added: An option may be to link twice: Once with debug info
>>>> included, and once with it stripped. Personally I trust the linker creating
>>>> the various headers, including the section ones, more than strip's (or
>>>> objcopy's). Yet then I can only repeat my observation that linking PE+ from
>>>> ELF inputs looks to be significantly slower than linking ELF -> ELF.
>>>
>>> That was also attempted. See previous versions. And no, it does not work.
>>
>> How exactly does it not work? When stripping debug info while linking (as
>> we now do for the first two passes), the resulting image should be both
>> small enough and correct. What am I missing? The only caveat I'm aware of
>> is the Eclair scan, where we should avoid doing any work for the
>> "auxiliary" linking step (the one not producing the binary that's actually
>> going to be used for running Xen).
> 
> One thing I remember was the build-id was not the same and debugging
> tools could not work.

Hmm, yes, that's a little ugly, but can likely be dealt with by using
--build-id=0x<hexdigits> to replicate the build-id that was generated for
the main binary.

Jan

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

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 2495 bytes --]

On Wed, Jun 17, 2026 at 01:55:59PM +0200, Jan Beulich wrote:
> On 16.06.2026 16:28, Frediano Ziglio wrote:
> > On Tue, 16 Jun 2026 at 15:15, Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 16.06.2026 16:07, Frediano Ziglio wrote:
> >>> On Thu, 11 Jun 2026 at 15:42, Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 11.06.2026 16:38, Jan Beulich wrote:
> >>>>> On 08.06.2026 19:31, Andrew Cooper wrote:
> >>>>>> 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.
> >>>>
> >>>> I should have added: An option may be to link twice: Once with debug info
> >>>> included, and once with it stripped. Personally I trust the linker creating
> >>>> the various headers, including the section ones, more than strip's (or
> >>>> objcopy's). Yet then I can only repeat my observation that linking PE+ from
> >>>> ELF inputs looks to be significantly slower than linking ELF -> ELF.
> >>>
> >>> That was also attempted. See previous versions. And no, it does not work.
> >>
> >> How exactly does it not work? When stripping debug info while linking (as
> >> we now do for the first two passes), the resulting image should be both
> >> small enough and correct. What am I missing? The only caveat I'm aware of
> >> is the Eclair scan, where we should avoid doing any work for the
> >> "auxiliary" linking step (the one not producing the binary that's actually
> >> going to be used for running Xen).
> > 
> > One thing I remember was the build-id was not the same and debugging
> > tools could not work.
> 
> Hmm, yes, that's a little ugly, but can likely be dealt with by using
> --build-id=0x<hexdigits> to replicate the build-id that was generated for
> the main binary.

IMO linking twice (with and without debug symbols) has a great risk
potential of producing different layout of the binary. While arguably it
would be a bug in the build scripts, it doesn't matter with strip
approach (used by virtually every other project I've seen).

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Jan Beulich]

On 17.06.2026 14:07, Marek Marczykowski-Górecki wrote:
> On Wed, Jun 17, 2026 at 01:55:59PM +0200, Jan Beulich wrote:
>> On 16.06.2026 16:28, Frediano Ziglio wrote:
>>> On Tue, 16 Jun 2026 at 15:15, Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 16.06.2026 16:07, Frediano Ziglio wrote:
>>>>> On Thu, 11 Jun 2026 at 15:42, Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 11.06.2026 16:38, Jan Beulich wrote:
>>>>>>> On 08.06.2026 19:31, Andrew Cooper wrote:
>>>>>>>> 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.
>>>>>>
>>>>>> I should have added: An option may be to link twice: Once with debug info
>>>>>> included, and once with it stripped. Personally I trust the linker creating
>>>>>> the various headers, including the section ones, more than strip's (or
>>>>>> objcopy's). Yet then I can only repeat my observation that linking PE+ from
>>>>>> ELF inputs looks to be significantly slower than linking ELF -> ELF.
>>>>>
>>>>> That was also attempted. See previous versions. And no, it does not work.
>>>>
>>>> How exactly does it not work? When stripping debug info while linking (as
>>>> we now do for the first two passes), the resulting image should be both
>>>> small enough and correct. What am I missing? The only caveat I'm aware of
>>>> is the Eclair scan, where we should avoid doing any work for the
>>>> "auxiliary" linking step (the one not producing the binary that's actually
>>>> going to be used for running Xen).
>>>
>>> One thing I remember was the build-id was not the same and debugging
>>> tools could not work.
>>
>> Hmm, yes, that's a little ugly, but can likely be dealt with by using
>> --build-id=0x<hexdigits> to replicate the build-id that was generated for
>> the main binary.
> 
> IMO linking twice (with and without debug symbols) has a great risk
> potential of producing different layout of the binary. While arguably it
> would be a bug in the build scripts,

Indeed, as it would further undermine reproducible builds. That said, we
could certainly put some (a lot of?) sanity checking in place.

> it doesn't matter with strip
> approach (used by virtually every other project I've seen).

Yet I expect that's "strip" on ELF binaries, not PE ones?

Jan