From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH 5/7] x86/mkreloc: remove warning about relocations to RO section
Date: Thu, 20 Mar 2025 09:14:43 +0100 [thread overview]
Message-ID: <Z9vOc5I828aV49rI@macbook.local> (raw)
In-Reply-To: <27ebf169-ab63-4def-a98b-751ae1758293@suse.com>
On Wed, Mar 19, 2025 at 11:46:22AM +0100, Jan Beulich wrote:
> On 19.03.2025 11:32, Jan Beulich wrote:
> > On 18.03.2025 18:35, Roger Pau Monne wrote:
> >> Relocations are now applied after having moved the trampoline,
> >
> > That's two entirely different sets of relocations, isn't it?
Right, this is the plain .reloc, while the trampoline one is
.trampoline_{rel,seg}
> > What we generate
> > here is what is to be encoded in the PE binary's .reloc section, for the PE
> > loader to process. And for us to then process again once we move Xen back to
> > its linked position (by virtue of leaving physical mode). Therefore what
> > matters here is whether these relocations are still carried out while on the
> > page tables to boot loader created, or when already on page tables we control.
> > In the former case any relocation to a non-writable section would be liable
> > to fault when applied.
>
> And yes - both calls to efi_arch_relocate_image() are ahead of switching page
> tables. The first call is benign - no writes occur there. The second call
> would cause #PF though for any relocs applied to .text or .rodata or .init.text
> or whatever else is non-writable.
I wonder how this worked then, as I've tested with the xen.efi smoke
test in gitlab CI. Maybe ovmf doesn't acknowledge the RX sections and
unconditionally sets all mappings as writable?
Thanks, Roger.
next prev parent reply other threads:[~2025-03-20 8:15 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-18 17:35 [PATCH 0/7] x86: generate xen.efi image with no write-execute sections Roger Pau Monne
2025-03-18 17:35 ` [PATCH 1/7] x86/boot: clarify comment about trampoline_setup usage Roger Pau Monne
2025-03-18 17:45 ` Andrew Cooper
2025-03-19 8:46 ` Roger Pau Monné
2025-03-19 12:22 ` Andrew Cooper
2025-03-18 17:35 ` [PATCH 2/7] x86/mkelf32: account for offset when detecting note segment placement Roger Pau Monne
2025-03-18 17:45 ` Andrew Cooper
2025-03-19 10:07 ` Jan Beulich
2025-03-19 14:16 ` Roger Pau Monné
2025-03-19 14:33 ` Jan Beulich
2025-03-18 17:35 ` [PATCH 3/7] xen: remove -N from the linker command line Roger Pau Monne
2025-03-18 17:53 ` Andrew Cooper
2025-03-19 10:20 ` Jan Beulich
2025-03-21 16:28 ` Oleksii Kurochko
2025-03-18 17:35 ` [PATCH 4/7] x86/boot: apply trampoline relocations at destination position Roger Pau Monne
2025-03-18 19:05 ` Frediano Ziglio
2025-03-18 19:17 ` Andrew Cooper
2025-03-19 12:00 ` Frediano Ziglio
2025-03-18 20:10 ` [PATCH] x86/boot: Untangle the trampoline copying/entry logic Andrew Cooper
2025-03-19 9:05 ` Roger Pau Monné
2025-03-20 13:59 ` Andrew Cooper
2025-03-18 20:14 ` [PATCH 4/7] x86/boot: apply trampoline relocations at destination position Andrew Cooper
2025-03-18 17:35 ` [PATCH 5/7] x86/mkreloc: remove warning about relocations to RO section Roger Pau Monne
2025-03-18 18:14 ` Andrew Cooper
2025-03-19 10:32 ` Jan Beulich
2025-03-19 10:46 ` Jan Beulich
2025-03-19 10:53 ` Jan Beulich
2025-03-20 8:14 ` Roger Pau Monné [this message]
2025-03-20 8:34 ` Jan Beulich
2025-03-20 9:53 ` Jan Beulich
2025-03-20 10:18 ` Jan Beulich
2025-03-20 11:00 ` Andrew Cooper
2025-03-20 11:11 ` Jan Beulich
2025-03-18 17:35 ` [PATCH 6/7] x86/efi: do not merge all .init sections Roger Pau Monne
2025-03-18 18:08 ` Andrew Cooper
2025-03-19 10:39 ` Jan Beulich
2025-03-18 17:35 ` [PATCH 7/7] xen/build: warn about RWX load segments Roger Pau Monne
2025-03-18 18:07 ` Andrew Cooper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z9vOc5I828aV49rI@macbook.local \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=dpsmith@apertussolutions.com \
--cc=jbeulich@suse.com \
--cc=marmarek@invisiblethingslab.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.