[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <D5P8Y0SCMRJZ.2VAI4IK2RCOAC@amazon.com>
Date: Mon, 18 Nov 2024 10:52:56 +0000
From: Nicolas Saenz Julienne <nsaenz@...zon.com>
To: Ard Biesheuvel <ardb@...nel.org>
CC: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
<x86@...nel.org>, "H . Peter Anvin" <hpa@...or.com>, Matt Fleming
<matt@...eblueprint.co.uk>, <linux-efi@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <stanspas@...zon.de>,
<nh-open-source@...zon.com>, <stable@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] x86/efi: Apply EFI Memory Attributes after kexec
On Fri Nov 15, 2024 at 4:39 PM UTC, Ard Biesheuvel wrote:
> On Tue, 12 Nov 2024 at 19:53, Nicolas Saenz Julienne <nsaenz@...zon.com> wrote:
>>
>> Kexec bypasses EFI's switch to virtual mode. In exchange, it has its own
>> routine, kexec_enter_virtual_mode(), which replays the mappings made by
>> the original kernel. Unfortunately, that function fails to reinstate
>> EFI's memory attributes, which would've otherwise been set after
>> entering virtual mode. Remediate this by calling
>> efi_runtime_update_mappings() within kexec's routine.
>>
>> Cc: stable@...r.kernel.org
>> Fixes: 18141e89a76c ("x86/efi: Add support for EFI_MEMORY_ATTRIBUTES_TABLE")
>> Signed-off-by: Nicolas Saenz Julienne <nsaenz@...zon.com>
>>
>> ---
>>
>> Notes:
>> - Tested with QEMU/OVMF.
>>
>
>
> I'll queue these up,
Thanks!
> but I am going drop the cc stable: the memory attributes table is an
> overlay of the EFI memory map with restricted permissions for EFI
> runtime services regions, which are only mapped while a EFI runtime
> call is in progress.
>
> So if the table is not taken into account after kexec, the runtime
> code and data mappings will all be RWX but I think this is a situation
> we can live with. If nothing breaks, we can always revisit this later
> if there is an actual need.
My intention was backporting the fix all the way to
'stable/linux-5.10.y'. But I'm happy to wait, or even to maintain an
internal backport. It's simple enough.
Nicolas
Powered by blists - more mailing lists