Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 3 Mar 2022 20:47:59 +0000
From:   Matthew Garrett <mjg59@srcf.ucam.org>
To:     baskov@ispras.ru
Cc:     Ard Biesheuvel <ardb@kernel.org>, Peter Jones <pjones@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        X86 ML <x86@kernel.org>, linux-efi <linux-efi@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC v2 0/2] Handle UEFI NX-restricted page tables
Message-ID: <20220303204759.GA20294@srcf.ucam.org>
References: <20220224154330.26564-1-baskov@ispras.ru>
 <CAMj1kXGg=HAv3P_NKqUHCg6bRFsB0qhfa_z-TOdmi-G8EqPrZA@mail.gmail.com>
 <20220228183044.GA18400@srcf.ucam.org>
 <9787f1c1948cc640e70a50e4b929f44f@ispras.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9787f1c1948cc640e70a50e4b929f44f@ispras.ru>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Thu, Mar 03, 2022 at 04:42:07PM +0300, baskov@ispras.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.

How does Windows handle this? Just update the page tables itself for any 
regions it needs during boot?