summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* pip: bump edk2-pytool-library from 0.19.9 to 0.21.4dependabot/pip/edk2-pytool-library-0.21.4dependabot[bot]2024-04-021-1/+1
| | | | | | | | | | | | | | Bumps [edk2-pytool-library](https://github.com/tianocore/edk2-pytool-library) from 0.19.9 to 0.21.4. - [Release notes](https://github.com/tianocore/edk2-pytool-library/releases) - [Commits](https://github.com/tianocore/edk2-pytool-library/compare/v0.19.9...v0.21.4) --- updated-dependencies: - dependency-name: edk2-pytool-library dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
* CryptoPkg: Remove interdependence for RsaPssVerifyHou, Wenxing2024-04-011-63/+11
| | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4742 Remove interdependence for RsaPssVerify, only use original mbedtls API. Because APIs such as Sha512Init may be closed by the platform PCD. And this patch optimize the hash flow. Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Yi Li <yi1.li@intel.com> Signed-off-by: Wenxing Hou <wenxing.hou@intel.com> Reviewed-by: Yi Li <yi1.li@intel.com>
* CryptoPkg: Update Md5/Sha1/Sha2 by using new mbedtls apiHou, Wenxing2024-04-014-24/+20
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4741 Update Md5/Sha1/Sha2 by using mbedtls 3.0 api in BaseCryptLibMbedTls, because the old API may be deprecated when open some MACRO. Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Yi Li <yi1.li@intel.com> Signed-off-by: Wenxing Hou <wenxing.hou@intel.com> Reviewed-by: Yi Li <yi1.li@intel.com>
* CryptoPkg: Update OPTIONAL location for BaseCryptLibMbedTlsHou, Wenxing2024-04-012-8/+4
| | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4740 There is a wrong usage for OPTIONAL. Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Yi Li <yi1.li@intel.com> Signed-off-by: Wenxing Hou <wenxing.hou@intel.com> Reviewed-by: Yi Li <yi1.li@intel.com>
* MdeModulePkg: MemoryProtection: Use ImageRecordPropertiesLibOliver Smith-Denny2024-03-291-213/+28
| | | | | | | | | | | | | | | | | The functionality to create and delete Image Records has been consolidated in a library and ensured that MemoryProtection.c's usage is encapsulated there. This patch moves MemoryProtection.c to reuse the code in the lib and to prevent issues in the future where code is updated in one place but not the other. Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Taylor Beebe <taylor.d.beebe@gmail.com> Acked-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
* MdeModulePkg: ImagePropertiesRecordLib: Consolidate UsageOliver Smith-Denny2024-03-291-19/+63
| | | | | | | | | | | | | | | Currently, there are multiple instances of code create image records. ImagePropertiesRecordLib was created to only have this code in one place. Update the lib to use additional logic from the copy in MemoryProtection.c before converging that code to use the lib. Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Taylor Beebe <taylor.d.beebe@gmail.com> Acked-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
* MdeModulePkg: ImagePropertiesRecordLib: Use SectionAlignment for CodeSizeOliver Smith-Denny2024-03-291-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an ImageRecord is stored by ImagePropertiesRecordLib, it reports the CodeSegmentSize as the SizeOfRawData from the image. However, the image as loaded into memory is aligned to the SectionAlignment, so SizeOfRawData is under the actual size in memory. This is important, because the memory attributes table uses these image records to create its entries and it will report that the alignment of an image is incorrect, even though the actual image is correct. This was discovered on ARM64, which has a 64k runtime page granularity alignment, which is backed by a 64k section alignment for DXE_RUNTIME_DRIVERs. The runtime code and data was correctly being loaded into memory, however the memory attribute table was incorrectly reporting misaligned ranges to the OS, causing attributes to be ignored for these sections for OSes using greater than 4k pages. This patch correctly aligns the CodeSegmentSize to the SectionAlignment and the corresponding memory attribute table entries are now correctly aligned and pointing to the right places in memory. Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Taylor Beebe <taylor.d.beebe@gmail.com> Acked-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Marvin H?user <mhaeuser@posteo.de> Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
* MdePkg: Add gEfiDeviceSignatureDatabaseGuid to decWenxing Hou2024-03-291-1/+7
| | | | | | | | | | | | | According to UEFI 2.10 spec 32.8.2 UEFI Device Signature Variable GUID and Variable Name section, add gEfiDeviceSignatureDatabaseGuid to dec. Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Wenxing Hou <wenxing.hou@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdePkg: Add UEFI 2.10 DeviceAuthenticationWenxing Hou2024-03-291-0/+61
| | | | | | | | | | | | | According to UEFI 2.10 spec 32.8.2 UEFI Device Signature Variable GUID and Variable Name section, add signature database for device authentication. Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Wenxing Hou <wenxing.hou@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* ShellPkg/Acpiview: Adds ACPI WSMT Table parseAbdul Lateef Attar2024-03-254-0/+166
| | | | | | | | | | Adds WSMT parse to the UefiShellAcpiViewCommandLib library. Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Pierre Gondois <pierre.gondois@arm.com> Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
* ShellPkg/Acpiview: Adds HPET parserAbdul Lateef Attar2024-03-254-0/+241
| | | | | | | | | | Adds HPET parse to the UefiShellAcpiViewCommandLib library. Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Pierre Gondois <pierre.gondois@arm.com> Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
* MdeModulePkg/Xhci: Skip another size round up for TRB addressDat Mach2024-03-222-2/+2
| | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4560 Commit f36e1ec1f0a5fd3be84913e09181d7813444b620 had fixed the DXE_ASSERT caused by the TRB size round up from 16 to 64 for most cases. However, there is a remaining case that the TRB size is also rounded up during setting TR dequeue pointer that would trigger DXE_ASSERT. This patch sets the alignment flag to FALSE in XhcSetTrDequeuePointer to fix this issue as well. Cc: Gao Cheng <gao.cheng@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Dat Mach <dmach@nvidia.com> Reviewed-by: Gao Cheng <gao.cheng@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* OvmfPkg/TdxDxe: Clear the registers before tdcallCeping Sun2024-03-191-4/+26
| | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4696 Refer to the [GHCI] spec, TDVF should clear the BIT5 for RBP in the mask. And TDVF should clear the regitsers to avoid leaking secrets to VMM. Reference: [GHCI]: TDX Guest-Host-Communication Interface v1.5 https://cdrdv2.intel.com/v1/dl/getContent/726792 Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Isaku Yamahata <isaku.yamahata@intel.com> Signed-off-by: Ceping Sun <cepingx.sun@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/CcExitLib: Update TDVMCALL_EXPOSE_REGS_MASKCeping Sun2024-03-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4696 Refer to the [GHCI] spec, TDVF should clear the BIT5 for RBP in the mask. Reference: [GHCI]: TDX Guest-Host-Communication Interface v1.5 https://cdrdv2.intel.com/v1/dl/getContent/726792 Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Isaku Yamahata <isaku.yamahata@intel.com> Signed-off-by: Ceping Sun <cepingx.sun@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Min Xu <min.m.xu@intel.com>
* MdePkg/BaseLib: Update TDVMCALL_EXPOSE_REGS_MASKCeping Sun2024-03-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4696 Refer to the [GHCI] spec, TDVF should clear the BIT5 for RBP in the mask. Reference: [GHCI]: TDX Guest-Host-Communication Interface v1.5 https://cdrdv2.intel.com/v1/dl/getContent/726792 Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Isaku Yamahata <isaku.yamahata@intel.com> Signed-off-by: Ceping Sun <cepingx.sun@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* IntelFsp2WrapperPkg: Error handling of FspmWrapperInit()Du Lin2024-03-151-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4701 The error handling of FspmWrapperInit() is limited to ASSERT statements only, which only works in debug builds, but not in release builds. Fix the issue by enhancing the error handling of FspmWrapperInit() to cover both debug builds and release builds. Cc: Ashraf Ali S <ashraf.ali.s@intel.com> Cc: Chasel Chiu <chasel.chiu@intel.com> Cc: Chen Gang C <gang.c.chen@intel.com> Cc: Duggapu Chinni B <chinni.b.duggapu@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Susovan Mohapatra <susovan.mohapatra@intel.com> Cc: Ted Kuo <ted.kuo@intel.com> Signed-off-by: Du Lin <du.lin@intel.com> Reviewed-by: Ashraf Ali S <ashraf.ali.s@intel.com> Reviewed-by: Chen Gang C <gang.c.chen@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* IntelFsp2WrapperPkg: Error handling of TpmMeasureAndLogDataWithFlags()Du Lin2024-03-151-0/+4
| | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4700 TpmMeasureAndLogDataWithFlags() computes the measure the code and log it into PCR 0. TpmMeasureAndLogData() computes the hash for the configuration. The same "Status" variable is used to store the return values for both of the functions. There is no error handling if TpmMeasureAndLogDataWithFlags() returns an error Status. Fix the issue by adding error handling for TpmMeasureAndLogDataWithFlags(). Cc: Ashraf Ali S <ashraf.ali.s@intel.com> Cc: Chasel Chiu <chasel.chiu@intel.com> Cc: Chen Gang C <gang.c.chen@intel.com> Cc: Duggapu Chinni B <chinni.b.duggapu@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Susovan Mohapatra <susovan.mohapatra@intel.com> Cc: Ted Kuo <ted.kuo@intel.com> Signed-off-by: Du Lin <du.lin@intel.com> Reviewed-by: Ashraf Ali S <ashraf.ali.s@intel.com> Reviewed-by: Chen Gang C <gang.c.chen@intel.com>
* MdeModulePkg: DxeCore: Do Not Apply Guards to Unsupported TypesOliver Smith-Denny2024-03-144-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, there are multiple issues when page or pool guards are allocated for runtime memory regions that are aligned to non-EFI_PAGE_SIZE alignments. Multiple other issues have been fixed for these same systems (notably ARM64 which has a 64k runtime page allocation granularity) recently. The heap guard system is only built to support 4k guard pages and 4k alignment. Today, the address returned to a caller of AllocatePages will not be aligned correctly to the runtime page allocation granularity, because the heap guard system does not take non-4k alignment requirements into consideration. However, even with this bug fixed, the Memory Allocation Table cannot be produced and an OS with a larger than 4k page granularity will not have aligned memory regions because the guard pages are reported as part of the same memory allocation. So what would have been, on an ARM64 system, a 64k runtime memory allocation is actually a 72k memory allocation as tracked by the Page.c code because the guard pages are tracked as part of the same allocation. This is a core function of the current heap guard architecture. This could also be fixed with rearchitecting the heap guard system to respect alignment requirements and shift the guard pages inside of the outer rounded allocation or by having guard pages be the runtime granularity. Both of these approaches have issues. In the former case, we break UEFI spec 2.10 section 2.3.6 for AARCH64, which states that each 64k page for runtime memory regions may not have mixed memory attributes, which pushing the guard pages inside would create. In the latter case, an immense amount of memory is wasted to support such large guard pages, and with pool guard many systems could not support an additional 128k allocation for all runtime memory. The simpler and safer solution is to disallow page and pool guards for runtime memory allocations for systems that have a runtime granularity greater than the EFI_PAGE_SIZE (4k). The usefulness of such guards is limited, as OSes do not map guard pages today, so there is only boot time protection of these ranges. This also prevents other bugs from being exposed by using guards for regions that have a non-4k alignment requirement, as again, multiple have cropped up because the heap guard system was not built to support it. This patch adds both a static assert to ensure that either the runtime granularity is the EFI_PAGE_SIZE or that the PCD bits are not set to enable heap guard for runtime memory regions. It also adds a check in the page and pool allocation system to ensure that at runtime we are not allocating a runtime region and attempt to guard it (the PCDs are close to being removed in favor of dynamic heap guard configurations). BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4674 Github PR: https://github.com/tianocore/edk2/pull/5382 Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: DxeCore: Correct Runtime Granularity Memory TypeOliver Smith-Denny2024-03-144-7/+7
| | | | | | | | | | | | | | | | | | | Per the UEFI spec 2.10, section 2.3.6 (for the AARCH64 arch, other architectures in section two confirm the same) the memory types that need runtime page allocation granularity are EfiReservedMemoryType, EfiACPIMemoryNVS, EfiRuntimeServicesCode, and EfiRuntimeServicesData. However, legacy code was setting runtime page allocation granularity for EfiACPIReclaimMemory and not EfiReservedMemoryType. This patch fixes that error. Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com> Suggested-by: Ard Biesheuvel <ardb+tianocore@kernel.org> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: DxeCore: Fix CodeQL Error in FreePagesOliver Smith-Denny2024-03-141-1/+6
| | | | | | | | | | CodeQL flags the Free Pages logic for not ensuring that Entry is non-null before using it. Add a check for this and appropriately bail out if we hit this case. Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Remove ArmPkg DependencyOliver Smith-Denny2024-03-142-4/+1
| | | | | | | | | | | | | | | | | | | | | With commita21a994f55e53325d3e060c435ca3a87fd7c2c79 MdeModulePkg no longer has a hard dependency on ArmMmuLib and therefore ArmLib. This is the final dependency on ArmPkg, so remove the unused libs and drop the allowed dependency on ArmPkg as MdeModulePkg should not depend on it as this is a circular dependency. Github PR: https://github.com/tianocore/edk2/pull/5361 BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3651 Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com> Reviewed-by: Sean Brogan <sean.brogan@microsoft.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* BaseTools/GenFds: Apply OEM_CAPSULE_FLAGS during Capsule generation.Igniculus Fu2024-03-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Bugzilla ticket 4633 FdfParser.py has defined a key named OEM_CAPSULE_FLAGS to set the lower 16 bits of EFI_CAPSULE_HEADER.Flags. However, this key is totally "forgotten" in Capsule.py, making it impossible to set lower 16 bits of this field, and leading to an always FALSE when comparing to gEfiMdeModulePkgTokenSpaceGuid.PcdSystemRebootAfterCapsuleProcessFlag in MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleProcessLib.c: ProcessTheseCapsules(). This patch ORs the value of OEM_CAPSULE_FLAGS with previously calculated CAPSULE_FLAGS value, making the lower 16 bits of value being correctly set. Signed-off-by: Igniculus Fu <igniculus.fu@amd.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Cc: Abner Chang <abner.chang@amd.com> Cc: Eric Xing <eric.xing@amd.com> Cc: Abdul Lateef Attar <abdattar@amd.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* DynamicTablesPkg/SSDT: Require Package node in hierarchyJeshua Smith2024-03-131-10/+22
| | | | | | | | | | | | | The code was incorrectly assuming that root nodes had to be physical package nodes and vice versa. This is not always true, so update the check to simply require exactly one package node somewhere in the hierarchy. Cc: Pierre Gondois <pierre.gondois@arm.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Jeshua Smith <jeshuas@nvidia.com> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
* SecurityPkg: Update ReceiveData and SendData function descriptionQingyu Shang2024-03-131-2/+6
| | | | | | | | | | Refer to UEFI Spec 2.10 section 13.14, update the parameter 'MediaId' description for EFI_STORAGE_SECURITY_COMMAND_PROTOCOL function ReceiveData and SendData. Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Qingyu Shang <qingyu.shang@intel.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
* MdeModulePkg: Update ReceiveData and SendData function descriptionQingyu Shang2024-03-138-18/+54
| | | | | | | | | | | | AtaBusDxe, NvmExpressDxe, ScsiDiskDxe and EmmcDxe is used to back the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL, update the parameter 'MediaId' description for the protocol function ReceiveData and SendData as described in UEFI Spec 2.10 section 13.14. Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Qingyu Shang <qingyu.shang@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdePkg: Update ReceiveData and SendData function descriptionQingyu Shang2024-03-131-2/+6
| | | | | | | | | | | | Refer to UEFI Spec 2.10 section 13.14, update the parameter 'MediaId' description for EFI_STORAGE_SECURITY_COMMAND_PROTOCOL function ReceiveData and SendData. Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Signed-off-by: Qingyu Shang <qingyu.shang@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* EmbeddedPkg/NonCoherentIoMmuDxe: Make SetAttributes always succeedArd Biesheuvel2024-03-121-1/+1
| | | | | | | | | | | | | | NonCoherentIoMmuSetAttribute() does nothing except return EFI_UNSUPPORTED. This was fine when it was introduced, but now, the PCI bus driver will fail a PCI I/O Map() operation if the call to SetAttributes() fails. So return EFI_SUCCESS instead. Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Abner Chang <abner.chang@amd.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
* Maintainers.txt: remove Laszlo's entriesLaszlo Ersek2024-03-081-3/+0
| | | | | | | | | | | | | | | | | | Red Hat and I have mutually and amicably agreed to separate. Remove my entries from "Maintainers.txt". Cc: Andrew Fish <afish@apple.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20240306210552.19524-1-lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* UefiPayloadPkg: auto-generate SEC ProcessLibraryConstructorList() declLaszlo Ersek2024-03-084-13/+3
| | | | | | | | | | | | | | | | | | | | | | | Rely on AutoGen for declaring ProcessLibraryConstructorList(). Build-tested with: python UefiPayloadPkg/UniversalPayloadBuild.py -a X64 -b DEBUG -t GCC5 python UefiPayloadPkg/UniversalPayloadBuild.py -a X64 -b DEBUG -f \ -t GCC5 build -a X64 -b DEBUG -p UefiPayloadPkg/UefiPayloadPkg.dsc -t GCC5 \ -D BUILD_ARCH=X64 Cc: Gua Guo <gua.guo@intel.com> Cc: Guo Dong <guo.dong@intel.com> Cc: James Lu <james.lu@intel.com> Cc: Sean Rhodes <sean@starlabs.systems> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=990 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20240305113843.68812-11-lersek@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* UefiCpuPkg: auto-generate SEC ProcessLibraryConstructorList() declLaszlo Ersek2024-03-083-14/+2
| | | | | | | | | | | | | | | | | | | | | Rely on AutoGen for declaring ProcessLibraryConstructorList(). Build-tested with: build -a X64 -b DEBUG -m UefiCpuPkg/SecCore/SecCore.inf \ -p UefiCpuPkg/UefiCpuPkg.dsc -t GCC5 build -a X64 -b DEBUG -m UefiCpuPkg/SecCore/SecCoreNative.inf \ -p UefiCpuPkg/UefiCpuPkg.dsc -t GCC5 Cc: Catharine West <catharine.west@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Ray Ni <ray.ni@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=990 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20240305113843.68812-10-lersek@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* IntelFsp2Pkg: auto-generate SEC ProcessLibraryConstructorList() declLaszlo Ersek2024-03-083-14/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Rely on AutoGen for declaring ProcessLibraryConstructorList(). Build-tested with: build -a X64 -b DEBUG -m IntelFsp2Pkg/FspSecCore/Fsp24SecCoreM.inf \ -p IntelFsp2Pkg/IntelFsp2Pkg.dsc -t GCC5 build -a X64 -b DEBUG -m IntelFsp2Pkg/FspSecCore/FspSecCoreM.inf \ -p IntelFsp2Pkg/IntelFsp2Pkg.dsc -t GCC5 Cc: Ashraf Ali S <ashraf.ali.s@intel.com> Cc: Chasel Chiu <chasel.chiu@intel.com> Cc: Duggapu Chinni B <chinni.b.duggapu@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Susovan Mohapatra <susovan.mohapatra@intel.com> Cc: Ted Kuo <ted.kuo@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=990 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20240305113843.68812-9-lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* EmulatorPkg: auto-generate SEC ProcessLibraryConstructorList() declLaszlo Ersek2024-03-082-10/+1
| | | | | | | | | | | | | | | | | Rely on AutoGen for declaring ProcessLibraryConstructorList(). Build-tested with: build -a X64 -b DEBUG -m EmulatorPkg/Sec/Sec.inf \ -p EmulatorPkg/EmulatorPkg.dsc -t GCC5 Cc: Andrew Fish <afish@apple.com> Cc: Ray Ni <ray.ni@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=990 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20240305113843.68812-8-lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* ArmVirtPkg: auto-generate SEC ProcessLibraryConstructorList() declLaszlo Ersek2024-03-082-7/+1
| | | | | | | | | | | | | | | | | | | | Rely on AutoGen for declaring ProcessLibraryConstructorList(). Build-tested with: build -a AARCH64 -b DEBUG \ -m ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf \ -p ArmVirtPkg/ArmVirtKvmTool.dsc -t GCC5 Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=990 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20240305113843.68812-7-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* ArmPlatformPkg: auto-generate SEC ProcessLibraryConstructorList() declLaszlo Ersek2024-03-086-20/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rely on AutoGen for declaring ProcessLibraryConstructorList(). Build-tested with: build -a AARCH64 -b DEBUG \ -m ArmPlatformPkg/PrePeiCore/PrePeiCoreMPCore.inf \ -p ArmPlatformPkg/ArmPlatformPkg.dsc -t GCC5 build -a AARCH64 -b DEBUG \ -m ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf \ -p ArmPlatformPkg/ArmPlatformPkg.dsc -t GCC5 build -a AARCH64 -b DEBUG \ -m ArmPlatformPkg/PrePi/PeiMPCore.inf \ -p ArmPlatformPkg/ArmPlatformPkg.dsc -t GCC5 build -a AARCH64 -b DEBUG \ -m ArmPlatformPkg/PrePi/PeiUniCore.inf \ -p ArmPlatformPkg/ArmPlatformPkg.dsc -t GCC5 Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Leif Lindholm <quic_llindhol@quicinc.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=990 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20240305113843.68812-6-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/RiscVVirt/Sec: clean up ProcessLibraryConstructorList() declLaszlo Ersek2024-03-083-14/+1
| | | | | | | | | | | | | | | | | | | | | | | | <Library/PeimEntryPoint.h> declares a bogus ProcessLibraryConstructorList() for the OvmfPkg/RiscVVirt SEC module. Rely on AutoGen for (properly) declaring ProcessLibraryConstructorList(). Remove the correct, but superfluous, declaration as well. Build-tested with: build -a RISCV64 -b DEBUG -m OvmfPkg/RiscVVirt/Sec/SecMain.inf \ -p OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc -t GCC5 Cc: Andrei Warkentin <andrei.warkentin@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Sunil V L <sunilvl@ventanamicro.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=990 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20240305113843.68812-5-lersek@redhat.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/IntelTdx: auto-gen & fix SEC ProcessLibraryConstructorList() declLaszlo Ersek2024-03-082-3/+2
| | | | | | | | | | | | | | | | | | | | <Library/PeimEntryPoint.h> declares a bogus ProcessLibraryConstructorList() for IntelTdx's SEC module. Rely on AutoGen for (properly) declaring ProcessLibraryConstructorList(). Update the call. Build-tested with: build -a X64 -b DEBUG -m OvmfPkg/IntelTdx/Sec/SecMain.inf \ -p OvmfPkg/IntelTdx/IntelTdxX64.dsc -t GCC5 Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=990 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20240305113843.68812-4-lersek@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: auto-generate (and fix) SEC ProcessLibraryConstructorList() declLaszlo Ersek2024-03-082-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | <Library/PeimEntryPoint.h> declares a bogus ProcessLibraryConstructorList() for OVMF's SEC module. Rely on AutoGen for (properly) declaring ProcessLibraryConstructorList(). Update the call. Build-tested with: build -a X64 -b DEBUG -m OvmfPkg/Sec/SecMain.inf \ -p OvmfPkg/OvmfPkgX64.dsc -t GCC5 Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=990 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4643 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20240305113843.68812-3-lersek@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* pip-requirements.txt: require edk2-basetools version 0.1.51Laszlo Ersek2024-03-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The edk2-basetools commit that corresponds to edk2 commit bac9c74080cf ("BaseTools/AutoGen: declare ProcessLibraryConstructorList() for SEC modules", 2024-02-29) is 5b7161de22ee ("BaseTools/AutoGen: declare ProcessLibraryConstructorList() for SEC modules", 2024-03-04); it is part of tag v0.1.51. Subsequent patches in this series put that feature to use. Require release 0.1.51 of edk2-basetools in "pip-requirements.txt", so that the next patches work with in-tree and out-of-tree (e.g., CI) BaseTools. Furthermore, require version 0.20.0 of edk2-pytool-library. This is a dependency of edk2-basetools v0.1.50 (commit 08e5bbe755d2, "Add pyproject.toml and fix setup.py deprecation warnings", 2024-02-13) and v0.1.51 too (commit f3e15d654479, "Add pyproject.toml and fix setup.py deprecation warnings", 2024-02-16). Cc: Bob Feng <bob.c.feng@intel.com> Cc: Joey Vagedes <joey.vagedes@gmail.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Yuwei Chen <yuwei.chen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=991 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20240305113843.68812-2-lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* UefiPayloadPkg: Make Dsc accomodative of other archsDhaval2024-03-061-21/+27
| | | | | | | | | | | | | Current DSC files contains a lot of files which are specific to X86 arch. Need to move around files under arch specific sections. Cc: Guo Dong <guo.dong@intel.com> Cc: Sean Rhodes <sean@starlabs.systems> Cc: James Lu <james.lu@intel.com> Cc: Gua Guo <gua.guo@intel.com> Signed-off-by: Dhaval Sharma <dhaval@rivosinc.com> Reviewed-by: Gua Guo <gua.guo@intel.com>
* OvmfPkg/SmbiosPlatformDxe: tweak fallback release date againLee, Chun-Yi2024-03-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case PcdFirmwareReleaseDateString is not set use a valid date as fallback. But the default valid date can _NOT_ pass the Microsoft SVVP test "Check SMBIOS Table Specific Requirements". The test emitted the error message: BIOS Release Date string is unexpected length: 8. This string must be in MM/DD/YYYY format. No other format is allowed and no additional information may be included. See field description in the SMBIOS specification. Base on SMBIOS spec v3.7.0: 08h 2.0+ BIOS Release Date BYTE STRING String number of the BIOS release date. The date string, if supplied, is in either mm/dd/yy or mm/dd/yyyy format. If the year portion of the string is two digits, the year is assumed to be 19yy. NOTE: The mm/dd/yyyy format is required for SMBIOS version 2.3 and later. So, let's tweek the fallback release date again. Fixes: a0f9628705e3 ("OvmfPkg/SmbiosPlatformDxe: tweak fallback release date") [edk2-stable202305~327] Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com> Message-Id: <20240204092914.29813-1-jlee@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Pawel Polawski <ppolawsk@redhat.com> Cc: Oliver Steffen <osteffen@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Ruifeng Gao <ruifeng.gao@intel.com> Cc: "Lee, Chun-Yi" <jlee@suse.com> [lersek@redhat.com: Turn the CC's from the list posting to commit message body tags, for placating "PatchCheck.py". Also work the "ruifeng.gao@intel.com" email address into a format that "PatchCheck.py" accepts.]
* .github/workflows/codeql.yml: Update actions being deprecatedMichael Kubacki2024-03-041-13/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently CodeQL runs have the following warnings: Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/setup-python@v4, actions/upload-artifact@v3, actions/cache@v3. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/. And: CodeQL Action v2 will be deprecated on December 5th, 2024. Please update all occurrences of the CodeQL Action in your workflow files to v3. For more information, see: https://github.blog/changelog/2024-01-12-code-scanning-deprecation-of-codeql-action-v2/ The first is resolved by updating the actions to the latest versions that were released to use Node.js 20. The second is specifically referring to the codeql-action/upload-sarif action which is at v2. This change updates all of the actions to the latest releases to prevent deprecated versions from continuing to be used. --- The following breaking change was noted in actions/upload-artifact that caused some related changes in the workflow: "Due to how Artifacts are created in this new version, it is no longer possible to upload to the same named Artifact multiple times. You must either split the uploads into multiple Artifacts with different names, or only upload once. Otherwise you will encounter an error." This workflow depended on that behavior previously to append multiple logs (e.g. setup log, update log, build log) to the same named artifact (named per package). These were appended after each operation so they are readily available if the operation failed and no further actions are run. Now the artifacts must be unique in name. The hyphenation comes in because edk2 further builds some packages with both architectures in a single build vs separate builds (e.g. IA32 and X64 vs IA32,X64). To uniquely name artifacts resulting from those builds, the architecture is also placed in the artifact name. For builds with multiple architectures the artifact name captures each architecture separated by a hyphen. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Joey Vagedes <joey.vagedes@gmail.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools/GenFds: Resolve absolute workspace INF pathsMichael Kubacki2024-03-041-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, if an INF path is an absolute path on Linux (begins with "/"), the "/" character will be removed. If the path is an absolute system path, this creates an invalid path. An example of when this may be an issue is in external dependencies where an INF is within the external dependency, the `set_build_var` flag is set, and DSC files refer to files by its build variable (e.g. `$(SHARED_BINARIES)/Module.inf`). INFs in a binary distribution like this example may contain a [Binaries] section and refer to different section files that can be used by a platform to compose an FFS file. For example, the PE32 (.efi) and DEPEX (.depex) files. In this case, `$(SHARED_BINARIES)` will be an absolute path to the ext dep directory and `FfsInfStatement.__InfParse__` will remove the leading "/" character so the path is invalid. This change first checks if the absolute path will resolve into the current workspace. If it does (as will happen in the shared crypto ext dep example above), it modifies the path to be relative to the workspace so later logic dependent on relative paths can operate on it. If the absolute path is not within the current workspace, it follows previous behavior for backward compatibility to that scenario. Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* DynamicTablesPkg/SsdtSerialPortFixupLib: Add Interrupt node for SPIs onlyHimanshu Sharma2024-03-044-30/+69
| | | | | | | | | | | | | | | | | | Add interrupt node to the AML description of the serial-port only if the IRQ ID from the Configuration Manager is a valid SPI (shared processor interrupt) or an extended SPI. So, for DBG2 UART ports where interrupt is not mandatory, adding of an interrupt node in the AML description using Serial Port Fixup Library can be ignored if the UART is not defined with a valid SPI, like in N1SDP. This update generates the interrupt node for the valid SPI range using the AML Codegen API instead of updating it using the AML Fixup API. Cc: Sami Mujawar <Sami.Mujawar@arm.com> Cc: Pierre Gondois <pierre.gondois@arm.com> Signed-off-by: Himanshu Sharma <Himanshu.Sharma@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
* ArmPkg/ArmGicArchLib: Add macros for SPI and extended SPI rangesHimanshu Sharma2024-03-041-0/+14
| | | | | | | | | | | | | | | Taking reference from Table 2-1 of the Arm Generic Interrupt Controller Architecture Specification, Issue H, January 2022, add macros for the SPI and extended SPI ranges with the purpose of reusability on including the ArmPkg. Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Himanshu Sharma <Himanshu.Sharma@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* UefiPayloadPkg: UPL arch backward support ELFGua Guo2024-03-041-1/+1
| | | | | | | | | | | After 11ad164bcea6b0ed3628d merge, ELF format API won't meet backward requirement. Cc: Guo Dong <guo.dong@intel.com> Cc: Sean Rhodes <sean@starlabs.systems> Reviewed-by: James Lu <james.lu@intel.com> Cc: Gua Guo <gua.guo@intel.com> Signed-off-by: Gua Guo <gua.guo@intel.com>
* ShellPkg/SmbiosView: Support New ProcessorFamily for SMBIOS Type4Jason Lou2024-03-041-1/+33
| | | | | | | | | | | | The patch updates SmbiosView to support new ProcessorFamily for SMBIOS Type4 based on SMBIOS 3.8.0. Signed-off-by: Jason Lou <yun.lou@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhichao Gao <zhichao.gao@intel.com>
* MdePkg/SmBios.h: Add New ProcessorFamily definitions for SMBIOS Type4Jason Lou2024-03-041-3/+11
| | | | | | | | | | | | | | | | | | The patch adds new ProcessorFamily definitions for SMBIOS Type4 based on SMBIOS 3.8.0. Signed-off-by: Jason Lou <yun.lou@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Benny Lin <benny.lin@intel.com> Cc: Gua Guo <gua.guo@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn>
* OvmfPkg/ResetVector: wire up 5-level paging for TDXGerd Hoffmann2024-03-012-1/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | BSP workflow is quite simliar to the non-coco case. TDX_WORK_AREA_PGTBL_READY is used to record the paging mode: 1 == 4-level paging 2 == 5-level paging APs will look at TDX_WORK_AREA_PGTBL_READY to figure whenever they should enable 5-level paging or not. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20240301074402.98625-9-kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: move "CheckForSev:" label into "%if PG_5_LEVEL" scope, as discussed with Gerd] Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Oliver Steffen <osteffen@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Tom Lendacky <thomas.lendacky@amd.com> [lersek@redhat.com: turn the "Cc:" message headers from Gerd's on-list posting into "Cc:" tags in the commit message, in order to pacify "PatchCheck.py"]
* OvmfPkg/ResetVector: print post codes for 4/5 level pagingGerd Hoffmann2024-03-011-0/+8
| | | | | | | | | | | | | | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20240301074402.98625-8-kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Oliver Steffen <osteffen@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Tom Lendacky <thomas.lendacky@amd.com> [lersek@redhat.com: turn the "Cc:" message headers from Gerd's on-list posting into "Cc:" tags in the commit message, in order to pacify "PatchCheck.py"]
* OvmfPkg/ResetVector: add 5-level paging supportGerd Hoffmann2024-03-013-0/+102
| | | | | | | | | | | | | | | | | | | Add macros to check for 5-level paging and gigabyte page support. Enable 5-level paging for the non-confidential-computing case. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20240301074402.98625-7-kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Oliver Steffen <osteffen@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Tom Lendacky <thomas.lendacky@amd.com> [lersek@redhat.com: turn the "Cc:" message headers from Gerd's on-list posting into "Cc:" tags in the commit message, in order to pacify "PatchCheck.py"]
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-21 15:28:13 +0000