tree f61a1f4d87c8ec91f463f174068eed55f29ba606
parent b00c4c12944418a7587acf9ff0edb8d1cfc43be4
author Hao Wu <hao.a.wu@intel.com> 1542262182 +0800
committer Hao Wu <hao.a.wu@intel.com> 1542267632 +0800

SecurityPkg/VariableAuth: [CVE-2017-5753] Fix bounds check bypass

This commit applies edk2 master branch commit
e83d841fdc2878959185c4c6cc38a7a1e88377a4 to the VariableAuthenticated
driver.

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
VariableAuthenticated\RuntimeDxe driver and insert AsmLfence API to
mitigate the bounds check bypass issue.

For SMI handler SmmVariableHandler():

Under "case SMM_VARIABLE_FUNCTION_GET_VARIABLE:",
'SmmVariableHeader->NameSize' can be a potential cross boundary access of
the 'CommBuffer' (controlled external input) during speculative execution.

This cross boundary access is later used as the index to access array
'SmmVariableHeader->Name' by code:
"SmmVariableHeader->Name[SmmVariableHeader->NameSize/sizeof (CHAR16) - 1]"
One can observe which part of the content within array was brought into
cache to possibly reveal the value of 'SmmVariableHeader->NameSize'.

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

And there is 1 similar cases under
"case SMM_VARIABLE_FUNCTION_SET_VARIABLE:" as well. This commits also
handles it.

Also, under "case SMM_VARIABLE_FUNCTION_SET_VARIABLE:",
'(UINT8 *)SmmVariableHeader->Name + SmmVariableHeader->NameSize' points to
the 'CommBuffer' (with some offset) and then passed as parameter 'Data' to
function VariableServiceSetVariable().

Within function VariableServiceSetVariable(), there is a sanity check for
EFI_VARIABLE_AUTHENTICATION_2 descriptor for the data pointed by 'Data'.
If this check is speculatively bypassed, potential cross-boundary data
access for 'Data' is possible to be revealed via the below function calls
sequence during speculative execution:

ProcessVarWithPk() or ProcessVarWithKek()

Within function ProcessVarWithPk() or ProcessVarWithKek(), for the code
"PayloadSize = DataSize - AUTHINFO2_SIZE (Data);", 'AUTHINFO2_SIZE (Data)'
can be a cross boundary access during speculative execution.

Then, 'PayloadSize' is possible to be revealed by the function call
sequence:

UpdateVariable()
CopyMem()

Hence, this commit adds a AsmLfence() after the sanity check for
EFI_VARIABLE_AUTHENTICATION_2 descriptor upon 'Data' within function
VariableServiceSetVariable() to prevent the speculative execution.

Also, please note that the change made within function
VariableServiceSetVariable() will affect DXE as well. However, since we
only focuses on the SMM codes, the commit will introduce a new module
internal function called VariableLoadFence() to handle this. This internal
function will have 2 implementations (1 for SMM, 1 for DXE). For the SMM
implementation, it is a wrapper to call the AsmLfence() API; for the DXE
implementation, it is empty.

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>