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?
