From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Fri, 23 Aug 2019 06:26:18 -0700 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 50D9D18C4271; Fri, 23 Aug 2019 13:26:17 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-39.ams2.redhat.com [10.36.117.39]) by smtp.corp.redhat.com (Postfix) with ESMTP id 60DA55D6B2; Fri, 23 Aug 2019 13:26:14 +0000 (UTC) Subject: Re: [edk2-devel] [RFC PATCH 05/28] OvmfPkg: Create GHCB pages for use during Pei and Dxe phase To: "Lendacky, Thomas" , "devel@edk2.groups.io" Cc: Jordan Justen , Ard Biesheuvel , Michael D Kinney , Liming Gao , Eric Dong , Ray Ni , "Singh, Brijesh" References: <096c6641b2f228177ab3bb815211379c1f650028.1566250534.git.thomas.lendacky@amd.com> <59b40c01-a6bf-2c65-0edd-87a35f937264@redhat.com> <229e74df-17b8-9bb5-7a5e-f6e7df64ca4f@amd.com> <28e75840-4725-5cdd-ae4a-1cc175bace1a@redhat.com> From: "Laszlo Ersek" Message-ID: Date: Fri, 23 Aug 2019 15:26:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.62]); Fri, 23 Aug 2019 13:26:17 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 08/22/19 17:24, Lendacky, Thomas wrote: > On 8/22/19 9:12 AM, Laszlo Ersek wrote: >> On 08/21/19 23:42, Lendacky, Thomas wrote: >>> On 8/21/19 9:31 AM, Laszlo Ersek wrote: >>>> On 08/19/19 23:35, Lendacky, Thomas wrote: >>>>> From: Tom Lendacky >>>>> >>>>> Allocate memory for the GHCB pages during SEV initialization for use >>>>> during Pei and Dxe phases. Since the GHCB pages must be mapped as shared >>>>> pages, modify CreateIdentityMappingPageTables() so that pagetable entries >>>>> are created without the encryption bit set. >>>>> >>>>> Signed-off-by: Tom Lendacky >>>>> --- >>>>> UefiCpuPkg/UefiCpuPkg.dec | 4 ++ >>>>> OvmfPkg/OvmfPkgX64.dsc | 4 ++ >>>>> MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf | 3 + >>>>> OvmfPkg/PlatformPei/PlatformPei.inf | 2 + >>>>> .../Core/DxeIplPeim/X64/VirtualMemory.h | 12 +++- >>>>> .../Core/DxeIplPeim/Ia32/DxeLoadFunc.c | 4 +- >>>>> .../Core/DxeIplPeim/X64/DxeLoadFunc.c | 11 +++- >>>>> .../Core/DxeIplPeim/X64/VirtualMemory.c | 49 ++++++++++---- >>>>> .../MemEncryptSevLibInternal.c | 1 - >>>>> .../BaseMemEncryptSevLib/X64/VirtualMemory.c | 33 ++++++++-- >>>>> OvmfPkg/PlatformPei/AmdSev.c | 64 +++++++++++++++++++ >>>>> 11 files changed, 164 insertions(+), 23 deletions(-) >>>> >>>> Should be split to at least four patches (UefiCpuPkg, MdeModulePkg, >>>> OvmfPkg/BaseMemEncryptSevLib, OvmfPkg/PlatformPei). >>>> >>>> In addition, MdeModulePkg content must not depend on UefiCpuPkg content >>>> -- if modules under both packages need to consume a new PCD, then the >>>> PCD should be declared under MdeModulePkg. The rough dependency order is: >>>> >>>> - MdePkg (must be self-contained) >>>> - MdeModulePkg (may consume MdePkg) >>>> - UefiCpuPkg (may consume everything above, to my knowledge) >>>> - OvmfPkg (may consume everything above) >>>> >>> >>> Ok, thanks for the guidance. >>> >>> Ideally, I just would like to modify the newly created page tables after >>> the call to CreateIdentityMappingPageTables() in MdeModulePkg/Core/ >>> DxeIplPeim/Ia32/DxeLoadFunc.c. Is there a preferred way to add a listener >>> or callback or notification service so that the main changes would be >>> limited to the OvmfPkg files and would that be acceptable? >> >> * https://bugzilla.tianocore.org/show_bug.cgi?id=623 >> >> Reported on 2017-07-07, resolved as WONTFIX on 2019-07-30 ("no >> resources"). >> >> And it's not like patches had not been proposed -- Leo had implemented >> a notification service --; they were rejected. >> >> * https://bugzilla.tianocore.org/show_bug.cgi?id=847 >> >> Reported on 2018-01-11, marked "not high priority" as of 2019-07-23 >> . >> >> I don't know what to tell you. While nobody seems to disagree with the >> necessity of such a service and/or library, core maintainers have >> rejected all the code proposals thus far (= "don't do that"). And I'm >> unaware of any constructive guidance (= "do this instead"). > > This isn't on the level of a "notify every time something changes" type > of thing. This is more of a "hey, we built some new pagetables and are > about to make them active, but before we do have a look and change what > you think should be changed." > > With that, I'd be able to remove the GhcbBase and GhcbSize that is > propogated on the ToSplit and Split functions. > > I'll take a look and see what it would look like and go from there. Maybe not the same kind of notification pattern (and the event triggering the notification could be different), but the point is the same -- the platform would like the core to call it back at various stages / points of page table manipulation. How we implement that, is "details" (edk2-specific (and versioned) protocol, provided by the platform and called by the core; versus separate event groups, signaled by the core; versus custom lib class, implemented by the platform; versus custom status codes reported by the core; etc). What's important is for core maintainers to finally accept that the facility *as such* is needed. > >> >> I suggest filing a Feature Request BZ for SEV-ES enablement (for >> OvmfPkg), and referencing that as "dependent bug" in both of the >> above-mentioned BZs. It might also help to dial in to the APAC/NAMO >> design / bug triage meeting, and campaign for the feature there. > > Yes, I need to file that Feature Request BZ anyway. Thanks. Laszlo >> >> https://github.com/tianocore/tianocore.github.io/wiki/Bug-Triage >> >> I have a bad track record at convincing core maintainers to do what they >> don't want to do. And I see escalating such problems from email to phone >> as a work-around, sort of "wear down your opponent by sheer >> persistence". So I avoid that. But, I've seen the approach work for >> others, so you might have better luck. >> >> (The APAC/NAMO call is also at a bad time for me, in UTC+1 / UTC+2.) >> >> I think the present RFC patches are a good way to re-raise these topics. >> >> Laszlo >>