From: Baskov Evgeniy <baskov@ispras.ru>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Baskov Evgeniy <baskov@ispras.ru>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, linux-efi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH RFC v2 0/2] Handle UEFI NX-restricted page tables
Date: Thu, 24 Feb 2022 18:43:28 +0300 [thread overview]
Message-ID: <20220224154330.26564-1-baskov@ispras.ru> (raw)
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(-)
next reply other threads:[~2022-02-24 15:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 15:43 Baskov Evgeniy [this message]
2022-02-24 15:43 ` [PATCH RFC v2 1/2] libstub: declare DXE services table Baskov Evgeniy
2022-02-24 15:43 ` [PATCH RFC v2 2/2] libstub: ensure allocated memory to be executable Baskov Evgeniy
2022-02-28 16:45 ` [PATCH RFC v2 0/2] Handle UEFI NX-restricted page tables Ard Biesheuvel
2022-02-28 18:30 ` Matthew Garrett
2022-03-03 13:42 ` baskov
2022-03-03 20:47 ` Matthew Garrett
2022-03-17 13:26 ` baskov
2022-03-18 16:37 ` Peter Jones
2022-03-24 16:39 ` baskov
2022-03-25 8:06 ` Ard Biesheuvel
2022-04-13 17:50 ` Ard Biesheuvel
2022-03-29 18:47 ` Peter Jones
2022-03-29 18:47 ` [PATCH] x86: Set the NX-compatibility flag in the PE header Peter Jones
2022-04-13 17:48 ` Ard Biesheuvel
2022-03-03 14:15 ` [PATCH RFC v2 0/2] Handle UEFI NX-restricted page tables baskov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220224154330.26564-1-baskov@ispras.ru \
--to=baskov@ispras.ru \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox