Re: [PATCH RFC v2 0/2] Handle UEFI NX-restricted page tables

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(cc Matt and Peter)

On Thu, 24 Feb 2022 at 16:45, Baskov Evgeniy <baskov@xxxxxxxxx> wrote:
>
> This is another implementation of this patch. It uses DXE services
> to change memory protection flags as you suggested earlier.
>
> As I mentioned, you can reproduce this issue with any firmware,
> including OVMF by setting the PcdDxeNxMemoryProtectionPolicy policy:
> gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy|0x7FD4
> Restricting the user from creating executable pages is not an goal,
> but restricting one from creating both executable and writable pages
> is a goal, which is enforced in the firmware we use. We cannot allow
> allocating pages of any type that have RWX permissions.
> gDS->SetMemorySpaceAttributes() is technically part of the UEFI PI
> specification, so it is not too bad to rely on it. However:
> - DXE services is not something designed to be used by an UEFI application.
> - From what we know, no other operating system uses this interface,
> which means that it can easily break in production firmware on the
> boards we do not control before anyone could even notice.
> We do not strictly mind experimenting with this route, but it would be
> preferable for this interface to become more standard in this case:
> move it to UEFI Boot Services or a separate protocol and include it in
> UEFI conformance suite. It will also help if we enable this feature in
> Linux by default.
>

Thanks for exploring my suggestion to use the DXE services for this.

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.

I've cc'ed Peter and Matt, who have much more experience dealing with
these kinds of things on x86 - my experience is mostly based on ARM,
which tends to be less quirky when it comes to UEFI support, given
that vendors that implement EFI actually care about being compliant
(instead of only about getting a windows sticker)

Matt, Peter, any thoughts?


> Baskov Evgeniy (2):
>        efi: declare DXE services table
>        libstub: ensure allocated memory to be executable
>
>  arch/x86/include/asm/efi.h              |  5 ++
>  drivers/firmware/efi/libstub/efistub.h  | 53 ++++++++++++++++++++
>  drivers/firmware/efi/libstub/x86-stub.c | 73 ++++++++++++++++++++++++++--
>  include/linux/efi.h                     |  2 +
>  4 files changed, 128 insertions(+), 5 deletions(-)



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux