On 23/07/2025 2:56 pm, Yann Sionneau wrote: > xen.efi PE does not boot when loaded from shim or some patched > downstream grub2. > > What happens is the bootloader would honour the MEM_DISCARDABLE > flag of the .reloc section meaning it would not load its content > into memory. > > But Xen is parsing the .reloc section content twice at boot: > * https://elixir.bootlin.com/xen/v4.20.1/source/xen/common/efi/boot.c#L1362 > * > https://elixir.bootlin.com/xen/v4.20.1/source/xen/arch/x86/efi/efi-boot.h#L237 > > Therefore it would crash with the following message: > "Unsupported relocation type" as reported there: > > * https://github.com/QubesOS/qubes-issues/issues/8206#issuecomment-2619048838 > * > https://lore.kernel.org/xen-devel/7e039262-1f54-46e1-8f70-ac3f03607...@suse.com/T/#me122b9e6c27cd98db917da2c9f67e74a2c6ad7a5 > > This commit adds a small C host tool named keeprelocs > that is called after xen.efi is produced by the build system > in order to remove this bit from its .reloc section header. > > Signed-off-by: Yann Sionneau <yann.sionn...@vates.tech> > --- > xen/Makefile | 5 +- > xen/arch/x86/Makefile | 1 + > xen/tools/Makefile | 3 ++ > xen/tools/keeprelocs.c | 119 +++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 127 insertions(+), 1 deletion(-) > create mode 100644 xen/tools/keeprelocs.c
I'm sick and tired of the hoops we have to jump through for broken tooling. This is now rewriting the PE+ metadata because apparently the linker can't do it correctly. Either fix the linker (or the way we drive it/etc), or we're doing away with PE+ emulation entirely and writing the MZ/PE headers by hand like literally every other kernel does. This is a level of technical debt I consider unreasonable to take. Also, note that your analysis points at a common code file, yet this is an x86-specific bodge. ~Andrew
