Messages in this thread | | | Subject | Re: [PATCH] x86/sme: Explicitly map new EFI memmap table as encrypted | From | Tom Lendacky <> | Date | Thu, 21 Oct 2021 08:21:15 -0500 |
| |
On 10/20/21 1: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 memory map is mapped > using early_memremap() and generally mapped encrypted, unless the new > memory for the mapping happens to come from an area of memory that is > marked as EFI_BOOT_SERVICES_DATA memory. In this case, the new memory will > be mapped unencrypted. However, during replacement of the old memory map, > efi_mem_type() is disabled, so the new memory map will now be long-term > mapped encrypted (in efi.memmap), resulting in the map containing invalid > data and causing the kernel boot to crash. > > Since it is known that the area will be mapped encrypted going forward, > explicitly map the new memory map as encrypted using early_memremap_prot(). > > Cc: <stable@vger.kernel.org> # 4.14.x > Fixes: 8f716c9b5feb ("x86/mm: Add support to access boot related data in the clear") > Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> > --- > arch/x86/platform/efi/quirks.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c > index b15ebfe40a73..b0b848d6933a 100644 > --- a/arch/x86/platform/efi/quirks.c > +++ b/arch/x86/platform/efi/quirks.c > @@ -277,7 +277,8 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size) > return; > } > > - new = early_memremap(data.phys_map, data.size); > + new = early_memremap_prot(data.phys_map, data.size, > + pgprot_val(pgprot_encrypted(FIXMAP_PAGE_NORMAL)));
I should really have a comment above this as to why this version of the early_memremap is being used.
Let me add that (and maybe work on the commit message a bit) and submit a v2. But I'll hold off for a bit in case any discussion comes about.
Thanks, Tom
> if (!new) { > pr_err("Failed to map new boot services memmap\n"); > return; >
| |