From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Baskov Evgeniy <baskov@ispras.ru>,
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
Date: Mon, 28 Feb 2022 18:30:44 +0000 [thread overview]
Message-ID: <20220228183044.GA18400@srcf.ucam.org> (raw)
In-Reply-To: <CAMj1kXGg=HAv3P_NKqUHCg6bRFsB0qhfa_z-TOdmi-G8EqPrZA@mail.gmail.com>
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?
next prev parent reply other threads:[~2022-02-28 18:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 15:43 [PATCH RFC v2 0/2] Handle UEFI NX-restricted page tables Baskov Evgeniy
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 [this message]
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=20220228183044.GA18400@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=ardb@kernel.org \
--cc=baskov@ispras.ru \
--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=pjones@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