The trampoline code is never executed in the position placed by the
loader.  It's first copied to the low 1MB, and always executed from
there.

Move the trampoline code from being in .init.text section into
.init.data, so it's not in an executable section.  This allows applying
the relocations safely against a non-executable (and thus non-read only)
section, and then copy the relocated trampoline to the low 1MB.  Note
that the trampoline code is placed on an .init section, so zapped after
boot has finished.

No functional change intended.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
An alternative approach is to apply the relocations after having copied the
trampoline to the low 1MB, but that still generates relocations in mkreloc,
which is not helpful for the goal of having no relocations applied to
read-execute code sections.  This approach however places code in a data
section, which might cause issues when debugging it.
---
 xen/arch/x86/boot/head.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 774894954e44..f5a2d08d0d0e 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -709,7 +709,7 @@ trampoline_setup:
         /* Jump into the relocated trampoline. */
         lret
 
-        .section .init.text, "ax", @progbits
+        .section .init.data, "aw", @progbits
 ENTRY(trampoline_start)
 #include "trampoline.S"
 ENTRY(trampoline_end)
-- 
2.48.1

On 01/04/2025 2:08 pm, Roger Pau Monne wrote:
> The trampoline code is never executed in the position placed by the
> loader.  It's first copied to the low 1MB, and always executed from
> there.
>
> Move the trampoline code from being in .init.text section into
> .init.data, so it's not in an executable section.  This allows applying
> the relocations safely against a non-executable (and thus non-read only)
> section, and then copy the relocated trampoline to the low 1MB.  Note
> that the trampoline code is placed on an .init section, so zapped after
> boot has finished.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> An alternative approach is to apply the relocations after having copied the
> trampoline to the low 1MB, but that still generates relocations in mkreloc,
> which is not helpful for the goal of having no relocations applied to
> read-execute code sections.  This approach however places code in a data
> section, which might cause issues when debugging it.

I, probably most of all, spend a reasonable amount of time disassembling
the trampoline. I really would prefer to keep it in an executable section.

What are the options with relocations?  Can't we simply drop any in the
trampoline region?

~Andrew

On 01.04.2025 15:49, Andrew Cooper wrote:
> On 01/04/2025 2:08 pm, Roger Pau Monne wrote:
>> The trampoline code is never executed in the position placed by the
>> loader.  It's first copied to the low 1MB, and always executed from
>> there.
>>
>> Move the trampoline code from being in .init.text section into
>> .init.data, so it's not in an executable section.  This allows applying
>> the relocations safely against a non-executable (and thus non-read only)
>> section, and then copy the relocated trampoline to the low 1MB.  Note
>> that the trampoline code is placed on an .init section, so zapped after
>> boot has finished.
>>
>> No functional change intended.
>>
>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>> ---
>> An alternative approach is to apply the relocations after having copied the
>> trampoline to the low 1MB, but that still generates relocations in mkreloc,
>> which is not helpful for the goal of having no relocations applied to
>> read-execute code sections.  This approach however places code in a data
>> section, which might cause issues when debugging it.
> 
> I, probably most of all, spend a reasonable amount of time disassembling
> the trampoline. I really would prefer to keep it in an executable section.
> 
> What are the options with relocations?  Can't we simply drop any in the
> trampoline region?

That's perhaps an option with mkreloc, but would require zapping them after
linking if we have the linker produce relocations. Doable, but likely not
to end up being pretty.

Jan