On Wed, 27 Oct 2021 at 17:11, Tom Lendacky thomas.lendacky@amd.com wrote:
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?
I could take it, but since it will ultimately go through -tip anyway, perhaps better if they just take it directly? (This will change after the next -rc1 though)
Boris?