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?
Thanks,
Baskov Evgeniy
