Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v2] x86/sme: Explicitly map new EFI memmap table as
 encrypted
From:   Tom Lendacky <thomas.lendacky@amd.com>
To:     Ard Biesheuvel <ardb@kernel.org>, linux-efi@vger.kernel.org,
        platform-driver-x86@vger.kernel.org
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Darren Hart <dvhart@infradead.org>,
        Andy Shevchenko <andy@infradead.org>,
        Matt Fleming <matt@codeblueprint.co.uk>,
        stable@vger.kernel.org, linux-kernel@vger.kernel.org,
        x86@kernel.org
References: <8afff0c64feb6b96db36112cb865243f4ae280ca.1634922135.git.thomas.lendacky@amd.com>
Message-ID: <c997e8a2-b364-2a8e-d247-438e9d937a1e@amd.com>
Date:   Wed, 27 Oct 2021 10:11:41 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
In-Reply-To: <8afff0c64feb6b96db36112cb865243f4ae280ca.1634922135.git.thomas.lendacky@amd.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aTU0SnlrV0tBM21jeDVVanF4WkZCRDhRWDROclo2NDl6RW0rSEtXcUZrL2lq?=
 =?utf-8?B?Zi9helE4aVNTSWJXS1pyc0lNUnRXWW5obVdsWnRZbjczd3E0TEt4VzYzV0Rx?=
 =?utf-8?B?aUE3anJKOVVaWEFZRTFObkVQaUVTQ1BJYWdSZHIweEZnNCtIUmVIU01pLzZP?=
 =?utf-8?B?cUxmc2t4c2loaGorWUVMRGE2RkxuSDZkcy9vTGM3R2ZNTnpZempCTmZ2ZE0v?=
 =?utf-8?B?Q2tsdmRRZUo2UXBwckRJQXJNaXBxdVk2L05LQlEyNDEzeVVabmpZUHZ4dWNX?=
 =?utf-8?B?STVYS1dIQmR1QkdRWlUyb2dJVXFIWmFZWk9DYThrOU9CVWNTZU9TNDczZ2JJ?=
 =?utf-8?B?NG45M25kRWpYL2NscWVXdDZGYSt3aEN4MFJzQmN4SkdydFNscWQ2NUV4Tzl0?=
 =?utf-8?B?VlhKVEFGZlRtZjhsOHgyRmYyR2NsZzlaYlJFc3AzdDlpcmxZTVdmU01FcVZv?=
 =?utf-8?B?YmlPQ3RiMWFOeksxVnpVR1psSE1leHhXd3NQODRiV0krZzlNa2wzTmhKcUh5?=
 =?utf-8?B?NldoQ3pHYmpnN2lUMWoyT3d6L1pTcnFVT21xdWRqanU2MXJqUW5SUFdzd2d2?=
 =?utf-8?B?eVBIYmMwM0FNcUZtVkZoV2dlRGJRWS9DMnEzc0hUZnNGZmhDc2w5c2VxRGNq?=
 =?utf-8?B?TDhDTUhOeE9FRUtRNmdPWFl4Vjlyc0laVzZIUk84UldyZVhrcjNLa1V4VXZz?=
 =?utf-8?B?cjFxRWM1M0IwTVJQMUNLWngydXBROXNJMVBkM1FYT0p4VUlUNVNwUnRHQlVI?=
 =?utf-8?B?UTJEaTRSUXc1RlZ0RUVGYmpjYmpiSGVlcmR6ZnlKYnVZV0RKTTFQTm5JTVBM?=
 =?utf-8?B?UTU3OGQrSktpYW9wQVZGazhRY1pOVmsyYytlcTRqVHdHcU1NT3EwTnNKZFVk?=
 =?utf-8?B?WDd1MlFqWTNobVNzRkthY0xFekdyZFExcndBaXdLNGhCZVNEdDVCZkhOQTJW?=
 =?utf-8?B?ZUVublJCT04xMDlyL2l4Wkh2aitKYSs3WDRRVDBleUVvVUdpdEJCWW1GZ1Vn?=
 =?utf-8?B?UlNHWk04UU9nVGh5Y21YUmJUMzdVNHNMY2plN1V1ekdOQ0tjSkwwTUpQZXNH?=
 =?utf-8?B?ZFcrN0pvR254YjVTQ0pYSFJacHlmeFdQOTV1ZUVvQXI3WWNkQlQxWEZtSmxK?=
 =?utf-8?B?QUEzSVNhZlFnTG9QVHBNcDJuMFZLUGI5a0I0Nm9KaHRzcEFZRW5ma092NGRn?=
 =?utf-8?B?WHF3QStaalpYeTZuK3Fja0w2Mkw1cEV5WWRiem8rVnY4NnFBL1RqVFRlREpY?=
 =?utf-8?B?MTJNVjJlRWFVc29LbExuSzB2UjJ6cjlRK0xQbHQ2b2tOZHhUZDBwbFV5YjBU?=
 =?utf-8?B?cmFqblN0VjJWa0loZHl1eUVxaU5BMWZUZ0VDWjdoenhGc053aWZPSnc2TTNa?=
 =?utf-8?B?T3BHTEI3cU1GclBFaVVsKzlYeTZUaklXa0tXZzJ4cSs0cm4wbUdEMjBBZUVT?=
 =?utf-8?B?NldUVXUxMVNiM25DT01rVmFCYlhXYUY1WUZhZmEwUytXbUFQK1pLNzYzbm5T?=
 =?utf-8?B?c3Z3cnpSYWQrMlZkaWdTWTNuaUlROGZlNmZMa0FqblpkdVc2T2tVNzdqVzh6?=
 =?utf-8?B?V0Rpd1VpTG9xekNaMlo2ZTYvTmNMWXhhT1R3MWM5b0grZTBtOW05Y0tXYkhz?=
 =?utf-8?B?b1EyV0FtVU9WTDN0am84Mml4cGxGcFZ3RjVOeE5MNGh4bGJrYnZZaGdiVWpW?=
 =?utf-8?B?RUFIaklhWHh1OXBTUUlocHpSRDhNNXNjNDNDanVxZFozT3BTUXMzS2Jobndj?=
 =?utf-8?B?WjUwMmtPUEZTSjVFT1BML2NKaWFZY3dSMkpWa3hSeUFNWms4L3RTYVhscHpa?=
 =?utf-8?B?TFJsZWZnekZlc1NVTUtCdjlXWnRPWllKUlBmK2xpYlMxL3JPYUVkTUkzM1BC?=
 =?utf-8?B?Z2JZRko4enVSWXZFV3NDUisvd0ExYVJZckM5TW9qOU00MmxGa2xwaE5WM3lX?=
 =?utf-8?B?R21tcldSdVdDZWxycXRCQlJzam5TbW1PTHRDNmY4VlhvbjQwTWpJVGNYcnlk?=
 =?utf-8?B?M1NWaGZhVEh3MWMwRDBlVXZCWE9WSHE4TWtSK3RWbTdxbENLcHhiSFRsRThj?=
 =?utf-8?B?TXdrZ3dDL1kzcWI5TXZFOXczYVhNclJlOUZPVktNWnBoUS9jeTEzdkY1TFhu?=
 =?utf-8?B?Yks3OEcveElhd0U1WXprQTVBNnlhSWZyc3dwMTJXVUUwZmxyTlcyZFhrcnVw?=
 =?utf-8?Q?StzEP+xtKwhyz4MpPJIAEig=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fd7239fe-6875-4b0b-657e-08d9995c1609
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB5229.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2021 15:11:44.1066
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: xLESfygwYYy5i+b1oqLVWlbCubWi4t3U+oLsfDy26OIec6jn0d/7gCwPqf76kKLpi2i/pqbe5ikowXMdW0IYhw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5246
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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;
>