]> git.proxmox.com Git - mirror_edk2.git/commitdiff
MdeModulePkg/SmmLockBox: [CVE-2017-5753] Fix bounds check bypass
authorHao Wu <hao.a.wu@intel.com>
Thu, 13 Sep 2018 07:35:12 +0000 (15:35 +0800)
committerHao Wu <hao.a.wu@intel.com>
Sun, 30 Sep 2018 05:06:42 +0000 (13:06 +0800)
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1194

Speculative execution is used by processor to avoid having to wait for
data to arrive from memory, or for previous operations to finish, the
processor may speculate as to what will be executed.

If the speculation is incorrect, the speculatively executed instructions
might leave hints such as which memory locations have been brought into
cache. Malicious actors can use the bounds check bypass method (code
gadgets with controlled external inputs) to infer data values that have
been used in speculative operations to reveal secrets which should not
otherwise be accessed.

This commit will focus on the SMI handler(s) registered within the
SmmLockBox driver and insert AsmLfence API to mitigate the
bounds check bypass issue.

For SMI handler SmmLockBoxHandler():

Under "case EFI_SMM_LOCK_BOX_COMMAND_SAVE:", the 'CommBuffer' (controlled
external inputs) is passed to function SmmLockBoxSave().

'TempLockBoxParameterSave.Length' can be a potential cross boundary access
of the 'CommBuffer' during speculative execution. This cross boundary
access is later passed as parameter 'Length' into function SaveLockBox().

Within function SaveLockBox(), the value of 'Length' can be inferred by
code:
"CopyMem ((VOID *)(UINTN)SmramBuffer, (VOID *)(UINTN)Buffer, Length);".
One can observe which part of the content within 'Buffer' was brought into
cache to possibly reveal the value of 'Length'.

Hence, this commit adds a AsmLfence() after the boundary/range checks of
'CommBuffer' to prevent the speculative execution.

And there is a similar case under "case EFI_SMM_LOCK_BOX_COMMAND_UPDATE:"
function SmmLockBoxUpdate() as well. This commits also handles it.

A more detailed explanation of the purpose of commit is under the
'Bounds check bypass mitigation' section of the below link:
https://software.intel.com/security-software-guidance/insights/host-firmware-speculative-execution-side-channel-mitigation

And the document at:
https://software.intel.com/security-software-guidance/api-app/sites/default/files/337879-analyzing-potential-bounds-Check-bypass-vulnerabilities.pdf

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.c

index 5a11743cb921bb2f47e8ba8920a52567b2ee33a8..c1c9aa5663b3e65a6f9a1fb8146bb23b90625df3 100644 (file)
@@ -76,6 +76,11 @@ SmmLockBoxSave (
     LockBoxParameterSave->Header.ReturnStatus = (UINT64)EFI_ACCESS_DENIED;\r
     return ;\r
   }\r
+  //\r
+  // The AsmLfence() call here is to ensure the above range check for the\r
+  // CommBuffer have been completed before calling into SaveLockBox().\r
+  //\r
+  AsmLfence ();\r
 \r
   //\r
   // Save data\r
@@ -160,6 +165,11 @@ SmmLockBoxUpdate (
     LockBoxParameterUpdate->Header.ReturnStatus = (UINT64)EFI_ACCESS_DENIED;\r
     return ;\r
   }\r
+  //\r
+  // The AsmLfence() call here is to ensure the above range check for the\r
+  // CommBuffer have been completed before calling into UpdateLockBox().\r
+  //\r
+  AsmLfence ();\r
 \r
   //\r
   // Update data\r