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 for Android: free password hash cracker in your pocket

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

Message-ID: <20e2f5b9ab008b12f14e763127f5ca1b@ispras.ru>
Date:   Thu, 24 Mar 2022 19:39:47 +0300
From:   baskov@...ras.ru
To:     ardb@...nel.org
Cc:     Matthew Garrett <mjg59@...f.ucam.org>,
        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>,
        pjones@...hat.com
Subject: Re: [PATCH RFC v2 0/2] Handle UEFI NX-restricted page tables

On 2022-03-18 19:37, Peter Jones wrote:
> On Thu, Mar 03, 2022 at 08:47:59PM +0000, Matthew Garrett wrote:
>> On Thu, Mar 03, 2022 at 04:42:07PM +0300, baskov@...ras.ru wrote:
>> > On 2022-02-28 21:30, Matthew Garrett wrote:
>> > > 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?
>> >
>> > Yes, this firmware is being modified to enforce stricter policy.
>> 
>> Ok. I think this should really go through the UEFI spec process - I
>> agree that from a strict interpretation of the spec, what this 
>> firmware
>> is doing is legitimate, but I don't like having a situation where we
>> have to depend on the DXE spec.
> 
> It's in the process of getting into the UEFI spec now as
> https://bugzilla.tianocore.org/show_bug.cgi?id=3519 .
> 
>> How does Windows handle this? Just update the page tables itself for 
>> any
>> regions it needs during boot?
> 
> Microsoft's bootloader sets up its own pagetables, though I believe
> they're switching it to use the (soon to be) standardized API.

The third version of the patch is the most close in structure
to the proposed protocol. And until the protocol is standardized and
implemented on problematic firmware, I think, it remains the better
solution in terms of simplicity and further porting to the new
protocol.

It is desirable to get the issue resolved, and make the kernel stricter
comply to the spec, without waiting for the new API implementation.
And later, switch the kernel to be using the protocol with
subsequent patches as soon as it gets usable.

So, is there a chance for these patches to be accepted in current
form, or with some modifications?

Thanks,
Baskov Evgeniy