lkml.org 
[lkml]   [2022]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[PATCH RFC v2 0/2] Handle UEFI NX-restricted page tables
Date
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.

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(-)

\
 
 \ /
  Last update: 2022-02-24 17:11    [W:0.134 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site