summaryrefslogtreecommitdiff
path: root/OvmfPkg/Sec/SecMain.inf
diff options
context:
space:
mode:
authorLaszlo Ersek <lersek@redhat.com>2015-11-30 18:41:14 +0000
committerlersek <lersek@Edk2>2015-11-30 18:41:14 +0000
commit320b4f084a256e16a7f0cbfa5f0b5c8e0bb1a0ac (patch)
treed996e90cb82f8d383a9a1c1c17d02e21299ac0e2 /OvmfPkg/Sec/SecMain.inf
parent1f695483e6bc2be8054d2cc677662e7df61e3962 (diff)
downloadedk2-platforms-320b4f084a256e16a7f0cbfa5f0b5c8e0bb1a0ac.tar.xz
OvmfPkg: Sec: force reinit of BaseExtractGuidedSectionLib handler table
BaseExtractGuidedSectionLib uses a table at the static physical address PcdGuidedExtractHandlerTableAddress, and modules that are linked against BaseExtractGuidedSectionLib are expected to work together on that table. Namely, some modules can register handlers for GUIDed sections, some other modules can decode such sections with the pre-registered handlers. The table carries persistent information between these modules. BaseExtractGuidedSectionLib checks a table signature whenever it is used (by whichever module that is linked against it), and at the first use (identified by a signature mismatch) it initializes the table. One of the module types that BaseExtractGuidedSectionLib can be used with is SEC, if the SEC module in question runs with the platform's RAM already available. In such cases the question emerges whether the initial contents of the RAM (ie. contents that predate the very first signature check) can be trusted. Normally RAM starts out with all zeroes (leading to a signature mismatch on the first check); however a malicious runtime OS can populate the area with some payload, then force a warm platform reset or an S3 suspend-and-resume. In such cases the signature check in the SEC module might not fire, and ExtractGuidedSectionDecode() might run code injected by the runtime OS, as part of SEC (ie. with high privileges). Therefore we clear the handler table in SEC. See also git commit ad43bc6b2e (SVN rev 15433) -- this patch secures the (d) and (e) code paths examined in that commit. Furthermore, a non-malicious runtime OS will observe no change in behavior; see case (c) in said commit. Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> [michael.d.kinney@intel.com: prevent VS20xx loop intrinsic with volatile] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19035 6f19259b-4bc3-4df7-8a09-765794883524
Diffstat (limited to 'OvmfPkg/Sec/SecMain.inf')
-rw-r--r--OvmfPkg/Sec/SecMain.inf2
1 files changed, 2 insertions, 0 deletions
diff --git a/OvmfPkg/Sec/SecMain.inf b/OvmfPkg/Sec/SecMain.inf
index 2f78f3c851..415731ce54 100644
--- a/OvmfPkg/Sec/SecMain.inf
+++ b/OvmfPkg/Sec/SecMain.inf
@@ -68,3 +68,5 @@
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
+ gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
+ gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize