lkml.org 
[lkml]   [2022]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RFC v2 0/2] Handle UEFI NX-restricted page tables
On Thu, Mar 03, 2022 at 04:42:07PM +0300, baskov@ispras.ru 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?

\
 
 \ /
  Last update: 2022-03-03 21:49    [W:0.150 / U:1.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site