On Thu, Aug 8, 2024 at 9:54 AM Jan Beulich <jbeul...@suse.com> wrote:
>
> On 08.08.2024 10:00, Frediano Ziglio wrote:
> > On Thu, Aug 8, 2024 at 8:34 AM Jan Beulich <jbeul...@suse.com> wrote:
> >>
> >> On 07.08.2024 15:48, Alejandro Vallejo wrote:
> >>> This change allows to put the trampoline in a separate, not executable
> >>> section. The trampoline contains a mix of code and data (data which
> >>> is modified from C code during early start so must be writable).
> >>> This is in preparation for W^X patch in order to satisfy UEFI CA
> >>> memory mitigation requirements.
> >>
> >> Which, aiui, has the downside of disassembly of the section no longer
> >> happening by default, when using objdump or similar tools, which go from
> >> section attributes. Why is it being in .init.text (and hence RX) not
> >> appropriate? It should - in principle at least - be possible to avoid
> >> all in-place writing to it, but instead only ever write to its relocated
> >> copy. Quite a bit more code churn of course.
> >>
> >> I wonder if we shouldn't put the trampoline in its own section, RWX in
> >> the object file, and switched to whatever appropriate in the binary
> >> (which really may be RX, not RW).
> >
> > We cannot have RWX to satisfy UEFI CA memory mitigation, that's why I
> > had to move it, code sections should not be writeable. We can mark
> > either RX or RW but we use the data very early so we are not able to
> > change the permissions (we can try with all complications that this
> > could bring like how to report an error at so early stages).
>
> The early writing could be done away with, as indicated. There's not
> really any strict requirement to write to the trampoline region within
> the Xen image. All updates to it could in principle be done after it
> was copied into low memory. Then (and of course only then) could it be
> part of an RX section in the image, maybe .init.text, maybe a separate
> .trampoline section.
>
> Jan
Hi Jan,
how strong are you on this? Is this "objdump" thing such a big
issue? The code contains a lot of 16 bit code which would require
additional options anyway. Won't be an assembly listing output more
helpful instead?
I tried to change the code to change only the final copy of the
trampoline but it looks like lot of code assumes it can change the
source of it (that is requiring it to be in a writeable section). For
instance EFI change settings directly and then allocate space for the
copy later. The allocation could be moved but there's a fallback on
code that assumes that early allocation can fail.
The trampoline relocation is done with PC relative addressing which is
helpful if you are changing the source directly, not the copy.
Could I ouput the trampoline in a code section ("ax" instead of "aw")
and then later move it into .init.data section assuring .init.data is
writeable but not executable?
Frediano
