summaryrefslogtreecommitdiffstats
path: root/MdeModulePkg
Commit message (Collapse)AuthorAgeFilesLines
* MdeModulePkg/Variable: Add TCG SPDM device measurement updateWenxing Hou4 days4-6/+43
| | | | | | | | | Add EV_EFI_SPDM_DEVICE_POLICY support for MeasureVariable. Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Wenxing Hou <wenxing.hou@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* MdeModulePkg: Add SPI NOR FLash SFDP drivers to DSCabnchang13 days1-1/+3
| | | | | | | | | | | | | BZ#: 4471 SPI NOR Flash JEDEC Serial Flash Discoverable Driver implementation. Signed-off-by: Abner Chang <abner.chang@amd.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Abdul Lateef Attar <abdattar@amd.com> Cc: Brit Chesley <brit.chesley@amd.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/SpiNorFlashJedecSfdp: SPI NOR Flash JEDEC SFDPabnchang13 days11-0/+4166
| | | | | | | | | | | | | BZ#: 4471 SPI NOR Flash JEDEC Serial Flash Discoverable Driver implementation. Signed-off-by: Abner Chang <abner.chang@amd.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Abdul Lateef Attar <abdattar@amd.com> Cc: Brit Chesley <brit.chesley@amd.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Add definitions in DEC for SPI NOR Flash SFDP driverAbner Chang13 days1-1/+27
| | | | | | | | | | | BZ#: 4473 Signed-off-by: Abner Chang <abner.chang@amd.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Abdul Lateef Attar <abdattar@amd.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Abdul Lateef Attar <abdattar@amd.com>
* MdeModulePkg/SMM: Support to unregister SMI handler in SMI handlersZhiguang Liu2024-04-162-26/+139
| | | | | | | | | | | | | | | | | | | | This patch fix a use-after-free issue where unregistering an SMI handler could lead to the deletion of the SMI_HANDLER while it is still in use by SmiManage(). The fix involves modifying SmiHandlerUnRegister() to detect whether it is being called from within the SmiManage() stack. If so, the removal of the SMI_HANDLER is deferred until SmiManage() has finished executing. Additionally, due to the possibility of recursive SmiManage() calls, the unregistration and subsequent removal of the SMI_HANDLER are ensured to occur only after the outermost SmiManage() invocation has completed. Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* Revert ae1079b386a597108a8070652bf7cdaa4ec3dda3Zhiguang Liu2024-04-161-7/+1
| | | | | | | | | | | | | | | This reverts "MdeModulePkg/SMM: Support to unregister SMI handler inside SMI handler" for better design later. Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* Revert 17b28722008eab745ce186b72cd325944cbe6bf0Zhiguang Liu2024-04-161-21/+8
| | | | | | | | | | | | | | | This reverts commit "MdeModulePkg/SMM: Disallow unregister SMI handler in other SMI handler" for better design later. Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* MdeModulePkg/AcpiTableDxe: Prefer xDSDT over DSDT when installing tablesDhaval2024-04-111-7/+17
| | | | | | | | | | | | | | | | | As per ACPI Spec 6.5+ Table 5-9 if xDSDT is available, it should be used first. Handle required flow when xDSDT is absent or present. Test: Tested on RISCV64 Qemu platform with xDSDT and booted to linux kernel. Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Pedro Falcato <pedro.falcato@gmail.com> Signed-off-by: Dhaval Sharma <dhaval@rivosinc.com> Acked-by: Chasel Chiu <chasel.chiu@...> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/AcpiTableDxe: PCD switch to avoid using ACPI reclaim memoryAaron Li2024-04-094-8/+45
| | | | | | | | | | | | | | | | | | | | | | UEFI spec defined ACPI Tables at boot time can be contained in memory of type EfiACPIReclaimMemory or EfiAcpiMemoryNVS, although InstallAcpiTable with AcpiTableProtocol will only allocate memory with type EfiACPIReclaimMemory (Except FACS). This patch provides an optional method controlled by PCD to avoid using EfiACPIReclaimMemory, by setting the PCD PcdNoACPIReclaimMemory to TRUE, all ACPI allocated memory will use EfiAcpiMemoryNVS instead. Cc: Zhiguang Liu <zhiguang.liu@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Liu Yun <yun.y.liu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Aaron Li <aaron.li@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
* MdeModulePkg: Update the comments of ReadKeyStroke and ReadKeyStrokeExQingyu2024-04-038-1/+30
| | | | | | | | | | | Refer to Uefi spec 2.10 section 12.3.3, Add a new retval EFI_UNSUPPORTED to EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL.ReadKeyStrokeEx and EFI_SIMPLE_TEXT_INPUT_PROTOCOL.ReadKeyStroke(). Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Qingyu <qingyu.shang@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* 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>
* 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>
* 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>
* 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>
* MdeModulePkg/Core/Pei: Improve the copy performanceLi, Zhihao2024-03-011-2/+2
| | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4697 EvacuateTempRam function will copy the temporary memory context to the rebased pages and the raw pages. Migrations of rebased PEIMs is from cache to memory, while raw PEIMs is from memory to memory. So the migrations of raw PEIMs is slower than rebased PEIMs. Experimental data indicates that changing the source address of raw PEIMs migration will improve performance by 35%. Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Zhihao Li <zhihao.li@intel.com> Message-Id: <20240301071147.519-1-zhihao.li@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
* MdeModulePkg/SMM: Disallow unregister SMI handler in other SMI handlerZhiguang Liu2024-03-011-8/+21
| | | | | | | | | | | | | | | | In last patch, we add code support to unregister SMI handler inside itself. However, the code doesn't support unregister SMI handler insider other SMI handler. While this is not a must-have usage. So add check to disallow unregister SMI handler in other SMI handler. Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com> Message-Id: <20240301030133.628-3-zhiguang.liu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* MdeModulePkg/SMM: Support to unregister SMI handler inside SMI handlerZhiguang Liu2024-03-011-1/+7
| | | | | | | | | | | | | | To support unregister SMI handler inside SMI handler itself, get next node before SMI handler is executed, since LIST_ENTRY that Link points to may be freed if unregister SMI handler in SMI handler itself. Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com> Message-Id: <20240301030133.628-2-zhiguang.liu@intel.com>
* MdeModulePkg/DxeIplPeim: rename variableGerd Hoffmann2024-02-291-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Rename Page5LevelSupported to Page5LevelEnabled. The variable is set to true in case 5-paging level is enabled (64-bit PEI) or will be enabled (32-bit PEI), it does *not* tell whenever the 5-level paging is supported by the CPU. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Message-Id: <20240222105407.75735-3-kraxel@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Oliver Steffen <osteffen@redhat.com> Cc: Ard Biesheuvel <ardb@kernel.org> [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"]
* MdeModulePkg/DxeIplPeim: fix PcdUse5LevelPageTable assertGerd Hoffmann2024-02-291-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PcdUse5LevelPageTable documentation says: Indicates if 5-Level Paging will be enabled in long mode. 5-Level Paging will not be enabled when the PCD is TRUE but CPU doesn't support 5-Level Paging. So running in 4-level paging mode with PcdUse5LevelPageTable=TRUE is possible. The only invalid combination is 5-level paging being active with PcdUse5LevelPageTable=FALSE. Fix the ASSERT accordingly. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Message-Id: <20240222105407.75735-2-kraxel@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Oliver Steffen <osteffen@redhat.com> Cc: Ard Biesheuvel <ardb@kernel.org> [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"]
* MdeModulePkg/TraceHubDebugSysTLib: Use wider type for loop comparisonsMichael Kubacki2024-02-263-4/+4
| | | | | | | | | | | | | | | | | | | | | | Resolves a new CodeQL error due to the value being incremented in the loop being a narrower type than the variable it is being compared against. The variable is changed to a UINT32 type so it has the same width as the type it is being compared against. Issue explanation: In a loop condition, comparison of a value of a narrow type with a value of a wide type may result in unexpected behavior if the wider value is sufficiently large (or small). This is because the narrower value may overflow. This can lead to an infinite loop. Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Gua Guo <gua.guo@intel.com> Cc: Prakashan Krishnadas Veliyathuparambil <krishnadas.veliyathuparambil.prakashan@intel.com> Cc: K N Karthik <karthik.k.n@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Gua Guo <gua.guo@intel.com>
* MdeModulePkg/Bus/Usb/UsbNetwork: Check array index range before accessMichael Kubacki2024-02-263-3/+3
| | | | | | | | | | | | Checks that an offset used to access array elements is within the expected range before accessing the array item. Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Ray Ni <ray.ni@intel.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Richard Ho <richardho@ami.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Align RuntimeDxe function headers with UEFI return valuesSuqiang Ren2024-02-097-41/+174
| | | | | | | | | | | | | RuntimeDxe is used to back the runtime services time functions, so align the description of the function return values with the defined values for these services as described in UEFI Spec 2.10. REF: UEFI spec 2.10 section 8 Services ? Runtime Services Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Suqiang Ren <suqiangx.ren@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Optimize CoreConnectSingleControllerZhi Jin2024-02-061-1/+6
| | | | | | | | | | | | CoreConnectSingleController() searches for the Driver Family Override Protocol drivers by looping and checking each Driver Binding Handles. This loop can be skipped by checking if any Driver Family Override Protocol installed in the platform first, to improve the performance. Cc: Ray Ni <ray.ni@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Zhi Jin <zhi.jin@intel.com>
* MdeModulePkg: Remove handle validation check in CoreGetProtocolInterfaceZhi Jin2024-02-061-6/+12
| | | | | | | | | | | | | | | | | | | | CoreGetProtocolInterface() is called by CoreOpenProtocol(), CoreCloseProtocol() and CoreOpenProtocolInformation(). Before CoreOpenProtocol() calls CoreGetProtocolInterface(), the input parameter UserHandle has been already checked for validation. So does CoreCloseProtocol(). Removing the handle validation check in CoreGetProtocolInterface() could improve the performance, as CoreOpenProtocol() is called very frequently. To ensure the assumption that the caller of CoreGetProtocolInterface() must pass in a valid UserHandle that is checked with CoreValidateHandle(), add the parameter check in CoreOpenProtocolInformation(), and declare CoreGetProtocolInterface() as static. Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Zhi Jin <zhi.jin@intel.com>
* MdeModulePkg: Dxe: add LOONGARCH64 to mMachineTypeInfoDongyan Qian2024-02-021-6/+7
| | | | | | | | | | | This fixes messages like: "Image type X64 can't be loaded on <Unknown> UEFI system" Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Chao Li <lichao@loongson.cn> Signed-off-by: Dongyan Qian <qiandongyan@loongson.cn> Reviewed-by: Chao Li <lichao@loongson.cn> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/Core/Dxe: Set MemoryTypeInfo bin range from HOBMichael D Kinney2024-01-304-8/+186
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Provide an optional method for PEI to declare a specific address range to use for the Memory Type Information bins. The current algorithm uses heuristics that tends to place the Memory Type Information bins in the same location, but memory configuration changes across boots or algorithm changes across a firmware updates could potentially change the Memory Type Information bin location. If the bin locations move across an S4 save/resume cycle, then the S4 resume may fail. Enabling this feature increases the number of scenarios that an S4 resume operation may succeed. If the HOB List contains a Resource Descriptor HOB that describes tested system memory and has an Owner GUID of gEfiMemoryTypeInformationGuid, then use the address range described by the Resource Descriptor HOB as the preferred location of the Memory Type Information bins. If this HOB is not detected, then the current behavior is preserved. The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid is ignored for the following conditions: * The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid is smaller than the Memory Type Information bins. * The HOB list contains more than one Resource Descriptor HOB with an owner GUID of gEfiMemoryTypeInformationGuid. * The Resource Descriptor HOB with an Owner GUID of gEfiMemoryTypeInformationGuid is the same Resource Descriptor HOB that that describes the PHIT memory range. Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Aaron Li <aaron.li@intel.com> Cc: Liu Yun <yun.y.liu@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* MdeModulePkg/Core/Dxe: Initialize GCD before RT memory allocationsMichael D Kinney2024-01-302-16/+20
| | | | | | | | | | | | | | | | | Update the DxeMain initialization order to initialize GCD services before any runtime allocations are performed. This is required to prevent runtime data fragmentation when the UEFI System Table and UEFI Runtime Service Table are allocated before both the memory and GCD services are initialized. Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Aaron Li <aaron.li@intel.com> Cc: Liu Yun <yun.y.liu@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* MdeModulePkg/PciBusDxe: Add feedback status for PciIoMapSheng Wei2024-01-251-6/+6
| | | | | | | | | | | | PciIoMap () need to feedback the status of mIoMmuProtocol->SetAttribute () return value. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4652 Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Huang Jenny <jenny.huang@intel.com> Cc: Chiang Chris <chris.chiang@intel.com> Signed-off-by: Sheng Wei <w.sheng@intel.com>
* MdeModulePkg/DriverSampleDxe: EFI_BROWSER_ACTION_REQUEST_QUESTION_APPLYMing Tan2024-01-244-0/+28
| | | | | | | | | | | | | | | | | REF: UEFI_Spec_2_10_Aug29.pdf page 1695. In 35.5.4 EFI_HII_CONFIG_ACCESS_PROTOCOL.CallBack(): If the callback function returns with the ActionRequest set to _QUESTION_APPLY, then the Forms Browser will write the current modified question value on the selected form to storage. Update the DriverSampleDxe, add a new question "Question apply test". Signed-off-by: Ming Tan <ming.tan@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/SetupBrowserDxe: EFI_BROWSER_ACTION_REQUEST_QUESTION_APPLYMing Tan2024-01-241-0/+9
| | | | | | | | | | | | | | | | | | | REF: UEFI_Spec_2_10_Aug29.pdf page 1695. In 35.5.4 EFI_HII_CONFIG_ACCESS_PROTOCOL.CallBack(): If the callback function returns with the ActionRequest set to _QUESTION_APPLY, then the Forms Browser will write the current modified question value on the selected form to storage. Update the SetupBrowserDxe, if callback function return EFI_BROWSER_ACTION_REQUEST_QUESTION_APPLY, then call SetQuestionValue with GetSetValueWithHiiDriver to apply the change immediately. Signed-off-by: Ming Tan <ming.tan@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/ResetSystemRuntimeDxe: Print Reset DataAshish Singhal2024-01-241-0/+8
| | | | | | | | | ResetSystem runtime call allows for sending reset data that starts with a NULL terminated string. Add support to print that string on console. Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
* MdeModulePkg/DebugAgentLibNull: Indicate SMM Debug Agent support or notJiaxin Wu2023-12-261-0/+12
| | | | | | | | | | | This patch is to use the Context to indicate SMM Debug Agent support or not if InitFlag is DEBUG_AGENT_INIT_SMM. Context must point to a BOOLEAN if it's not NULL. Cc: Ray Ni <ray.ni@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@Intel.com>
* MdeModulePkg: Support customized FV Migration InformationCheng Sun2023-12-256-75/+106
| | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4533 There are use cases which not all FVs need be migrated from TempRam to permanent memory before TempRam tears down. This new guid is introduced to avoid unnecessary FV migration to improve boot performance. Platform can publish MigrationInfo hob with this guid to customize FV migration info, and PeiCore will only migrate FVs indicated by this Hob info. This is a backwards compatible change, PeiCore will check MigrationInfo hob before migration. If MigrationInfo hobs exists, only migrate FVs recorded by hobs. If MigrationInfo hobs not exists, migrate all FVs to permanent memory. Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Ray Ni <ray.ni@intel.com> Cc: Guomin Jiang <guomin.jiang@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Ray Ni <ray.ni@intel.com> Signed-off-by: Cheng Sun <chengx.sun@intel.com>
* MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recoveryNeal Gompa2023-12-191-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the ReadyToBoot event is only signaled when a formal Boot Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()). However, the introduction of Platform Recovery in UEFI 2.5 makes it necessary to signal ReadyToBoot when a Platform Recovery boot loader runs because otherwise it may lead to the execution of a boot loader that has similar requirements to a regular one that is not launched as a Boot Manager option. This is especially critical to ensuring that the graphical console is actually usable during platform recovery, as some platforms do rely on the ConsolePrefDxe driver, which only performs console initialization after ReadyToBoot is triggered. This patch fixes that behavior by calling EfiSignalEventReadyToBoot () in EfiBootManagerProcessLoadOption () when invoking platform recovery, which is the function that sets up the platform recovery boot process. The expected behavior has been clarified in the UEFI 2.10 specification to explicitly indicate this behavior is required for correct operation. This is a rebased version of the patch originally written by Pete Batard. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2831 Co-authored-by: Pete Batard <pete@akeo.ie> Signed-off-by: Neal Gompa <ngompa@fedoraproject.org> Reviewed-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/Bus: Fix XhciDxe Linker IssuesNate DeSimone2023-12-061-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The DXE & MM standalone variant of AcpiTimerLib defines a global named mPerformanceCounterFrequency. A global with an identical name is also present in MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c Since XhciDxe has a dependency on TimerLib, this can cause link errors due to the same symbol being defined twice if the platform DSC chooses to use AcpiTimerLib as the TimerLib implementation for any given platform. To resolve this, I noted that some of the globals in Xhci.c are not used outside of the Xhci.c compilation unit: - mPerformanceCounterStartValue - mPerformanceCounterEndValue - mPerformanceCounterFrequency - mPerformanceCounterValuesCached I have changed the definition for all of these to static and added an Xhci prefix. Since they are not used outside of the Xhci.c compilation unit, there is no reason to have them exported as globals. Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
* MdeModulePkg: Optimize CoreInstallMultipleProtocolInterfacesZhi Jin2023-12-011-17/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | CoreLocateDevicePath is used in CoreInstallMultipleProtocolInterfaces to check if a Device Path Protocol instance with the same device path is alreay installed. CoreLocateDevicePath is a generic API, and would introduce some unnecessary overhead for such usage. The optimization is: 1. Implement IsDevicePathInstalled to loop all the Device Path Protocols installed and check if any of them matchs the given device path. 2. Replace CoreLocateDevicePath with IsDevicePathInstalled in CoreInstallMultipleProtocolInterfaces. This optimization could save several seconds in PCI enumeration on a system with many PCI devices. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Zhi Jin <zhi.jin@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/Variable: Merge variable header + data update into one stepGao Cheng2023-11-291-41/+4
| | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4597 When creating a new variable, skip marking VAR_HEADER_VALID_ONLY so that variable header + data update can be merged into one flash write. This will greatly reduce the time taken for updating a variable and thus increase performance. Removing VAR_HEADER_VALID_ONLY marking doesn't have any function impact since it's not used by current code to detect variable header + data corruption. Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Gao Cheng <gao.cheng@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/DxeCapsuleLibFmp: Fix crash with VirtualAddressMap omittedNhi Pham2023-11-282-12/+7
| | | | | | | | | | | | | If the SetVirtualAddressMap() is not called, mIsVirtualAddrConverted is FALSE and the kernel crash occurs in IsNestedFmpCapsule() when executing gBS->LocateProtocol () in the else case. To serve the omitted SetVirtualAddressMap() call, we could just check mEsrtTable presence instead of relying on mIsVirtualAddrConverted. Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Update DumpImageRecord() in ImagePropertiesRecordLibTaylor Beebe2023-11-276-23/+137
| | | | | | | | | | | | | | | Update DumpImageRecord() to be DumpImageRecords(), and improve the debug output. The function will output at DEBUG_INFO instead, and the function will be run in DXE and SMM MAT logic when the MAT is installed at EndOfDxe on DEBUG builds. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Add Logic to Create/Delete Image Properties RecordsTaylor Beebe2023-11-275-294/+280
| | | | | | | | | | | | | Add logic to create and delete image properties records. Where applicable, redirect existing code to use the new library. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Transition SMM MAT Logic to Use ImagePropertiesRecordLibTaylor Beebe2023-11-274-768/+58
| | | | | | | | | | | | | | Now that the bugs are fixed in the MAT logic, we can remove the duplicate logic from PiSmmCore/MemoryAttributesTable.c and use ImagePropertiesRecordLib instead. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Add NULL checks and Return Status to ImagePropertiesRecordLibTaylor Beebe2023-11-272-189/+254
| | | | | | | | | | | | | Update function headers to clarify the contract of each function and improve readability. Add NULL checks to all functions that take a pointer as an argument. Add return status to functions that may need to return early due to invalid input. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Dandan Bi <dandan.bi@intel.com> Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Fix MAT SplitTable() LogicTaylor Beebe2023-11-271-19/+19
| | | | | | | | | | | | | | | | | SplitTable() does not properly handle the case where there is an odd number of code regions within a loaded image. When there are an odd number of code regions, at least one image region descriptor is overwritten with uninitialized memory which has caused crashes in the right conditions. This failure cases is documented extensively in the following bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4492 Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Dandan Bi <dandan.bi@intel.com> Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Fix MAT SplitRecord() LogicTaylor Beebe2023-11-271-29/+27
| | | | | | | | | | | | | SplitRecord() does not handle the case where a memory descriptor describes an image region plus extra pages before or after the image region. This patch fixes this case by carving off the unrelated regions into their own descriptors. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Dandan Bi <dandan.bi@intel.com> Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Fix MAT Descriptor Count CalculationTaylor Beebe2023-11-272-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | |4K PAGE|DATA|CODE|DATA|CODE|DATA|4K PAGE| Say the above memory region is currently one memory map descriptor. The above image memory layout example contains two code sections oriented in a way that maximizes the number of descriptors which would be required to describe each section. NOTE: It's unlikely that a data section would ever be between two code sections, but it's still handled by the below formula for correctness. There are two code sections (let's say CodeSegmentMax == 2), three data sections, and two unrelated memory regions flanking the image. The number of required descriptors to describe this layout will be 2 * 2 + 3 == 7. This patch updates the calculations to account for the worst-case scenario. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Dandan Bi <dandan.bi@intel.com> Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-03 16:21:27 +0000