Re: [PATCH] x86/sme: Explicitly map new EFI memmap table as encrypted

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Sat, Dec 11, 2021 at 11:19:00AM -0600, Tom Lendacky wrote:
> commit 1ff2fc02862d52e18fd3daabcfe840ec27e920a8 upstream
> to be applied to 4.14, 4.19 and 5.4.
> 
> 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")
> Link: https://lore.kernel.org/all/ebf1eb2940405438a09d51d121ec0d02c8755558.1634752931.git.thomas.lendacky@amd.com/
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> [ardb: incorporate Kconfig fix by Arnd]
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>  arch/x86/Kconfig               | 1 +
>  arch/x86/platform/efi/quirks.c | 3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)

Now queued up, thanks.

greg k-h