Branch: refs/heads/master
Home: https://github.com/tianocore/edk2
Commit: 058196bbb3451a1a342ca9e8679b3c3218b28538
https://github.com/tianocore/edk2/commit/058196bbb3451a1a342ca9e8679b3c3218b28538
Author: Laszlo Ersek <ler...@redhat.com>
Date: 2016-04-28 (Thu, 28 Apr 2016)
Changed paths:
M MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
M MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
Log Message:
-----------
MdeModulePkg: PiDxeS3BootScriptLib: honor PcdAcpiS3Enable
In the edk2 tree, there are currently four drivers that consume
PcdAcpiS3Enable:
IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.inf
>From these, AcpiS3SaveDxe is the only one that isn't also a client of the
S3BootScriptLib class; all the others (BootScriptExecutorDxe,
S3SaveStateDxe, SmmS3SaveState) are clients of the S3BootScriptLib class.
In turn, the edk2 tree contains only one non-Null instance of the
S3BootScriptLib class:
MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
Therefore we can safely state that BootScriptExecutorDxe, S3SaveStateDxe,
and SmmS3SaveState are all linked against PiDxeS3BootScriptLib.
Now, if PcdAcpiS3Enable is FALSE when either of BootScriptExecutorDxe,
SmmS3SaveState, or SmmS3SaveState is dispatched, then the following
happens:
- The constructor of PiDxeS3BootScriptLib, function
S3BootScriptLibInitialize(), registers a protocol installation callback
for gEfiDxeSmmReadyToLockProtocolGuid. Namely, the function
S3BootScriptEventCallBack().
- The driver immediately exits with EFI_UNSUPPORTED from its entry point
function, upon seeing PcdAcpiS3Enable == FALSE. (See commits
800c02fbe2da6, 125e093876414, and d2d38610603f6.)
- This leaves a dangling callback pointer in the DXE core.
- When Platform BDS installs gEfiDxeSmmReadyToLockProtocolGuid (which is a
valid thing to do for locking down SMM, even in the absence of S3
support!), things blow up.
Fix this issue by returning immediately from S3BootScriptLibInitialize()
if PcdAcpiS3Enable is FALSE -- it is useless to initialize the library
instance if the containing driver module exits first thing in its entry
point.
Cc: Feng Tian <feng.t...@intel.com>
Cc: Jiewen Yao <jiewen....@intel.com>
Cc: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Ruiyu Ni <ruiyu...@intel.com>
Cc: Star Zeng <star.z...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <ler...@redhat.com>
Reviewed-by: Jaben Carsey <jaben.car...@intel.com>
Reviewed-by: Jiewen Yao <jiewen....@intel.com>
Reviewed-by: Star Zeng <star.z...@intel.com>
Commit: 70017e446125a454b6dc8f8fe6e4cfe5ff35b38e
https://github.com/tianocore/edk2/commit/70017e446125a454b6dc8f8fe6e4cfe5ff35b38e
Author: Laszlo Ersek <ler...@redhat.com>
Date: 2016-04-28 (Thu, 28 Apr 2016)
Changed paths:
M OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
Log Message:
-----------
OvmfPkg: PlatformBdsLib: lock down SMM in PlatformBdsInit()
OVMF's PlatformBdsLib currently makes SMM vulnerable to the following
attack:
(1) a malicious guest OS copies a UEFI driver module to the EFI system
partition,
(2) the OS adds the driver as a Driver#### option, and references it from
DriverOrder,
(3) at next boot, the BdsEntry() function in
"IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c" processes
Driver#### and DriverOrder between the calls to PlatformBdsInit() and
PlatformBdsPolicyBehavior(),
(4) OVMF locks down SMM only in PlatformBdsPolicyBehavior(), hence the
driver runs with SMM unlocked.
The BdsEntry() function of the MdeModulePkg BDS driver (in file
"MdeModulePkg/Universal/BdsDxe/BdsEntry.c") recommends to "Signal
ReadyToLock event" in PlatformBootManagerBeforeConsole() -- which
corresponds to PlatformBdsInit() --, not in
PlatformBootManagerAfterConsole() -- which corresponds to
PlatformBdsPolicyBehavior().
Albeit an independent question, but it's worth mentioning: this patch also
brings OvmfPkg's PlatformBdsInit() closer to ArmVirtPkg's. Namely, the
latter signals End-of-Dxe in PlatformBdsInit() already.
Cc: Feng Tian <feng.t...@intel.com>
Cc: Jiewen Yao <jiewen....@intel.com>
Cc: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Ruiyu Ni <ruiyu...@intel.com>
Cc: Star Zeng <star.z...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <ler...@redhat.com>
Acked-by: Star Zeng <star.z...@intel.com>
Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>
Commit: 84d2070aef8440819168f7f5736319d375a03447
https://github.com/tianocore/edk2/commit/84d2070aef8440819168f7f5736319d375a03447
Author: Laszlo Ersek <ler...@redhat.com>
Date: 2016-04-28 (Thu, 28 Apr 2016)
Changed paths:
M OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
Log Message:
-----------
OvmfPkg: PlatformBdsLib: lock down SMM regardless of S3
At the moment, the EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is only installed if
S3 is enabled -- at the end of SaveS3BootScript().
While a runtime OS is never booted with SMM unlocked (because the SMM IPL
locks down SMM as a last resort:
> SMM IPL! DXE SMM Ready To Lock Protocol not installed before Ready To
> Boot signal
> SmmInstallProtocolInterface: [EfiSmmReadyToLockProtocol] 0
> Patch page table start ...
> Patch page table done!
> SMM IPL locked SMRAM window
), we shouldn't allow UEFI drivers and applications either to mess with
SMM just because S3 is disabled. So install
EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL in PlatformBdsInit() unconditionally.
Cc: Feng Tian <feng.t...@intel.com>
Cc: Jiewen Yao <jiewen....@intel.com>
Cc: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Ruiyu Ni <ruiyu...@intel.com>
Cc: Star Zeng <star.z...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <ler...@redhat.com>
Acked-by: Star Zeng <star.z...@intel.com>
Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>
Compare: https://github.com/tianocore/edk2/compare/59844e126614...84d2070aef84
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
edk2-commits mailing list
edk2-commits@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-commits