lkml.org 
[lkml]   [2021]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2] x86/sme: Explicitly map new EFI memmap table as encrypted
From
Date
On 10/22/21 12:02 PM, Tom Lendacky wrote:
> Reserving memory using efi_mem_reserve() calls into the x86
> efi_arch_mem_reserve() function. This function will insert a new EFI
> memory descriptor into the EFI memory map representing the area of
> memory to be reserved and marking it as EFI runtime memory.
>
> As part of adding this new entry, a new EFI memory map is allocated and
> mapped. The mapping is where a problem can occur. This new EFI memory map
> is mapped using early_memremap(). If the allocated memory comes from an
> area that is marked as EFI_BOOT_SERVICES_DATA memory in the current EFI
> memory map, then it will be mapped unencrypted (see memremap_is_efi_data()
> and the call to efi_mem_type()).
>
> However, during replacement of the old EFI memory map with the new EFI
> memory map, efi_mem_type() is disabled, resulting in the new EFI memory
> map always being mapped encrypted in efi.memmap. This will cause a kernel
> crash later in the boot.
>
> Since it is known that the new EFI memory map will always be mapped
> encrypted when efi_memmap_install() is called, explicitly map the new EFI
> memory map as encrypted (using early_memremap_prot()) when inserting the
> new memory map entry.
>
> Cc: <stable@vger.kernel.org> # 4.14.x
> Fixes: 8f716c9b5feb ("x86/mm: Add support to access boot related data in the clear")
> Acked-by: Ard Biesheuvel <ardb@kernel.org>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>

Ard, are you going to take this through the EFI tree or does it need to go
through another tree?

Thanks,
Tom

>
> ---
> Changes for v2:
> - Update/expand commit message to (hopefully) make it easier to read and
> understand
> - Add a comment around the use of the early_memremap_prot() call
> ---
> arch/x86/platform/efi/quirks.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
> index b15ebfe40a73..14f8f20d727a 100644
> --- a/arch/x86/platform/efi/quirks.c
> +++ b/arch/x86/platform/efi/quirks.c
> @@ -277,7 +277,19 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
> return;
> }
>
> - new = early_memremap(data.phys_map, data.size);
> + /*
> + * When SME is active, early_memremap() can map the memory unencrypted
> + * if the allocation came from EFI_BOOT_SERVICES_DATA (see
> + * memremap_is_efi_data() and the call to efi_mem_type()). However,
> + * when efi_memmap_install() is called to replace the memory map,
> + * efi_mem_type() is "disabled" and so the memory will always be mapped
> + * encrypted. To avoid this possible mismatch between the mappings,
> + * always map the newly allocated memmap memory as encrypted.
> + *
> + * When SME is not active, this behaves just like early_memremap().
> + */
> + new = early_memremap_prot(data.phys_map, data.size,
> + pgprot_val(pgprot_encrypted(FIXMAP_PAGE_NORMAL)));
> if (!new) {
> pr_err("Failed to map new boot services memmap\n");
> return;
>

\
 
 \ /
  Last update: 2021-10-27 17:11    [W:3.185 / U:0.736 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site