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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXGg=HAv3P_NKqUHCg6bRFsB0qhfa_z-TOdmi-G8EqPrZA@mail.gmail.com>
Date:   Mon, 28 Feb 2022 17:45:53 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Baskov Evgeniy <baskov@...ras.ru>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Peter Jones <pjones@...hat.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        X86 ML <x86@...nel.org>, linux-efi <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC v2 0/2] Handle UEFI NX-restricted page tables

(cc Matt and Peter)

On Thu, 24 Feb 2022 at 16:45, Baskov Evgeniy <baskov@...ras.ru> 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(-)