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: <20220228183044.GA18400@srcf.ucam.org>
Date:   Mon, 28 Feb 2022 18:30:44 +0000
From:   Matthew Garrett <mjg59@...f.ucam.org>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Baskov Evgeniy <baskov@...ras.ru>, Peter Jones <pjones@...hat.com>,
        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

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?