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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9d9ca009-93c5-acc3-7445-d514c7878478@amd.com>
Date:   Thu, 21 Oct 2021 08:21:15 -0500
From:   Tom Lendacky <thomas.lendacky@....com>
To:     linux-kernel@...r.kernel.org, x86@...nel.org,
        linux-efi@...r.kernel.org, platform-driver-x86@...r.kernel.org
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, Ard Biesheuvel <ardb@...nel.org>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        Matt Fleming <matt@...eblueprint.co.uk>, stable@...r.kernel.org
Subject: Re: [PATCH] x86/sme: Explicitly map new EFI memmap table as encrypted

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@...r.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@....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;
>