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; Wed, 31 Jul 2019 02:57:44 -0700 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B1FBC4E83C; Wed, 31 Jul 2019 09:57:43 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-199.ams2.redhat.com [10.36.117.199]) by smtp.corp.redhat.com (Postfix) with ESMTP id E22145D9C5; Wed, 31 Jul 2019 09:57:42 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH 1/3] UefiCpuPkg/PiSmmCpu: Add Internal function IsStaticPageTableEnabled To: "Ni, Ray" , "devel@edk2.groups.io" References: <20190727032850.337840-1-ray.ni@intel.com> <20190727032850.337840-2-ray.ni@intel.com> <1812e3c6-f388-6faa-71d9-8e878b8e9b6c@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5C263DB0@SHSMSX104.ccr.corp.intel.com> From: "Laszlo Ersek" Message-ID: Date: Wed, 31 Jul 2019 11:57:41 +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: <734D49CCEBEEF84792F5B80ED585239D5C263DB0@SHSMSX104.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 31 Jul 2019 09:57:43 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 07/30/19 17:20, Ni, Ray wrote: > > >> -----Original Message----- >> From: devel@edk2.groups.io On Behalf Of Laszlo Ersek >> Sent: Monday, July 29, 2019 7:33 PM >> To: devel@edk2.groups.io; Ni, Ray >> Subject: Re: [edk2-devel] [PATCH 1/3] UefiCpuPkg/PiSmmCpu: Add Internal function IsStaticPageTableEnabled >> >> Hi Ray, >> >> On 07/27/19 05:28, Ni, Ray wrote: >>> The internal function reflects the status whether static page table >>> is enabled. >>> >>> Signed-off-by: Ray Ni >>> Cc: Laszlo Ersek >>> Cc: Eric Dong >> --- >>> UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 16 ++++++++++++++++ >>> UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 15 +++++++++++++++ >>> UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c | 16 ++++++++++++++++ >>> 3 files changed, 47 insertions(+) >>> >>> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c >>> index 05fb455936..2a9af4b77d 100644 >>> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c >>> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c >>> @@ -28,6 +28,22 @@ EnableCet ( >>> VOID >>> ); >>> >>> +/** >>> + Return whether Static Page Table is enabled. >>> + >>> + Note: Static Page Table is always disabled for IA32 build. >>> + >>> + @retval TRUE Static Page Table is enabled. >>> + @retval FALSE Static Page Table is disabled. >>> +**/ >>> +BOOLEAN >>> +IsStaticPageTableEnabled ( >>> + VOID >>> + ) >>> +{ >>> + return FALSE; >>> +} >>> + >>> /** >>> Create PageTable for SMM use. >>> >>> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h >>> index 186809f431..14b7676c16 100644 >>> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h >>> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h >>> @@ -1267,6 +1267,21 @@ EFIAPI >>> PiSmmCpuSmiEntryFixupAddress ( >>> ); >>> >>> + >>> +/** >>> + Return whether Static Page Table is enabled. >>> + >>> + Note: Static Page Table is always disabled for IA32 build. >>> + >>> + @retval TRUE Static Page Table is enabled. >>> + @retval FALSE Static Page Table is disabled. >>> +**/ >>> +BOOLEAN >>> +IsStaticPageTableEnabled ( >>> + VOID >>> + ) >>> +; >>> + >>> /** >>> This function reads CR2 register when on-demand paging is enabled >>> for 64 bit and no action for 32 bit. >>> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c >>> index a3b62f7787..18e3f9e08d 100644 >>> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c >>> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c >>> @@ -37,6 +37,22 @@ EnableCet ( >>> VOID >>> ); >>> >>> +/** >>> + Return whether Static Page Table is enabled. >>> + >>> + Note: Static Page Table is always disabled for IA32 build. >>> + >>> + @retval TRUE Static Page Table is enabled. >>> + @retval FALSE Static Page Table is disabled. >>> +**/ >>> +BOOLEAN >>> +IsStaticPageTableEnabled ( >>> + VOID >>> + ) >>> +{ >>> + return mCpuSmmStaticPageTable; >>> +} >>> + >>> /** >>> Check if 1-GByte pages is supported by processor or not. >>> >>> >> >> I like the approach in this patch; however I think the IA32 >> implementation (and comments) are wrong. The function should return >> constant TRUE on IA32. >> >> "static paging" means that all page tables used in SMM are built in >> advance. When "static paging" is off (= "dynamic paging" is enabled), >> then page tables are built in SMM on-demand, based on individual page >> faults. (This is my understanding anyway.) >> >> And in the IA32 build, the page tables are always built in advance, to >> my understanding. Hence "static paging" should be reported as "on". > > Your understanding to the meaning of "static paging" is correct. > But later commit c60d36b4d1ee1f69b7cca897d3621dfa951895c2 > * UefiCpuPkg/SmmCpu: Block access-out only when static paging is used > alters the meaning of "static paging" to a platform policy that: > When it's true, SMM code cannot access out after EndOfDxe; > When it's false, SMM code can access out after EndOfDxe. > > Which means "static paging" can be either TRUE or FALSE in IA32 build. > Which means the PCD description in UefiCpuPkg.dec is wrong after > commit c60d36b4d1ee1f69b7cca897d3621dfa951895c2. > Right now it says: > ## Indicates if SMM uses static page table. > # If enabled, SMM will not use on-demand paging. SMM will build static page table for all memory. > # This flag only impacts X64 build, because SMM always builds static page table for IA32. > > I was confused when changing the code. > > In the V2 patch, I will: > 1. update UefiCpuPkg.dec to indicate it's new usage of this PCD. Name of PCD is unchanged but it's also applicable > to IA32 now; > 2. No touch to the CR2 save/restore logic because that code depends on whether page table is "built in advance". > 3. Add Ia32 version of mCpuSmmStaticPageTable and cache the PCD value to it. > 4. Check mCpuSmmStaticPageTable and only protect non-SMRAM and page table when it's TRUE. > > Do you agree? I find it extremely confusing to have a PCD which says "StaticPageTable" in the name, but controls something else entirely in the IA32 build of PiSmmCpuDxeSmm. Because, IA32 continues to use statically built page tables. Setting a PCD that says "StaticPageTable" in the name to FALSE, but expecting the page fault handler to *only* change access-out behavior, is wrong. It makes "PcdCpuSmmStaticPageTable" a misnomer. I'm starting to doubt whether the "simplification" in commit c60d36b4d1ee was a good idea. It looks like that commit repurposed PcdCpuSmmStaticPageTable for something that the PCD was never meant for. In my opinion, there are two alternatives: (1) Restore the original meaning of PcdCpuSmmStaticPageTable, and introduce a *new* feature or boolean PCD for controlling access-out. The X64 code would use both PCDs (for different purposes, of course). The IA32 code would only use the new (access-out) PCD. If necessary, catch the invalid combinations of both PCDs (static page table, versus access-out) in the entry point function of PiSmmCpuDxeSmm, with ASSERT()s. I think it possible that out of the 2*2=4 variations only 3 are valid. (2) Alternatively, if it turns out that the original purpose of PcdCpuSmmStaticPageTable is actually a one-to-one match with the new access-out PCD -- in other words, if it turns out that the access-out control *inherently* maps to static paging, and *not* just as a simplification --, then we should not introduce a new PCD. However, in that case, both "mCpuSmmStaticPageTable" and "PcdCpuSmmStaticPageTable" should be renamed to explain this dual purpose. Basically, my alternative (2) is what you are proposing, except I'd also like to see the PCD and the global variable renamed, in that case. However, what's more important is to first re-evaluate whether the "simplification" in commit c60d36b4d1ee was valid. I'm quite unconvinced that using PcdCpuSmmStaticPageTable *additionally* for controlling access outside of SMRAM is inherently necessary. As I understand it, "access-out" is a characteristic that both IA32 and X64 platforms may reasonably want to control. "Static page tables" is a different characteristic that only X64 platforms may reasonably want to control. I think we need separate PCDs. If we can, we should even make "PcdCpuSmmStaticPageTable" an X64-only PCD -- code built for IA32 that references the PCD shouldn't even compile. I think the DEC file syntax makes such restrictions possible. Thanks Laszlo