Re: [PATCH v2] xen/x86: fix xen.efi boot crash from some bootloaders

["Yann Sionneau" <yann.sionneau@xxxxxxxxxx>]

On 10/13/25 13:41, Jan Beulich wrote:
> On 25.08.2025 16:29, Jan Beulich wrote:
>> On 25.08.2025 16:17, Yann Sionneau wrote:
>>> On 8/4/25 11:34, Jan Beulich wrote:
>>>> On 24.07.2025 16:07, 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-ac3f03607d5a@xxxxxxxx/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.sionneau@xxxxxxxxxx>
>>>>
>>>> So I found a way to deal with this at the linker side, without any new 
>>>> command
>>>> line options. Behavior is solely driven by the attributes of any incoming 
>>>> .reloc
>>>> sections (of which there would be none by default, retaining original 
>>>> behavior).
>>>> The important patch is [1], but at least the first patch of the series [2] 
>>>> would
>>>> in most cases also be wanted/needed (patch 04 is obviously a mechanical 
>>>> prereq
>>>> for the main patch). Need for other of the prereqs there depends on the 
>>>> scope
>>>> and purpose of one's binutils build(s).
>>>>
>>>> [1] https://sourceware.org/pipermail/binutils/2025-August/143153.html
>>>> [2] https://sourceware.org/pipermail/binutils/2025-August/143141.html
>>>
>>> That sounds great!
>>> It's clearly better to fix the issue by changing/improving binutils.
>>> Let's drop my patch in Xen if this gets accepted in binutils!
>>
>> Luckily I'm in a position where I don't need "acceptance", but merely
>> "absence of objections". The sole reason for the present delay is with
>> a colliding MIPS patch, which I'd rather see go in first.
>>
>>> It would be nice if you could keep us posted in xen-devel of the
>>> status/progress of the binutils patches.
>>
>> I'll try to remember.
> 
> Here you go - the series went in late last week.
> 
> Jan
> 

Thanks Jan :)

-- 


--
Yann Sionneau | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech