On 20.03.2025 10:53, Jan Beulich wrote: > On 20.03.2025 09:34, Jan Beulich wrote: >> On 20.03.2025 09:14, Roger Pau Monné wrote: >>> 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? >> >> Possible. And that would be in line with the mode being call "physical mode": >> There are no permissions to enforce there. It just so happens that x86-64 >> requires paging to be enabled to be able to run 64-bit code. >> >> My experience with OVMF has been that it's hard to find where certain code >> lives. Perhaps I should try whether I can find respective code there. Then >> again if I find nothing, there wouldn't be any guarantee that I merely didn't >> spot the right place. > > All I can find is > BaseTools/Source/C/Common/BasePeCoff.c:PeCoffLoaderLoadImage(), > which doesn't look to care about section flags at all.
And then there is at least one duplicate thereof elsewhere, or something very close to a duplicate. In addition I meanwhile found ProtectUefiImage(), yet it's unclear (to me) under what conditions execution would make it there. Plus it leading to SetUefiImageMemoryAttributes() leaves open where gCpu->SetMemoryAttributes() is implemented. I can spot some Arm and RISC-V code with respective names (albeit in distinct places), and MTRR functionality with names along these lines. None of these can be it. Jan
