tyler.durden
/
audk
mirror of https://github.com/acidanthera/audk.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
audk/MdeModulePkg/Universal/Variable/RuntimeDxe/SpeculationBarrierDxe.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

28 lines
531 B
C
Raw Normal View History

MdeModulePkg/Variable: [CVE-2017-5753] Fix bounds check bypass 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 Variable\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 are 2 similar cases under "case SMM_VARIABLE_FUNCTION_SET_VARIABLE:" and "case SMM_VARIABLE_FUNCTION_VAR_CHECK_VARIABLE_PROPERTY_GET:" as well. This commits also handles them. 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: AuthVariableLibProcessVariable() 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: AuthServiceInternalUpdateVariableWithTimeStamp() mAuthVarLibContextIn->UpdateVariable() VariableExLibUpdateVariable() 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 Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@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>
2018-09-13 09:47:10 +02:00
/** @file
MdeModulePkg/Variable: Update to consume SpeculationBarrier REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1417 Since BaseLib API AsmLfence() is a x86 arch specific API and should be avoided using in generic codes, this commit replaces the usage of AsmLfence() with arch-generic API SpeculationBarrier(). Please note that speculation execution barriers are intended to be asserted for SMM codes, hence, this commit still preserve an empty implementation of the speculation execution barrier for the DXE codes. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
2018-12-21 03:30:22 +01:00
Barrier to stop speculative execution (DXE version).
MdeModulePkg/Variable: [CVE-2017-5753] Fix bounds check bypass 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 Variable\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 are 2 similar cases under "case SMM_VARIABLE_FUNCTION_SET_VARIABLE:" and "case SMM_VARIABLE_FUNCTION_VAR_CHECK_VARIABLE_PROPERTY_GET:" as well. This commits also handles them. 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: AuthVariableLibProcessVariable() 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: AuthServiceInternalUpdateVariableWithTimeStamp() mAuthVarLibContextIn->UpdateVariable() VariableExLibUpdateVariable() 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 Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@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>
2018-09-13 09:47:10 +02:00
Copyright (c) 2018, Intel Corporation. All rights reserved.<BR>
MdeModulePkg: Replace BSD License with BSD+Patent License https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
2019-04-04 01:05:13 +02:00
SPDX-License-Identifier: BSD-2-Clause-Patent
MdeModulePkg/Variable: [CVE-2017-5753] Fix bounds check bypass 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 Variable\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 are 2 similar cases under "case SMM_VARIABLE_FUNCTION_SET_VARIABLE:" and "case SMM_VARIABLE_FUNCTION_VAR_CHECK_VARIABLE_PROPERTY_GET:" as well. This commits also handles them. 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: AuthVariableLibProcessVariable() 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: AuthServiceInternalUpdateVariableWithTimeStamp() mAuthVarLibContextIn->UpdateVariable() VariableExLibUpdateVariable() 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 Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@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>
2018-09-13 09:47:10 +02:00
**/
#include "Variable.h"
/**
MdeModulePkg/Variable: Update to consume SpeculationBarrier REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1417 Since BaseLib API AsmLfence() is a x86 arch specific API and should be avoided using in generic codes, this commit replaces the usage of AsmLfence() with arch-generic API SpeculationBarrier(). Please note that speculation execution barriers are intended to be asserted for SMM codes, hence, this commit still preserve an empty implementation of the speculation execution barrier for the DXE codes. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
2018-12-21 03:30:22 +01:00
This service is consumed by the variable modules to place a barrier to stop
speculative execution.
Ensures that no later instruction will execute speculatively, until all prior
instructions have completed.
MdeModulePkg/Variable: [CVE-2017-5753] Fix bounds check bypass 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 Variable\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 are 2 similar cases under "case SMM_VARIABLE_FUNCTION_SET_VARIABLE:" and "case SMM_VARIABLE_FUNCTION_VAR_CHECK_VARIABLE_PROPERTY_GET:" as well. This commits also handles them. 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: AuthVariableLibProcessVariable() 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: AuthServiceInternalUpdateVariableWithTimeStamp() mAuthVarLibContextIn->UpdateVariable() VariableExLibUpdateVariable() 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 Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@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>
2018-09-13 09:47:10 +02:00
**/
VOID
MdeModulePkg/Variable: Update to consume SpeculationBarrier REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1417 Since BaseLib API AsmLfence() is a x86 arch specific API and should be avoided using in generic codes, this commit replaces the usage of AsmLfence() with arch-generic API SpeculationBarrier(). Please note that speculation execution barriers are intended to be asserted for SMM codes, hence, this commit still preserve an empty implementation of the speculation execution barrier for the DXE codes. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
2018-12-21 03:30:22 +01:00
VariableSpeculationBarrier (
MdeModulePkg/Variable: [CVE-2017-5753] Fix bounds check bypass 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 Variable\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 are 2 similar cases under "case SMM_VARIABLE_FUNCTION_SET_VARIABLE:" and "case SMM_VARIABLE_FUNCTION_VAR_CHECK_VARIABLE_PROPERTY_GET:" as well. This commits also handles them. 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: AuthVariableLibProcessVariable() 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: AuthServiceInternalUpdateVariableWithTimeStamp() mAuthVarLibContextIn->UpdateVariable() VariableExLibUpdateVariable() 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 Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@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>
2018-09-13 09:47:10 +02:00
VOID
)
{
//
// Do nothing.
//
}