summaryrefslogtreecommitdiffstats
path: root/MdeModulePkg
Commit message (Collapse)AuthorAgeFilesLines
* MdeModulePkg/DxeCapsuleLibFmp: Fix crash if no ESRT is foundNhi Pham2024-06-072-0/+17
| | | | | | | | | | | | The ESRT table is not required in UEFI firmware. In such cases, the table may not be present in the UEFI Configuration Table. The mEsrtTable is to check if the IsNestedFmpCapsule() function is invoked at runtime to determine whether to use gEsrtManagementProtocolGuid or the ESRT table from the Configuration Table. Unfortunately, the check does not cover situations where the ESRT is not present, potentially resulting in a kernel crash. This patch is intended to fix this issue. Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
* MdeModulePkg: In RemoveTableFromRsdt don't read from unallocated memoryRebecca Cran2024-06-071-4/+4
| | | | | | | Instead of copying from unallocated memory in RemoveTableFromRsdt, do a CopyMem followed by ZeroMem. Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
* MdeModulePkg: Warn if out of flash space when writing variablesOliver Steffen2024-06-071-0/+2
| | | | | | | | | | | | Emit a DEBUG_WARN message if there is not enough flash space left to write/update a variable. This condition is currently not logged appropriately in all cases, given that full variable store can easily render the system unbootable. This new message helps identifying this condition. Signed-off-by: Oliver Steffen <osteffen@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
* MdeModulePkg/HiiDatabaseDxe: Remove assert for VarStoreId = 0Jeff Brasen2024-06-061-2/+3
| | | | | | | | | | | | | | It is legal for the VarStoreId of a question to be 0 per the UEFI spec: "Specifies the identifier of a previously declared variable store to use when storing the question’s value. A value of zero indicates no associated variable store." Instead of hitting an assert just skip this question as there is no value to return. Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
* MdeModulePkg/HiiDatabaseDxe: Avoid struct assignmentArd Biesheuvel2024-06-041-4/+5
| | | | | | | | | | | | Struct assignments are not permitted in EDK2, as they may be converted by the compiler into calls to the 'memcpy' intrinsic, which is not guaranteed to be available in EDK2. So replace the assignment with a call to CopyMem (), and -while at it- replace the loop with a single CopyMem () call, as the loop operates on items that are contiguous in memory. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
* MdeModulePkg:Remove MpService2Ppi field in SMM_S3_RESUME_STATEDun Tan2024-06-041-2/+1
| | | | | | | | | | | | | | | This MpService2Ppi field in SMM_S3_RESUME_STATE is used to wakeup AP to do the CPU initialization during smm s3 boot when the execution mode of PEI and DXE are the same. Currently, in CpuS3.c of smm cpu driver, BSP doesn't need to wakeup AP anymore. The initialization for AP will be done in S3Resume.c before transfer to CpuS3.c of smm cpu driver. So we can remove the MpService2Ppi field in SMM_S3_RESUME_STATE. Signed-off-by: Dun Tan <dun.tan@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Add gEdkiiS3MtrrSettingGuidDun Tan2024-06-041-1/+4
| | | | | | | | | | | | Add gEdkiiS3MtrrSettingGuid a new GUID for s3 MTRR setting. This GUID will be used to save MTRR_SETTINGS at EndOfDxe by LockBox and restore at S3 boot PEI phase for s3 usage. Signed-off-by: Dun Tan <dun.tan@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
* MdeModulePkg: Update GCD attribute conversion to support SP attributeDu Lin2024-06-021-0/+1
| | | | | | | Add a new entry into GCD attribute conversion table to convert EFI_RESOURCE_ATTRIBUTE_SPECIAL_PURPOSE to EFI_MEMORY_SP. Signed-off-by: Du Lin <du.lin@intel.com>
* MdeModulePkg/SMM: Initialize 'WillReturn' variableZhiguang Liu2024-05-301-0/+1
| | | | | | | | | The local variable 'WillReturn' was being used without prior initialization in some code paths. This patch ensures that 'WillReturn' is properly initialized to prevent undefined behavior. Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* MdeModulePkg: Potential UINT32 overflow in S3 ResumeCountShanmugavel Pakkirisamy2024-05-171-4/+8
| | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4677 Attacker able to modify physical memory and ResumeCount. System will crash/DoS when ResumeCount reaches its MAX_UINT32. Cc: Zhiguang Liu <zhiguang.liu@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Pakkirisamy ShanmugavelX <shanmugavelx.pakkirisamy@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Use newly defined Unaccepted Memory TypeSachin Ganesh2024-05-084-69/+24
| | | | | | | | | | | | EFI_RESOURCE_MEMORY_UNACCEPTED has been officially defined in the PI 1.8 specification. So all temporary solutions have been replaced with the actual definition. Cc: Felix Polyudov <felixp@ami.com> Cc: Dhanaraj V <vdhanaraj@ami.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Sachin Ganesh <sachinganesh@ami.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Adding SpiHc DriversBrit Chesley2024-05-081-0/+2
| | | | | | | | | | | | | | Including the SpiHc drivers in MdeModulePkg.dsc Bugzilla #4753 Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Ray Ni <ray.ni@intel.com> Cc: Abner Chang <abner.chang@amd.com> Cc: Abdul Lateef Attar <AbdulLateef.Attar@amd.com> Signed-off-by: Brit Chesley <brit.chesley@amd.com> Acked-by: Abner Chang <abner.chang@amd.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: SpiHc: SpiHc DriversBrit Chesley2024-05-087-0/+514
| | | | | | | | | | | | | | Added SpiHc DXE and SMM drivers. This code receives bus transactions from the SpiBus layer and passes them onto the SpiHcPlatformLib Platform Initialization Spec 1.7 volume 5 section 18.1.7 Bugzilla #4753 Cc: Abner Chang <abner.chang@amd.com> Cc: Abdul Lateef Attar <AbdulLateef.Attar@amd.com> Signed-off-by: Brit Chesley <brit.chesley@amd.com> Reviewed-by: Abner Chang <abner.chang@amd.com>
* MdeModulePkg:BaseSpiHcPlatformLib: Adding NULL lib instanceBrit Chesley2024-05-086-0/+344
| | | | | | | | | | | | | | | | | | Adding NULL SpiHcPlatformLib instance. This library is responsible for handling the low level details of the SPI host controller. Since this is platform specific this library will be dependent on OEM SPI implementation. The SPI host controller layer will utilize this library for SPI bus transactions. Bugzilla #4753 Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Ray Ni <ray.ni@intel.com> Cc: Abner Chang <abner.chang@amd.com> Cc: Abdul Lateef Attar <AbdulLateef.Attar@amd.com> Signed-off-by: Brit Chesley <brit.chesley@amd.com> Acked-by: Abner Chang <abner.chang@amd.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Adding SpiBus DriversBrit Chesley2024-05-081-0/+2
| | | | | | | | | | | | | | | | Including the SpiBus drivers in MdeModulePkg.dsc Platform Initialization spec 1.7 volume 5 section 18.1.6 Bugzilla #4753 Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Ray Ni <ray.ni@intel.com> Cc: Abner Chang <abner.chang@amd.com> Cc: Abdul Lateef Attar <AbdulLateef.Attar@amd.com> Signed-off-by: Brit Chesley <brit.chesley@amd.com> Acked-by: Abner Chang <abner.chang@amd.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/Bus/Spi/SpiBus: Adding SpiBus DriversBrit Chesley2024-05-087-0/+1052
| | | | | | | | | | | | | | | | | Added SpiBus DXE and SMM drivers. This code translates SPI requests from the application layer into SPI Bus transactions on the SPI host controller. The code is responsible for checking if the transaction is valid, then setting up the SPI clock and chip select properly before passing the bus transaction to the host controller. Platform Initialization Spec 1.7 volume 5 section 18.1.6 Bugzilla #4753 Cc: Abner Chang <abner.chang@amd.com> Cc: Abdul Lateef Attar <AbdulLateef.Attar@amd.com> Signed-off-by: Brit Chesley <brit.chesley@amd.com> Reviewed-by: Abner Chang <abner.chang@amd.com>
* MdeModulePkg/XhciDxe: Add PCD for the delay of HCRSTXianglei Cai2024-05-074-1/+12
| | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=4727 Recently some of XHCI host controllers require to have extra 1ms delay before accessing any MMIO register during reset. PHY transition from P3 to P0 can take around 1.3ms and the xHCI reset can take around 1.5ms. Add PCD to control the delay, the default is 2 ms. Cc: Ray Ni <ray.ni@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Krzysztof Lewandowski <krzysztof.lewandowski@intel.com> Cc: Jenny Huang <jenny.huang@intel.com> Cc: More Shih <more.shih@intel.com> Cc: Ian Chiu <ian.chiu@intel.com> Signed-off-by: Xianglei Cai <xianglei.cai@intel.com> Reviewed-by: Krzysztof Lewandowski <krzysztof.lewandowski@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/XhciDxe: Reset endpoint while USB Transaction errorXianglei Cai2024-05-073-2/+15
| | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=4556 Based on XHCI spec 4.8.3, software should do the reset endpoint while USB Transaction occur. Add the error code for USB Transaction error since UEFI spec don't have the related definition. Cc: Ray Ni <ray.ni@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Krzysztof Lewandowski <krzysztof.lewandowski@intel.com> Cc: Jenny Huang <jenny.huang@intel.com> Cc: More Shih <more.shih@intel.com> Signed-off-by: Xianglei Cai <xianglei.cai@intel.com> Reviewed-by: Krzysztof Lewandowski <krzysztof.lewandowski@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/Variable: Add TCG SPDM device measurement updateWenxing Hou2024-04-304-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 DSCabnchang2024-04-201-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 SFDPabnchang2024-04-2011-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 Chang2024-04-201-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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-24 15:43:01 +0000