[PATCH for-4.22?] x86/EFI: arrange for non-discardable .reloc in xen.efi

[PATCH for-4.22?] x86/EFI: arrange for non-discardable .reloc in xen.efi

[Jan Beulich]

Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections,
yet we need to access it ourselves when switching out of "physical mode".
Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which
doesn't have the discardable flag set (which cannot even be expressed in
ELF) will yield the output section also non-discardable.

Since for intermediate binaries we don't care about section attributes,
link in the new object only on the final linking pass.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
With a new enough linker, $(dot-target).2r.o could be leveraged instead:
$(dot-target).2r.S is going to be empty (or if it's not, the .reloc
section there would already have the wanted property), so instead of
adding the new relocs-empty.S we could also insert the section directive
there. Overall that seemed more convoluted to me, though.

--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -196,7 +196,8 @@ 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
+$(TARGET).efi: $(obj)/efi/relocs-dummy.o $(obj)/efi/relocs-empty.o $(obj)/efi/mkreloc
+$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds
 ifeq ($(CONFIG_DEBUG_INFO),y)
 	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),echo,:) "Will strip debug info from $(@F)"
 endif
@@ -227,7 +228,7 @@ endif
 	$(MAKE) $(build)=$(@D) .$(@F).2r.o .$(@F).2s.o
 	$(call compare-symbol-tables, $(dot-target).1r.o, $(dot-target).2r.o)
 	$(call compare-symbol-tables, $(dot-target).1s.o, $(dot-target).2s.o)
-	$(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< \
+	$(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< $(obj)/efi/relocs-empty.o \
 	      $(dot-target).2r.o $(dot-target).2s.o $(orphan-handling-y) \
 	      $(note_file_option) -o $@
 	$(NM) -pa --format=sysv $@ \
@@ -247,7 +248,7 @@ $(TARGET).efi: FORCE
 endif
 
 # These should already have been rebuilt when building the prerequisite of "prelink.o"
-$(obj)/efi/buildid.o $(obj)/efi/relocs-dummy.o: ;
+$(obj)/efi/buildid.o $(obj)/efi/relocs-dummy.o $(obj)/efi/relocs-empty.o: ;
 
 .PHONY: include
 include: $(objtree)/arch/x86/include/asm/asm-macros.h
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -17,5 +17,5 @@ obj-y := common-stub.o stub.o
 obj-$(XEN_BUILD_EFI) := $(filter-out %.init.o,$(EFIOBJ-y))
 obj-bin-$(XEN_BUILD_EFI) := $(filter %.init.o,$(EFIOBJ-y))
 obj-bin-y += mbi2.init.o
-extra-$(XEN_BUILD_EFI) += buildid.o relocs-dummy.o
+extra-$(XEN_BUILD_EFI) += buildid.o relocs-dummy.o relocs-empty.o
 nocov-$(XEN_BUILD_EFI) += stub.o
--- /dev/null
+++ b/xen/arch/x86/efi/relocs-empty.S
@@ -0,0 +1,8 @@
+/*
+ * Empty .reloc section, simply to indicate to GNU ld that the output .reloc
+ * section in xen.efi should not be marked IMAGE_SCN_MEM_DISCARDABLE.  This
+ * requires GNU ld 2.46 or newer to actually be understood in the intended way.
+ */
+
+	.section .reloc, "a", @progbits
+	.balign 4

Re: [PATCH for-4.22?] x86/EFI: arrange for non-discardable .reloc in xen.efi

[Roger Pau Monné]

On Tue, Jun 16, 2026 at 06:17:54PM +0200, Jan Beulich wrote:
> Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections,
> yet we need to access it ourselves when switching out of "physical mode".
> Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which
> doesn't have the discardable flag set (which cannot even be expressed in
> ELF) will yield the output section also non-discardable.
> 
> Since for intermediate binaries we don't care about section attributes,
> link in the new object only on the final linking pass.

I'm not sure I follow.  Xen already does generate a custom .reloc
section without the IMAGE_SCN_MEM_DISCARDABLE attribute when using
the mkreloc utility, and hence the .reloc section should never be
marked as discardable?

Thanks, Roger.

Re: [PATCH for-4.22?] x86/EFI: arrange for non-discardable .reloc in xen.efi

[Jan Beulich]

On 17.06.2026 12:29, Roger Pau Monné wrote:
> On Tue, Jun 16, 2026 at 06:17:54PM +0200, Jan Beulich wrote:
>> Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections,
>> yet we need to access it ourselves when switching out of "physical mode".
>> Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which
>> doesn't have the discardable flag set (which cannot even be expressed in
>> ELF) will yield the output section also non-discardable.
>>
>> Since for intermediate binaries we don't care about section attributes,
>> link in the new object only on the final linking pass.
> 
> I'm not sure I follow.  Xen already does generate a custom .reloc
> section without the IMAGE_SCN_MEM_DISCARDABLE attribute when using
> the mkreloc utility, and hence the .reloc section should never be
> marked as discardable?

mkreloc is used only when we recognize the linker to be incapable of
producing (correct) base relocations. As a modern linker is required for
the desired IMAGE_SCN_MEM_DISCARDABLE handling for .reloc, mkreloc
wouldn't normally be used there. Hence no .reloc section with the wanted
property.

Jan

Re: [PATCH for-4.22?] x86/EFI: arrange for non-discardable .reloc in xen.efi

[Roger Pau Monné]

On Wed, Jun 17, 2026 at 12:37:38PM +0200, Jan Beulich wrote:
> On 17.06.2026 12:29, Roger Pau Monné wrote:
> > On Tue, Jun 16, 2026 at 06:17:54PM +0200, Jan Beulich wrote:
> >> Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections,
> >> yet we need to access it ourselves when switching out of "physical mode".
> >> Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which
> >> doesn't have the discardable flag set (which cannot even be expressed in
> >> ELF) will yield the output section also non-discardable.
> >>
> >> Since for intermediate binaries we don't care about section attributes,
> >> link in the new object only on the final linking pass.
> > 
> > I'm not sure I follow.  Xen already does generate a custom .reloc
> > section without the IMAGE_SCN_MEM_DISCARDABLE attribute when using
> > the mkreloc utility, and hence the .reloc section should never be
> > marked as discardable?
> 
> mkreloc is used only when we recognize the linker to be incapable of
> producing (correct) base relocations. As a modern linker is required for
> the desired IMAGE_SCN_MEM_DISCARDABLE handling for .reloc, mkreloc
> wouldn't normally be used there. Hence no .reloc section with the wanted
> property.

I see, MKRELOC becomes ":" then, I didn't catch that.

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

Thanks, Roger.

Re: [PATCH for-4.22?] x86/EFI: arrange for non-discardable .reloc in xen.efi

[Andrew Cooper]

On 17/06/2026 11:37 am, Jan Beulich wrote:
> On 17.06.2026 12:29, Roger Pau Monné wrote:
>> On Tue, Jun 16, 2026 at 06:17:54PM +0200, Jan Beulich wrote:
>>> Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections,
>>> yet we need to access it ourselves when switching out of "physical mode".
>>> Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which
>>> doesn't have the discardable flag set (which cannot even be expressed in
>>> ELF) will yield the output section also non-discardable.
>>>
>>> Since for intermediate binaries we don't care about section attributes,
>>> link in the new object only on the final linking pass.
>> I'm not sure I follow.  Xen already does generate a custom .reloc
>> section without the IMAGE_SCN_MEM_DISCARDABLE attribute when using
>> the mkreloc utility, and hence the .reloc section should never be
>> marked as discardable?
> mkreloc is used only when we recognize the linker to be incapable of
> producing (correct) base relocations.

I wasn't even aware of that behaviour.

So we've got even more completely undocumented and obscure toolchain
restrictions and behaviours.

What else?  It needs at least enumerating somewhere so people stand a
chance of being able figure out which toolstack they need in order to
get a functioning xen.efi.

I'm going to insist that a doc happens, and that this patch patches it
adding in the Binutils 2.46 requirement.

But I'll write the doc if you can summarise the other checks I'm not
aware of.

~Andrew

Re: [PATCH for-4.22?] x86/EFI: arrange for non-discardable .reloc in xen.efi

[Jan Beulich]

On 17.06.2026 13:20, Andrew Cooper wrote:
> On 17/06/2026 11:37 am, Jan Beulich wrote:
>> On 17.06.2026 12:29, Roger Pau Monné wrote:
>>> On Tue, Jun 16, 2026 at 06:17:54PM +0200, Jan Beulich wrote:
>>>> Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections,
>>>> yet we need to access it ourselves when switching out of "physical mode".
>>>> Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which
>>>> doesn't have the discardable flag set (which cannot even be expressed in
>>>> ELF) will yield the output section also non-discardable.
>>>>
>>>> Since for intermediate binaries we don't care about section attributes,
>>>> link in the new object only on the final linking pass.
>>> I'm not sure I follow.  Xen already does generate a custom .reloc
>>> section without the IMAGE_SCN_MEM_DISCARDABLE attribute when using
>>> the mkreloc utility, and hence the .reloc section should never be
>>> marked as discardable?
>> mkreloc is used only when we recognize the linker to be incapable of
>> producing (correct) base relocations.
> 
> I wasn't even aware of that behaviour.
> 
> So we've got even more completely undocumented and obscure toolchain
> restrictions and behaviours.
> 
> What else?  It needs at least enumerating somewhere so people stand a
> chance of being able figure out which toolstack they need in order to
> get a functioning xen.efi.

The two ways of generating relocations exist to allow people to build a
functioning xen.efi irrespective of GNU ld version used. Hence it's not
quite clear to me ...

> I'm going to insist that a doc happens, and that this patch patches it
> adding in the Binutils 2.46 requirement.
> 
> But I'll write the doc if you can summarise the other checks I'm not
> aware of.

... what exactly you want to document. The change here is towards
secure boot support; outside of that xen.efi is operating okay in this
regard, afaik. The first paragraph of docs/misc/efi.pandoc could do
with an update (as the version restrictions are now obsolete), but it
was my understanding that the secure boot related aspects all would
live in a new, to be created doc (which iirc you already have in flight).

Besides the .reloc filling, the other check we have is for whether to
include debug info. As with the documentation on toolchain versions
required, the MS ABI check could likely be dropped now as well. Otoh
the "linker supports PE" check of course needs to remain.

Jan

Re: [PATCH for-4.22?] x86/EFI: arrange for non-discardable .reloc in xen.efi

[Oleksii Kurochko]

On 6/16/26 6:17 PM, Jan Beulich wrote:
> Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections,
> yet we need to access it ourselves when switching out of "physical mode".
> Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which
> doesn't have the discardable flag set (which cannot even be expressed in
> ELF) will yield the output section also non-discardable.
> 
> Since for intermediate binaries we don't care about section attributes,
> link in the new object only on the final linking pass.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii