summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* SecurityPkg/OpalPasswordExtraInfoVariable.h: Remove the deprecated guid and ↵UDK2017Eric Dong2019-05-083-32/+0
| | | | | | | | variable. After Opal solution enhance BlockSid solution to consume the TCG PP. This variable and guid definition is deprecated. Signed-off-by: Eric Dong <eric.dong@intel.com>
* SecurityPkg/OpalPasswordSmm: Fix get BlockSid value error.Eric Dong2019-05-083-26/+12
| | | | | | OpalDxe driver already enhanced to use TCG PP to send BlockSid request, so the old variable OPAL_EXTRA_INFO_VAR_NAME is not used by OpalDxe driver. But OpalSmm driver still consume this variable to decide whether need to send BlockSid when S3 resume. This patch fixed this issue by change OpalSmm driver to consume Tcg PP actions. Signed-off-by: Eric Dong <eric.dong@intel.com>
* SecurityPkg/SmmTcg2PhysicalPresenceLib: Add ↵Eric Dong2019-05-081-0/+32
| | | | | | | | Tcg2PhysicalPresenceLibGetManagementFlags support. OpalPasswordSmm driver need to use this API from this library, so enable this API. Signed-off-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/MpInitLib: Avoid call PcdGet* in Ap & Bsp.Eric Dong2018-11-263-8/+8
| | | | | | | | | | | | | | | | | | | | | | | MicrocodeDetect function will run by every threads, and it will use PcdGet to get PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize, if change both PCD default to dynamic, system will in non-deterministic behavior. By design, UEFI/PI services are single threaded and not re-entrant so Multi processor code should not use UEFI/PI services. Here, Pcd protocol/PPI is used to access dynamic PCDs so it would result in non-deterministic behavior. This code get PCD value in BSP and save them in CPU_MP_DATA for Ap. https://bugzilla.tianocore.org/show_bug.cgi?id=726 Cc: Crystal Lee <CrystalLee@ami.com.tw> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> (cherry picked from commit 1e3f7a3782f1928a19bba81d9d0dba28d15fdae5)
* SecurityPkg/OpalPWSupportLib: [CVE-2017-5753] Fix bounds check bypassHao Wu2018-11-211-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 OpalPasswordSupportLib and insert AsmLfence API to mitigate the bounds check bypass issue. For SMI handler SmmOpalPasswordHandler(): Under "case SMM_FUNCTION_SET_OPAL_PASSWORD:", '&DeviceBuffer->OpalDevicePath' can points to a potential cross boundary access of the 'CommBuffer' (controlled external inputs) during speculative execution. This cross boundary access pointer is later passed as parameter 'DevicePath' into function OpalSavePasswordToSmm(). Within function OpalSavePasswordToSmm(), 'DevicePathLen' is an access to the content in 'DevicePath' and can be inferred by code: "CompareMem (&List->OpalDevicePath, DevicePath, DevicePathLen)". One can observe which part of the content within either '&List->OpalDevicePath' or 'DevicePath' was brought into cache to possibly reveal the value of 'DevicePathLen'. Hence, this commit adds a AsmLfence() after the boundary/range checks of 'CommBuffer' to prevent the speculative execution. 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: Star Zeng <star.zeng@intel.com> Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* MdeModulePkg/SmmCorePerfLib: [CVE-2017-5753] Fix bounds check bypassHao Wu2018-11-211-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 SmmCorePerformanceLib and insert AsmLfence API to mitigate the bounds check bypass issue. For SMI handler SmmPerformanceHandlerEx(): Under "case SMM_PERF_FUNCTION_GET_GAUGE_DATA :", 'SmmPerfCommData->LogEntryKey' can be a potential cross boundary access of the 'CommBuffer' (controlled external inputs) during speculative execution. This cross boundary access is then assign to parameter 'LogEntryKey'. And the value of 'LogEntryKey' can be inferred by code: CopyMem ( (UINT8 *) &GaugeDataEx[Index], (UINT8 *) &GaugeEntryExArray[LogEntryKey++], sizeof (GAUGE_DATA_ENTRY_EX) ); One can observe which part of the content within 'GaugeEntryExArray' was brought into cache to possibly reveal the value of 'LogEntryKey'. Hence, this commit adds a AsmLfence() after the boundary/range checks of 'CommBuffer' to prevent the speculative execution. And there is 1 similar case for SMI handler SmmPerformanceHandler() as well. This commit 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 Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Laszlo Ersek <lersek@redhat.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>
* UefiCpuPkg/PiSmmCpuDxeSmm: [CVE-2017-5753] Fix bounds check bypassHao Wu2018-11-141-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. It is possible for SMI handler(s) to call EFI_SMM_CPU_PROTOCOL service ReadSaveState() and use the content in the 'CommBuffer' (controlled external inputs) as the 'CpuIndex'. So this commit will insert AsmLfence API to mitigate the bounds check bypass issue within SmmReadSaveState(). For SmmReadSaveState(): The 'CpuIndex' will be passed into function ReadSaveStateRegister(). And then in to ReadSaveStateRegisterByIndex(). With the call: ReadSaveStateRegisterByIndex ( CpuIndex, SMM_SAVE_STATE_REGISTER_IOMISC_INDEX, sizeof(IoMisc.Uint32), &IoMisc.Uint32 ); The 'IoMisc' can be a cross boundary access during speculative execution. Later, 'IoMisc' is used as the index to access buffers 'mSmmCpuIoWidth' and 'mSmmCpuIoType'. One can observe which part of the content within those buffers was brought into cache to possibly reveal the value of 'IoMisc'. Hence, this commit adds a AsmLfence() after the check of 'CpuIndex' within function SmmReadSaveState() to prevent the speculative execution. 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: Michael D Kinney <michael.d.kinney@intel.com> 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: Eric Dong <eric.dong@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> (cherry picked from commit 5b02be4d9a234d80c7578fc3a0c789d22ce83f38)
* MdeModulePkg/Variable: [CVE-2017-5753] Fix bounds check bypassHao Wu2018-11-147-0/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit e83d841fdc2878959185c4c6cc38a7a1e88377a4)
* MdeModulePkg/SmmLockBox: [CVE-2017-5753] Fix bounds check bypassHao Wu2018-11-141-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit ee65b84e7663d12c1f950a418a0ed63776a80e4f)
* MdeModulePkg/FaultTolerantWrite:[CVE-2017-5753]Fix bounds check bypassHao Wu2018-11-142-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 FaultTolerantWriteDxe driver and insert AsmLfence API to mitigate the bounds check bypass issue. For SMI handler SmmFaultTolerantWriteHandler(): Under "case FTW_FUNCTION_WRITE:", 'SmmFtwWriteHeader->Length' can be a potential cross boundary access of the 'CommBuffer' (controlled external inputs) during speculative execution. This cross boundary access is later passed as parameter 'Length' into function FtwWrite(). Within function FtwWrite(), the value of 'Length' can be inferred by code: "CopyMem (MyBuffer + Offset, 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. 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> (cherry picked from commit cb54cd24634cfeccadb661f7f65aab3adee05e1c)
* MdePkg/BaseLib: Add new AsmLfence APIHao Wu2018-11-144-0/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1193 This commit will add a new BaseLib API AsmLfence(). This API will perform a serializing operation on all load-from-memory instructions that were issued prior to the call of this function. Please note that this API is only available on IA-32 and x64. The purpose of adding this API is to mitigate of the [CVE-2017-5753] Bounds Check Bypass issue when untrusted data are being processed within SMM. More details can be referred at the 'Bounds check bypass mitigation' section at the below link: https://software.intel.com/security-software-guidance/insights/host-firmware-speculative-execution-side-channel-mitigation Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Michael D Kinney <michael.d.kinney@intel.com> 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: Liming Gao <liming.gao@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> (cherry picked from commit 2ecd829972f8553de83fbf943c5b89863999d7c8)
* UefiCpuPkg/SmmCpuFeaturesLib: [CVE-2017-5715] Stuff RSB before RSMHao Wu2018-11-146-5/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1093 Return Stack Buffer (RSB) is used to predict the target of RET instructions. When the RSB underflows, some processors may fall back to using branch predictors. This might impact software using the retpoline mitigation strategy on those processors. This commit will add RSB stuffing logic before returning from SMM (the RSM instruction) to avoid interfering with non-SMM usage of the retpoline technique. After the stuffing, RSB entries will contain a trap like: @SpecTrap: pause lfence jmp @SpecTrap A more detailed explanation of the purpose of commit is under the 'Branch target injection mitigation' section of the below link: https://software.intel.com/security-software-guidance/insights/host-firmware-speculative-execution-side-channel-mitigation Please note that this commit requires further actions (BZ 1091) to remove the duplicated 'StuffRsb.inc' files and merge them into one under a UefiCpuPkg package-level directory (such as UefiCpuPkg/Include/). REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1091 Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> (cherry picked from commit 0df5056012e64fdf14cab0cd94e3b8630a3a88ba)
* UefiCpuPkg/PiSmmCpuDxeSmm: [CVE-2017-5715] Stuff RSB before RSMHao Wu2018-11-146-0/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1093 Return Stack Buffer (RSB) is used to predict the target of RET instructions. When the RSB underflows, some processors may fall back to using branch predictors. This might impact software using the retpoline mitigation strategy on those processors. This commit will add RSB stuffing logic before returning from SMM (the RSM instruction) to avoid interfering with non-SMM usage of the retpoline technique. After the stuffing, RSB entries will contain a trap like: @SpecTrap: pause lfence jmp @SpecTrap A more detailed explanation of the purpose of commit is under the 'Branch target injection mitigation' section of the below link: https://software.intel.com/security-software-guidance/insights/host-firmware-speculative-execution-side-channel-mitigation Please note that this commit requires further actions (BZ 1091) to remove the duplicated 'StuffRsb.inc' files and merge them into one under a UefiCpuPkg package-level directory (such as UefiCpuPkg/Include/). REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1091 Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> (cherry picked from commit 02f7fd158e977d0368705129c52a800217fe8887)
* IntelFrameworkModulePkg: Fix UEFI and Tiano Decompression logic issueLiming Gao2018-11-141-0/+6
| | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1317 This is a regression issue caused by 684db6da64bc7b5faee4e1174e801c245f563b5c. In Decode() function, once mOutBuf is fully filled, Decode() should return. Current logic misses the checker of mOutBuf after while() loop. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com> (cherry picked from commit ade71c52a49d659b20c0b433fb11ddb4f4f543c4)
* MdePkg BaseUefiDecompressLib: Fix UEFI Decompression logic issueLiming Gao2018-11-141-0/+6
| | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1317 This is a regression issue caused by 2ec7953d49677142c5f7552e9e3d96fb406ba0c4. In Decode() function, once mOutBuf is fully filled, Decode() should return. Current logic misses the checker of mOutBuf after while() loop. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com> (cherry picked from commit 1c4cecc9fd314de0dce8125b0d4b45967637a401)
* BaseTools: Fix UEFI and Tiano Decompression logic issueLiming Gao2018-11-142-0/+12
| | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1317 This is a regression issue caused by 041d89bc0f0119df37a5fce1d0f16495ff905089. In Decode() function, once mOutBuf is fully filled, Decode() should return. Current logic misses the checker of mOutBuf after while() loop. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com> (cherry picked from commit 5e45a1fdcfbf9b2b389122eb97475148594625f8)
* IntelSiliconPkg IntelVTdDxe: Check HeaderType if func 0 is implementedStar Zeng2018-11-071-8/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1169 Current code checks HeaderType of Function 0 even Function 0 is not implemented. HeaderType value will be 0xFF if Function 0 is not implemented, then MaxFunction will be set to PCI_MAX_FUNC + 1. The code can be optimized to only check HeaderType if Function 0 is implemented. Test done: With this patch, the result is same with the result after the patch at https://lists.01.org/pipermail/edk2-devel/2018-September/029623.html. Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Rangasai V Chaganty <rangasai.v.chaganty@intel.com> Cc: Tomson Chang <tomson.chang@intel.com> Cc: Jenny Huang <jenny.huang@intel.com> Cc: Amy Chan <amy.chan@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> (cherry picked from commit b06dfd40bb5cf9fdd626a79a300253f193b600ae)
* IntelSiliconPkg IntelVTdDxe: Optimize when func 0 is not implementedStar Zeng2018-11-071-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1169 PCI spec: They are also required to always implement function 0 in the device. Implementing other functions is optional and may be assigned in any order (i.e., a two-function device must respond to function 0 but can choose any of the other possible function numbers (1-7) for the second function). This patch updates ScanPciBus() to not scan other functions if function 0 is not implemented. Test done: Added debug code below in the second loop of ScanPciBus(), compared the debug logs with and without this patch, many non-0 unimplemented functions are skipped correctly. DEBUG (( DEBUG_INFO, "%a() B%02xD%02xF%02x VendorId: %04x DeviceId: %04x\n", __FUNCTION__, Bus, Device, Function, VendorID, DeviceID )); Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Rangasai V Chaganty <rangasai.v.chaganty@intel.com> Cc: Tomson Chang <tomson.chang@intel.com> Cc: Jenny Huang <jenny.huang@intel.com> Cc: Amy Chan <amy.chan@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> (cherry picked from commit e69d7e99e77d2f7aa1390502d8b42d61f9aeb99a)
* BaseTools: Add more checker in Decompress algorithm to access the valid ↵Liming Gao2018-10-242-4/+48
| | | | | | | | | | | | | | buffer (CVE FIX) Fix CVE-2017-5731,CVE-2017-5732,CVE-2017-5733,CVE-2017-5734,CVE-2017-5735 https://bugzilla.tianocore.org/show_bug.cgi?id=686 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Holtsclaw Brent <brent.holtsclaw@intel.com> Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> (cherry picked from commit 041d89bc0f0119df37a5fce1d0f16495ff905089)
* IntelFrameworkModulePkg: Add more checker in UefiTianoDecompressLib (CVE FIX)Liming Gao2018-10-241-2/+14
| | | | | | | | | | | | | Fix CVE-2017-5731,CVE-2017-5732,CVE-2017-5733,CVE-2017-5734,CVE-2017-5735 https://bugzilla.tianocore.org/show_bug.cgi?id=686 To make sure the valid buffer be accessed only. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Holtsclaw Brent <brent.holtsclaw@intel.com> Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> (cherry picked from commit 684db6da64bc7b5faee4e1174e801c245f563b5c)
* MdePkg: Add more checker in UefiDecompressLib to access the valid buffer ↵Liming Gao2018-10-241-2/+15
| | | | | | | | | | | | | | only (CVE FIX) Fix CVE-2017-5731,CVE-2017-5732,CVE-2017-5733,CVE-2017-5734,CVE-2017-5735 https://bugzilla.tianocore.org/show_bug.cgi?id=686 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Holtsclaw Brent <brent.holtsclaw@intel.com> Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> (cherry picked from commit 2ec7953d49677142c5f7552e9e3d96fb406ba0c4)
* MdeModulePkg Variable: Fix Timestamp zeroing issue on APPEND_WRITEStar Zeng2018-10-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=415 When SetVariable() to a time based auth variable with APPEND_WRITE attribute, and if the EFI_VARIABLE_AUTHENTICATION_2.TimeStamp in the input Data is earlier than current value, it will cause timestamp zeroing. This issue may bring time based auth variable downgrade problem. For example: A vendor released three certs at 2014, 2015, and 2016, and system integrated the 2016 cert. User can SetVariable() with 2015 cert and APPEND_WRITE attribute to cause timestamp zeroing first, then SetVariable() with 2014 cert to downgrade the cert. This patch fixes this issue. Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> (cherry picked from commit b7dc8888f31402f410c53242839271ba3b94b619)
* MdeModulePkg/NvmExpressDxe: fix error status overrideHeyi Guo2018-09-201-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit f6b139b added return status handling to PciIo->Mem.Write. However, the second status handling will override EFI_DEVICE_ERROR returned in this branch: // // Check the NVMe cmd execution result // if (Status != EFI_TIMEOUT) { if ((Cq->Sct == 0) && (Cq->Sc == 0)) { Status = EFI_SUCCESS; } else { Status = EFI_DEVICE_ERROR; ^^^^^^^^^^^^^^^^ Since PciIo->Mem.Write will probably return SUCCESS, it causes NvmExpressPassThru to return SUCCESS even when DEVICE_ERROR occurs. Callers of NvmExpressPassThru will then continue executing which may cause further unexpected results, e.g. DiscoverAllNamespaces couldn't break out the loop. So we save previous status before calling PciIo->Mem.Write and restore the previous one if it already contains error. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Heyi Guo <heyi.guo@linaro.org> Cc: Eric Dong <eric.dong@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> (cherry picked from commit 9a77210b43ef34af52ea7285fadc0ce5779306fe)
* SecurityPkg OpalPasswordSupportLib: Add check to avoid potential buffer ↵Eric Dong2018-08-014-24/+42
| | | | | | | | | | | | | | | | | overflow. Current code not check the CommunicationBuffer size before use it. Attacker can read beyond the end of the (untrusted) commbuffer into controlled memory. Attacker can get access outside of valid SMM memory regions. This patch add check before use it. bugz: https://bugzilla.tianocore.org/show_bug.cgi?id=198 Cc: Yao Jiewen <jiewen.yao@intel.com> Cc: Wu Hao <hao.a.wu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Yao Jiewen <jiewen.yao@intel.com>
* UefiCpuPkg/PiSmmCpu: Check GCD and UEFI mem attrib table.Jiewen Yao2018-07-264-27/+217
| | | | | | | | | | | | | | | 1) UefiCpuPkg/PiSmmCpu: Check for untested memory in GCD It treats GCD untested memory as invalid SMM communication buffer. 2) UefiCpuPkg/PiSmmCpu: Check EFI_RUNTIME_RO in UEFI mem attrib table. It treats the UEFI runtime page with EFI_MEMORY_RO attribute as invalid SMM communication buffer. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
* MdeModulePkg/DxeCore: Not update RtCode in MemAttrTable after EndOfDxeJiewen Yao2018-07-261-0/+13
| | | | | | | | | | | | | | | We want to provide precise info in MemAttribTable to both OS and SMM, and SMM only gets the info at EndOfDxe. So we do not update RtCode entry in EndOfDxe. The impact is that if 3rd part OPROM is runtime, it cannot be executed at UEFI runtime phase. Currently, we do not see compatibility issue, because the only runtime OPROM we found before in UNDI, and UEFI OS will not use UNDI interface in OS. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
* MdeModulePkg/DxeCore: Install UEFI mem attrib table at EndOfDxe.Jiewen Yao2018-07-261-1/+35
| | | | | | | | So that the SMM can consume it to set page protection for the UEFI runtime page with EFI_MEMORY_RO attribute. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
* MdePkg/SmmMemLib: Check EFI_MEMORY_RO in UEFI mem attrib table.Jiewen Yao2018-07-262-4/+60
| | | | | | | | It treats the UEFI runtime page with EFI_MEMORY_RO attribute as invalid SMM communication buffer. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
* MdePkg/SmmMemLib: Check for untested memory in GCDJiewen Yao2018-07-262-7/+93
| | | | | | | | It treats GCD untested memory as invalid SMM communication buffer. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
* SignedCapsulePkg SystemFirmwareUpdateDxe: Fix failure caused by d69d922Star Zeng2018-07-131-5/+16
| | | | | | | | | | | | | | | | | | d69d9227d046211265de1fab5580c50a65944614 caused system firmware update failure. It is because FindMatchingFmpHandles() is expected to return handles matched, but the function returns all handles found. This patch is to fix the issue. This patch also assigns mSystemFmpPrivate->Handle for "case 1:" path in case the Handle is needed by other place in future. Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> (cherry picked from commit 665bfd41ac32b364201c07dc1c5434432730c034)
* SignedCapsulePkg/SystemFirmwareReportDxe: Pass thru on same handleKinney, Michael D2018-07-131-3/+7
| | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=928 Use HandleProtocol() to pass thru a SetImage() call to the System FMP Protocol that must be on the same handle as the FMP Protocol. Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> (cherry picked from commit 153f5c7a93be09403891404c06e5b0e24eb019a3)
* SignedCapsulePkg/SystemFirmwareUpdateDxe: Single FMPKinney, Michael D2018-07-131-21/+322
| | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=928 Uninstall all System FMP Protocols for the current FW device. If an FMP Protocol for the current FW device is already present, then install the new System FMP protocol onto the same handle as the FMP Protocol. Otherwise, install the FMP protocol onto a new handle. This supports use cases where multiple capsules for the same system firmware device are processed on the same boot of the platform. It guarantees there is at most one FMP protocol for each system firmware device. Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> (cherry picked from commit d69d9227d046211265de1fab5580c50a65944614)
* MdeModulePkg/PciHostBridgeDxe: Make bitwise operands of the same sizeHao Wu2018-06-061-1/+1
| | | | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> (cherry picked from commit 8df95dd04f467c5626850b34dec564dec918c47d)
* MdeModulePkg/PciHostBridgeDxe: Fix EBC build failureDandan Bi2018-06-061-2/+2
| | | | | | | | Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> (cherry picked from commit 7a85e8474127ae6df47337a04797b2b443b57682)
* SecurityPkg:Tcg2Smm: Update TcgNvs info after memory is allocatedZhang, Chao B2018-05-251-7/+12
| | | | | | | | | | | | | Update package format info in _PRS to TcgNvs after memory is allocated. Change-Id: Icfadb350e60d3ed2df332e92c257ce13309c0018 Contributed-under: TianoCore Contribution Agreement 1.1 Cc: Yao Jiewen <jiewen.yao@intel.com> Cc: Long Qin <qin.long@intel.com> Signed-off-by: Zhang, Chao B <chao.b.zhang@intel.com> Reviewed-by: Long Qin <qin.long@intel.com> (cherry picked from commit 1ea08a3dcdd61c7481ec78ad8b8037ee6ca45402) (cherry picked from commit fb8254478f7259d22d8433f6729307e001b81bdd)
* MdePkg/ResetNotification: Rename to UnregisterResetNotifyRuiyu Ni2018-05-251-1/+1
| | | | | | | | | | | | | | | UEFI Spec uses UnRegisterResetNotify in protocol structure definition but uses UnregisterResetNotify in the function prototype definition. By searching the entire spec, Unregister* is used for SIMPLE_TEXT_INPUT_EX_PROTOCOL.UnregisterKeyNotify(). So choose to use UnregisterResetNotify for consistency. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> (cherry picked from commit fcccba378bebd740bfa3e36d684215d739421181)
* MdePkg: Add ResetNotification protocol definitionRuiyu Ni2018-05-252-0/+89
| | | | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> (cherry picked from commit 342470a6f83a29002ddcf99221343d2e5261eb6b)
* MdePkg/SmmPeriodicSmiLib: Get Periodic SMI Context More RobustlyRuiyu Ni2018-05-211-23/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PeriodicSmiDispatchFunction() in SmmPeriodicSmiLib may assert with "Bad CR signature". Currently, the SetActivePeriodicSmiLibraryHandler() function (invoked at the beginning of the PeriodicSmiDispatchFunction() function) attempts to locate the PERIODIC_SMI_LIBRARY_HANDLER_CONTEXT structure pointer for the current periodic SMI from a given EFI_SMM_PERIODIC_TIMER_REGISTER_CONTEXT (RegiserContext) structure pointer (using the CR macro). The RegisterContext structure pointer passed to the PeriodicSmiDispatchFunction() is assumed to point to the same RegisterContext structure address given to the SmmPeriodicTimerDispatch2 protocol Register() API in PeriodicSmiEnable(). However, certain SmmPeriodicTimerDispatch2 implementation may copy the RegisterContext to a local buffer and pass that address as the context to PeriodicSmiDispatchFunction() in which case usage of the CR macro to find the parent structure base fails. The patch uses the LookupPeriodicSmiLibraryHandler() function to find the PERIODIC_SMI_LIBRARY_HANDLER_CONTEXT structure pointer. This works even in this scenario since the DispatchHandle returned from the SmmPeriodicTimerDispatch2 Register() function uniquely identifies that registration. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> (cherry picked from commit 1e35fcc9ee8b6b991535d9d6731d0e04169b99c0)
* SourceLevelDebugPkg DebugCommUsb3: Return error when debug cap is resetStar Zeng2018-05-111-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When source level debug is enabled, but debug cable is not connected, XhcResetHC() in XhciReg.c will reset the host controller, the debug capability registers will be also reset. After the code in InitializeUsbDebugHardware() sets DCE bit and LSE bit to "1" in DCCTRL, there will be DMA on 0 (the value of some debug capability registers for data transfer is 0) address buffer, fault info like below will appear when IOMMU based on VTd is enabled. VER_REG - 0x00000010 CAP_REG - 0x00D2008C40660462 ECAP_REG - 0x0000000000F050DA GSTS_REG - 0xC0000000 RTADDR_REG - 0x0000000086512000 CCMD_REG - 0x2800000000000000 FSTS_REG - 0x00000002 FECTL_REG - 0xC0000000 FEDATA_REG - 0x00000000 FEADDR_REG - 0x00000000 FEUADDR_REG - 0x00000000 FRCD_REG[0] - 0xC0000006000000A0 0000000000000000 Fault Info - 0x0000000000000000 Source - B00 D14 F00 Type - 1 (read) Reason - 6 IVA_REG - 0x0000000000000000 IOTLB_REG - 0x1200000000000000 This patch is to return error for the case. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> (cherry picked from commit df67a480eb81821ba21ad6909e2fda287e745834)
* SourceLevelDebugPkg DebugUsb3: Re-Support IOMMUStar Zeng2018-05-116-112/+954
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> (cherry picked from commit 75787f6580f331b8cf6765c677c6a8bdccb98270)
* SourceLevelDebugPkg DebugCommUsb3: Refine some formats/commentsStar Zeng2018-05-112-50/+13
| | | | | | | | | | | | Refine some formats/comments and remove some unused prototypes. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> (cherry picked from commit f0c562761f397733e2294c8725512e31c352cb72)
* SourceLevelDebugPkg DebugUsb3: Re-Fix GCC build failuresStar Zeng2018-05-112-5/+1
| | | | | | | | | | | | | | | | | | | | | Fix GCC build failures below. variable 'EvtTrb' set but not used [-Werror=unused-but-set-variable] variable 'Index' set but not used [-Werror=unused-but-set-variable] The build failure could only be caught with -D SOURCE_DEBUG_USE_USB3 build flag. ad6040ec9b5bbc462762331f9738b8e42c0b9c80 needs to be also reverted when reverting IOMMU support patches, otherwise there will be conflict. This patch is to re-do ad6040ec9b5bbc462762331f9738b8e42c0b9c80. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> (cherry picked from commit 3ecca0033039cac31845b9dbb9e4a3d6b8148b01)
* Revert "DebugUsb3: Support IOMMU"Star Zeng2018-05-116-842/+129
| | | | | | | | | | | | This reverts commit de8373fa07f87ca735139bb86c51e2c29fb1d956. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> (cherry picked from commit 1f279e7a53f5a576682214a550810faff92fd9a1)
* Revert "DebugUsb3: Fix GCC build failures"Star Zeng2018-05-112-1/+5
| | | | | | | | | | | | This reverts commit ad6040ec9b5bbc462762331f9738b8e42c0b9c80. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> (cherry picked from commit 373b1d0ee31ea2e2868307ea82277271b18a7be7)
* Revert "DebugUsb3: Check mUsb3Instance before dereferencing it"Star Zeng2018-05-111-1/+1
| | | | | | | | | | | | This reverts commit 6ef394ffe29bbc67038fc16ed540bfe6eed10e16. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> (cherry picked from commit abea3bca8212f8c2ea34da6b9f6315d755537767)
* SourceLevelDebugPkg DebugUsb3: Check mUsb3Instance before dereferencing itStar Zeng2018-05-111-1/+1
| | | | | | | | | Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> (cherry picked from commit 6ef394ffe29bbc67038fc16ed540bfe6eed10e16)
* SourceLevelDebugPkg DebugUsb3: Fix GCC build failuresStar Zeng2018-05-112-5/+1
| | | | | | | | | | | | | | | | Fix GCC build failures below. variable 'EvtTrb' set but not used [-Werror=unused-but-set-variable] variable 'Index' set but not used [-Werror=unused-but-set-variable] The build failure could only be caught with -D SOURCE_DEBUG_USE_USB3 build flag. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> (cherry picked from commit ad6040ec9b5bbc462762331f9738b8e42c0b9c80)
* SourceLevelDebugPkg DebugUsb3: Support IOMMUStar Zeng2018-05-116-129/+842
| | | | | | | | | | | | | For PEI, allocate granted DMA buffer from IOMMU PPI. For DXE, map DMA buffer by PciIo. Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> (cherry picked from commit de8373fa07f87ca735139bb86c51e2c29fb1d956)
* SourceLevelDebugPkg DebugUsb3: Fix some typosStar Zeng2018-05-114-12/+12
| | | | | | | | | Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> (cherry picked from commit f4043414da4b0415aa97dba83f0e59e2ce4334a9)
* SourceLevelDebugPkg DebugAgentLib: Rename IsBsp to DebugAgentIsBspStar Zeng2018-05-113-8/+8
| | | | | | | | | | | | | For avoiding function name confliction, rename IsBsp to DebugAgentIsBsp. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> (cherry picked from commit a2acb04ca67853519a514a986de11b6bc468d564)
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-02 14:56:22 +0000