On Fri, 25 Mar 2022 at 09:06, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > On Thu, 24 Mar 2022 at 17:39, <baskov@xxxxxxxxx> wrote: > > > > On 2022-03-18 19:37, Peter Jones wrote: > > > On Thu, Mar 03, 2022 at 08:47:59PM +0000, Matthew Garrett wrote: > > >> 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. > > > > > > It's in the process of getting into the UEFI spec now as > > > https://bugzilla.tianocore.org/show_bug.cgi?id=3519 . > > > > > >> How does Windows handle this? Just update the page tables itself for > > >> any > > >> regions it needs during boot? > > > > > > Microsoft's bootloader sets up its own pagetables, though I believe > > > they're switching it to use the (soon to be) standardized API. > > > > The third version of the patch is the most close in structure > > to the proposed protocol. And until the protocol is standardized and > > implemented on problematic firmware, I think, it remains the better > > solution in terms of simplicity and further porting to the new > > protocol. > > > > It is desirable to get the issue resolved, and make the kernel stricter > > comply to the spec, without waiting for the new API implementation. > > And later, switch the kernel to be using the protocol with > > subsequent patches as soon as it gets usable. > > > > So, is there a chance for these patches to be accepted in current > > form, or with some modifications? > > > > I am fine with taking the v3, as it is the most likely to only affect > the systems that actually need this change in behavior. > > So unless there are any objections, I will queue these up after the > merge window. I have queued these up now.
