From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9D63FC433F5 for ; Wed, 27 Oct 2021 15:15:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 78DFF60FBF for ; Wed, 27 Oct 2021 15:15:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242709AbhJ0PR2 (ORCPT ); Wed, 27 Oct 2021 11:17:28 -0400 Received: from mail.kernel.org ([198.145.29.99]:35280 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242685AbhJ0PRN (ORCPT ); Wed, 27 Oct 2021 11:17:13 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id BCA2760FBF; Wed, 27 Oct 2021 15:14:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1635347687; bh=d/hO+irUkRPAzOGdj54F3ss4yD7w6tan9uDNj2qHGIU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=LnZpW/y7ZHNV2FSyWuS7JHO3QFfij5w3RLDLVKOON6tOCd+MufZc0b5YfFwuM1wqc BPKnxbmuopGdep3xmltXh/wM80r6X5rMipCh2dA+RUB9BswkVAREurb8ulMtNpbZCo 1s7QTdjiNabd2gKYl7KNwwZHJF6smwDEBNCBg8TSbJMjK1oxwQCvPyxoxVZVrgQihl IPVzlcD9hyv7MxpCllAxpD7m/gCAQrq6eGdkQ6V9tQ0YNL3+KnFMpjJtZ/VsT23tIS +cOTOzMnXI4OUIDIygDLmAAgCHmXFgYW4CXqvFQbDub/DgUxNkE5fgeFtLynpowwGJ x1Ac2xpTBlvcw== Received: by mail-oi1-f172.google.com with SMTP id q124so3881744oig.3; Wed, 27 Oct 2021 08:14:47 -0700 (PDT) X-Gm-Message-State: AOAM531knRuUH23akYraNx7d5zD3nII8z4+SpMrk1zST3AbsurZKIC5J 0peZJQFb414LVcA2+J3fj4Bje0YM9PkFakJ14mE= X-Google-Smtp-Source: ABdhPJy9+vxFPsaLhxqGQzcobHUkMTWm501K6OCqjdgv4SmHSPBbSKIhFJ1CAnqbinO45Kdc680JobcJmsOS4WQU6bU= X-Received: by 2002:a05:6808:1805:: with SMTP id bh5mr3986936oib.47.1635347687082; Wed, 27 Oct 2021 08:14:47 -0700 (PDT) MIME-Version: 1.0 References: <8afff0c64feb6b96db36112cb865243f4ae280ca.1634922135.git.thomas.lendacky@amd.com> In-Reply-To: From: Ard Biesheuvel Date: Wed, 27 Oct 2021 17:14:35 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] x86/sme: Explicitly map new EFI memmap table as encrypted To: Tom Lendacky Cc: linux-efi , platform-driver-x86@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Darren Hart , Andy Shevchenko , Matt Fleming , "# 3.4.x" , Linux Kernel Mailing List , X86 ML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 27 Oct 2021 at 17:11, Tom Lendacky 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: # 4.14.x > > Fixes: 8f716c9b5feb ("x86/mm: Add support to access boot related data in the clear") > > Acked-by: Ard Biesheuvel > > Signed-off-by: Tom Lendacky > > 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?