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
>
