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@vger.kernel.org
Fixes: 18141e89a76c ("x86/efi: Add support for EFI_MEMORY_ATTRIBUTES_TABLE")
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>

---

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(+)

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

On Mon, 11 Nov 2024 at 22:45, Nicolas Saenz Julienne <nsaenz@amazon.com> 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@vger.kernel.org
> Fixes: 18141e89a76c ("x86/efi: Add support for EFI_MEMORY_ATTRIBUTES_TABLE")
> Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
>
> ---
>
> 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
>

On Tue Nov 12, 2024 at 7:55 AM UTC, Ard Biesheuvel wrote:
> On Mon, 11 Nov 2024 at 22:45, Nicolas Saenz Julienne <nsaenz@amazon.com> wrote:
>>
>> - 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.
>
> 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.

Isn't there a tiny posibility some platorm might be using the feature?
Otherwise I'll send a v2 right away.

Nicolas