On 20/03/2025 10:18 am, Jan Beulich wrote: > 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.
https://www.kraxel.org/blog/2023/12/uefi-nx-linux-boot/ ~Andrew
