Messages in this thread | | | Subject | Re: [PATCH v2] x86/sme: Explicitly map new EFI memmap table as encrypted | From | Tom Lendacky <> | Date | Wed, 27 Oct 2021 10:11:41 -0500 |
| |
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; >
| |