On Mon, 11 Nov 2024 at 22:45, Nicolas Saenz Julienne <nsaenz@xxxxxxxxxx> wrote: > > Kexec bypasses EFI's switch to virtual mode. In exchange, it has its own > routine, kexec_enter_virtual_mode(), that replays the mappings made by > the original kernel. Unfortunately, the function fails to reinstate > EFI's memory attributes and runtime memory protections, which would've > otherwise been set after entering virtual mode. Remediate this by > calling efi_runtime_update_mappings() from it. > > Cc: stable@xxxxxxxxxxxxxxx > Fixes: 18141e89a76c ("x86/efi: Add support for EFI_MEMORY_ATTRIBUTES_TABLE") > Signed-off-by: Nicolas Saenz Julienne <nsaenz@xxxxxxxxxx> > > --- > > Notes: > - I tested the Memory Attributes path using QEMU/OVMF. > > - Although care is taken to make sure the memory backing the EFI Memory > Attributes table is preserved during runtime and reachable after kexec > (see efi_memattr_init()). I don't see the same happening for the EFI > properties table. Maybe it's just unnecessary as there's an assumption > that the table will fall in memory preserved during runtime? Or for > another reason? Otherwise, we'd need to make sure it isn't possible to > set EFI_NX_PE_DATA on kexec. > > arch/x86/platform/efi/efi.c | 1 + > 1 file changed, 1 insertion(+) > Thanks. I think we should just drop support for the EFI_PROPERTIES_TABLE - it was a failed, short-lived experiment that broke the boot on both Linux and Windows, and was replaced with the memory attributes table shortly after. > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c > index 88a96816de9a..b9b17892c495 100644 > --- a/arch/x86/platform/efi/efi.c > +++ b/arch/x86/platform/efi/efi.c > @@ -784,6 +784,7 @@ static void __init kexec_enter_virtual_mode(void) > > efi_sync_low_kernel_mappings(); > efi_native_runtime_setup(); > + efi_runtime_update_mappings(); > #endif > } > > -- > 2.40.1 >