On Thu, Mar 03, 2022 at 04:42:07PM +0300, baskov@xxxxxxxxx wrote: > On 2022-02-28 21:30, Matthew Garrett wrote: > > On Mon, Feb 28, 2022 at 05:45:53PM +0100, Ard Biesheuvel wrote: > > > > > Given that this is a workaround for a very specific issue arising on > > > PI based implementations of UEFI, I consider this a quirk, and so I > > > think this approach is reasonable. I'd still like to gate it on some > > > kind of identification, though - perhaps something related to DMI like > > > the x86 core kernel does as well. > > > > When the V1 patches were reviewed, you suggested allocating > > EFI_LOADER_CODE rather than EFI_LOADER_DATA. The example given for a > > failure case is when NxMemoryProtectionPolicy is set to 0x7fd4, in which > > case EFI_LOADER_CODE, EFI_BOOT_SERVICES_CODE and > > EFI_RUNTIEM_SERVICES_CODE should not have the nx policy applied. So it > > seems like your initial suggestion (s/LOADER_DATA/LOADER_CODE/) should > > have worked, even if there was disagreement about whether the spec > > required it to. Is this firmware applying a stricter policy? > > Yes, this firmware is being modified to enforce stricter policy. Ok. I think this should really go through the UEFI spec process - I agree that from a strict interpretation of the spec, what this firmware is doing is legitimate, but I don't like having a situation where we have to depend on the DXE spec. How does Windows handle this? Just update the page tables itself for any regions it needs during boot?
