public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ni, Ray" <ray.ni@intel.com>
To: devel@edk2.groups.io
Cc: Eric Dong <eric.dong@intel.com>, Laszlo Ersek <lersek@redhat.com>,
	Jiewen Yao <jiewen.yao@intel.com>
Subject: [PATCH v2 1/2] UefiCpuPkg: Add PCD PcdCpuSmmAccessOut to control SMM access out
Date: Thu,  1 Aug 2019 00:38:51 +0800	[thread overview]
Message-ID: <20190731163852.191708-2-ray.ni@intel.com> (raw)
In-Reply-To: <20190731163852.191708-1-ray.ni@intel.com>

There is a requirement to allow SMM code access non-SMRAM memory
after ReadyToLock.
The requirement was expected to be satisfied by commit:
c60d36b4d1ee1f69b7cca897d3621dfa951895c2
* UefiCpuPkg/SmmCpu: Block access-out only when static paging is used

Commit c60d36b4 re-interpreted the PcdCpuSmmStaticPageTable as
a way to control whether SMM module can access non-SMRAM memory
after ReadyToLock.
It brought confusion because "static page table" means the page table
is created in advance and there is no dynamic page table modification
at runtime. It only applies to 64bit environment because page table
for memory below 4GB is always created in advance. But the control
of whether allowing SMM module access non-SMRAM memory can also be
applied to 32bit environment.
It makes more sense to have a separate PCD as proposed in this
patch to control the policy.

Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
---
 UefiCpuPkg/UefiCpuPkg.dec | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index 6ddf0cd224..24b44bae39 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -246,6 +246,13 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
   # @Prompt Use static page table for all memory in SMM.
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStaticPageTable|TRUE|BOOLEAN|0x3213210D
 
+  ## Controls whether SMM modules can access all non-SMRAM memory after SmmReadyToLock.
+  #   TRUE  - SMM modules can access all non-SMRAM memory after SmmReadyToLock.<BR>
+  #   FALSE - SMM modules can only access reserved, runtime and ACPI NVS type of non-SMRAM memory
+  #           after SmmReadyToLock.<BR>
+  # @Prompt SMM modules can access all non-SMRAM memory after SmmReadyToLock.
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmAccessOut|FALSE|BOOLEAN|0x3213210F
+
   ## Specifies timeout value in microseconds for the BSP in SMM to wait for all APs to come into SMM.
   # @Prompt AP synchronization timeout value in SMM.
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|1000000|UINT64|0x32132104
-- 
2.21.0.windows.1


  reply	other threads:[~2019-07-31 16:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-31 16:38 [PATCH v2 0/2] Add new PCD PcdCpuSmmAccessOut to control SMM access out Ni, Ray
2019-07-31 16:38 ` Ni, Ray [this message]
2019-07-31 22:21   ` [edk2-devel] [PATCH v2 1/2] UefiCpuPkg: Add " Laszlo Ersek
2019-08-01  6:38     ` Ni, Ray
2019-07-31 16:38 ` [PATCH v2 2/2] UefiCpuPkg/PiSmmCpu: PcdCpuSmmAccessOut controls SMM access-out policy Ni, Ray
2019-07-31 23:13   ` [edk2-devel] " Laszlo Ersek
2019-07-31 23:46     ` Laszlo Ersek
2019-08-01  0:08       ` Laszlo Ersek
2019-08-01  0:02     ` Yao, Jiewen
2019-08-01  1:27       ` Ni, Ray
2019-08-01  1:38         ` Yao, Jiewen
2019-08-01  2:23           ` Ni, Ray
2019-08-01  3:10             ` Yao, Jiewen
2019-08-01  6:25               ` Ni, Ray
2019-08-02  1:41                 ` Laszlo Ersek
2019-08-02  2:04       ` Laszlo Ersek
2019-08-02  2:46         ` Yao, Jiewen
2019-08-02 22:06           ` Laszlo Ersek
2019-08-03  2:23             ` Yao, Jiewen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190731163852.191708-2-ray.ni@intel.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox