summaryrefslogtreecommitdiffstats
path: root/MdeModulePkg/Core
Commit message (Collapse)AuthorAgeFilesLines
* MdeModulePkg: Update GCD attribute conversion to support SP attributeDu Lin10 days1-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 Liu13 days1-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: Use newly defined Unaccepted Memory TypeSachin Ganesh2024-05-082-24/+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/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: 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: DxeCore: Do Not Apply Guards to Unsupported TypesOliver Smith-Denny2024-03-143-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/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: Align RuntimeDxe function headers with UEFI return valuesSuqiang Ren2024-02-092-2/+18
| | | | | | | | | | | | | 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-303-3/+177
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Support customized FV Migration InformationCheng Sun2023-12-254-73/+63
| | | | | | | | | | | | | | | | | | | | | | | 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: 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: Update DumpImageRecord() in ImagePropertiesRecordLibTaylor Beebe2023-11-272-3/+17
| | | | | | | | | | | | | | | 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-272-294/+54
| | | | | | | | | | | | | 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-272-768/+18
| | | | | | | | | | | | | | 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: Fix MAT Descriptor Count CalculationTaylor Beebe2023-11-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | |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>
* MdeModulePkg: Move Some DXE MAT Logic to ImagePropertiesRecordLibTaylor Beebe2023-11-274-805/+14
| | | | | | | | | | | Move some DXE MAT logic to ImagePropertiesRecordLib to consolidate code and enable unit testability. 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: Update MemoryAttributesTable.c to Reduce Global Variable UseTaylor Beebe2023-11-271-48/+54
| | | | | | | | | | | This patch updates MemoryAttributesTable.c to reduce reliance on global variables and allow some logic to move to a library. 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/DxeCore: Allow relocation of images with large addressJeff Brasen2023-10-312-1/+4
| | | | | | | | | | | | | | | | Add PCD to control if modules with start addresses in PE/COFF > 0x100000 attempt to load at specified address. If a module has an address in this range and there is untested memory DxeCore will attempt to promote all memory to tested which bypasses any memory testing that would occur later in boot. There are several existing AARCH64 option roms that have base addresses of 0x180000000. Signed-off-by: Jeff Brasen <jbrasen@nvidia.com> Reviewed-by: Ashish Singhal <ashishsingha@nvidia.com> Message-Id: <bd36c9c24158590db2226ede05cb8c2f50c93a37.1684194452.git.jbrasen@nvidia.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Fix misspellingNate DeSimone2023-09-261-2/+2
| | | | | | | | | | confroms should be conforms. Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Dandan Bi <dandan.bi@intel.com>
* MdeModulePkg: Memory Bin Range Update Accounts for Guard PageTaylor Beebe2023-09-181-1/+1
| | | | | | | | | | | | | | | | | | | | When finding a free page range for allocation, if the found range starts below the tracked memory bin address range, the lowest memory bin address is updated which will not include the guard page if present. When CoreConvertPagesWithGuard() is called on the range being allocated, the memory range is adjusted to include guard pages which can push it out of the memory bin address range and cause the memory type statistics to be unaltered. This patch updates the lowest memory bin address range to account for the guard page if NeedGuard is TRUE so the memory type statistics are updated correctly. 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 <t@taylorbeebe.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/Core/Dxe: Fix memory leak issue in FwVolBlock.cMike Maslenkin2023-09-111-0/+2
| | | | | | | | | | | FvbDev->LbaCache must be freed on error path before freeing FvbDev. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Mike Maslenkin <mike.maslenkin@gmail.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/Core/Dxe: Fix memory leak issue in FwVol.cMike Maslenkin2023-09-111-0/+1
| | | | | | | | | | | FwVolHeader must be freed on error path. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Mike Maslenkin <mike.maslenkin@gmail.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Fix memory leak in LocateHandleBuffer()Nate DeSimone2023-08-311-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4543 REF: https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html#efi-boot-services-locatehandlebuffer CoreLocateHandleBuffer() can in certain cases, return an error and not free an allocated buffer. This scenario occurs if the first call to InternalCoreLocateHandle() returns success and the second call returns an error. On a successful return, LocateHandleBuffer() passes ownership of the buffer to the caller. However, the UEFI specification is not explicit about what the expected ownership of this buffer is in the case of an error. However, it is heavily implied by the code example given in section 7.3.15 of v2.10 of the UEFI specificaton that if LocateHandleBuffer() returns a non-successful status code then the ownership of the buffer does NOT transfer to the caller. This code example explicitly refrains from calling FreePool() if LocateHandleBuffer() returns an error. From a practical standpoint, it is logical to assume that a non-successful status code indicates that no buffer of handles was ever allocated. Indeed, in most error cases, LocateHandleBuffer() does not go far enough to get to the point where a buffer is allocated. Therefore, all existing users of this API must already be coded to support the case of a non-successful status code resulting in an invalid handle buffer being returned. Therefore, this change will not cause any backwards compatibility issues with existing code. In conclusion, this boils down to a fix for a memory leak that also brings the behavior of our LocateHandleBuffer() implementation into alignment with the original intentions of the UEFI specification authors. Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
* MdeModulePkg: HeapGuard: Don't Assume Pool Head Allocated In First PageOliver Smith-Denny2023-08-193-5/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, HeapGuard, when in the GuardAlignedToTail mode, assumes that the pool head has been allocated in the first page of memory that was allocated. This is not the case for ARM64 platforms when allocating runtime pools, as RUNTIME_PAGE_ALLOCATION_GRANULARITY is 64k, unlike X64, which has RUNTIME_PAGE_ALLOCATION_GRANULARITY as 4k. When a runtime pool is allocated on ARM64, the minimum number of pages allocated is 16, to match the runtime granularity. When a small pool is allocated and GuardAlignedToTail is true, HeapGuard instructs the pool head to be placed as (MemoryAllocated + EFI_PAGES_TO_SIZE(Number of Pages) - SizeRequiredForPool). This gives this scenario: |Head Guard|Large Free Number of Pages|PoolHead|TailGuard| When this pool goes to be freed, HeapGuard instructs the pool code to free from (PoolHead & ~EFI_PAGE_MASK). However, this assumes that the PoolHead is in the first page allocated, which as shown above is not true in this case. For the 4k granularity case (i.e. where the correct number of pages are allocated for this pool), this logic does work. In this failing case, HeapGuard then instructs the pool code to free 16 (or more depending) pages from the page the pool head was allocated on, which as seen above means we overrun the pool and attempt to free memory far past the pool. We end up running into the tail guard and getting an access flag fault. This causes ArmVirtQemu to fail to boot with an access flag fault when GuardAlignedToTail is set to true (and pool guard enabled for runtime memory). It should also cause all ARM64 platforms to fail in this configuration, for exactly the same reason, as this is core code making the assumption. This patch removes HeapGuard's assumption that the pool head is allocated on the first page and instead undoes the same logic that HeapGuard did when allocating the pool head in the first place. With this patch in place, ArmVirtQemu boots with GuardAlignedToTail set to true (and when it is false, also). BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4521 Github PR: https://github.com/tianocore/edk2/pull/4731 Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> 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: Oliver Smith-Denny <osde@linux.microsoft.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Leif Lindholm <quic_llindhol@quicinc.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Remove other attribute protection in UnsetGuardPageDun Tan2023-06-301-1/+15
| | | | | | | | | | | | | | | | In UnsetGuardPage(), before SmmReadyToLock, remove NX and RO memory attribute protection for guarded page since EfiConventionalMemory in SMRAM is RW and executable before SmmReadyToLock. If UnsetGuardPage() happens after SmmReadyToLock, then apply EFI_MEMORY_XP to the guarded page to make sure EfiConventionalMemory in SMRAM is NX since EfiConventionalMemory in SMRAM is marked as NX in PiSmmCpuDxe driver when SmmReadyToLock. Signed-off-by: Dun Tan <dun.tan@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Ray Ni <ray.ni@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
* MdeModulePkg/DxeIpl ARM AARCH64: Switch to generic handoff codeArd Biesheuvel2023-06-262-81/+1
| | | | | | | | | | | Now that we have a generic method to manage memory permissions using a PPI, we can switch to the generic version of the DXE handoff code in DxeIpl, and drop the ARM specific version. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com> Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/DxeIpl: Use memory attribute PPI to remap the stack NXArd Biesheuvel2023-06-262-4/+30
| | | | | | | | | | | | If the associated PCD is set to TRUE, use the memory attribute PPI to remap the stack non-executable. This provides a generic method for doing so, which will be used by ARM and AArch64 as well once they move to the generic DxeIpl handoff implementation. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com> Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/DxeIpl: Merge EBC, RISCV64 and LOONGARCH codeArd Biesheuvel2023-06-264-147/+3
| | | | | | | | | | | | | | | The Risc-V and LoongArch specific versions of the DXE core handoff code in DxeIpl are essentially copies of the EBC version (modulo the copyright in the header and some debug prints in the code). In preparation for introducing a generic PPI based method to implement the non-executable stack, let's merge these versions, so we only need to add this logic once. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com> Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/SmmCore: Perf-log PlatformHookBefore/AfterSmmDispatchRay Ni2023-06-211-0/+4
| | | | | | | | Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg/SmmCore: Add perf-logging for SmmDriverDispatchHandlerRay Ni2023-06-211-1/+4
| | | | | | | | | | | | | | SmmDriverDispatchHandler is the routine that dispatches SMM drivers from FV. It's a time-consuming routine. Add perf-logging for this routine. Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg/SmmCore: Add perf-logging for time-consuming proceduresRay Ni2023-06-212-1/+20
| | | | | | | | | | | | | | | | | | Following procedures are perf-logged: * SmmReadyToBootHandler * SmmReadyToLockHandler * SmmEndOfDxeHandler * SmmEntryPoint (It's the main routine run in BSP when SMI happens.) * SmiManage Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg/DxeIpl: Align Page table Level setting with previous level.Jiaxin Wu2023-05-311-12/+24
| | | | | | | | | | | | | | | | | | | | | | System paging 5 level enabled or not can be checked via CR4.LA57, system preferred Page table Level (PcdUse5LevelPageTable) must align with previous level for 64bit long mode. This patch is to do the wise check: If cpu has already run in 64bit long mode PEI, Page table Level in DXE must align with previous level. If cpu runs in 32bit protected mode PEI, Page table Level in DXE is decided by PCD and feature capability. Cc: Dandan Bi <dandan.bi@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zeng Star <star.zeng@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/Core/Pei: set AprioriCount=0 before walking through next FVedk2-stable202305Wendy Liao2023-05-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4438 The main dispatch loop in PeiDispatcher() goes through each FV and calls DiscoverPeimsAndOrderWithApriori() to search Apriori file to reorder all PEIMs then do the PEIM dispatched. DiscoverPeimsAndOrderWithApriori() calculates Apriori file count for every FV once and set Private->AprioriCount, but Private->AprioriCount doesn't be set to 0 before dispatch loop walking through the next FV. It causes the peim which sort on less than Private->AprioriCount and depex is not satisfied would be dispatched when dispatch loop go through to a scaned FV, even the peim is not set in APRIORI file. Cc: Leon Chen <leon.chen@insyde.com> Cc: Tim Lewis <tim.lewis@insyde.com> Reported-by: Esther Lee <esther.lee@insyde.com> Signed-off-by: Wendy Liao <wendy.liao@insyde.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Update code to be more C11 compliant by using __func__Rebecca Cran2023-04-108-12/+12
| | | | | | | | | | | | __FUNCTION__ is a pre-standard extension that gcc and Visual C++ among others support, while __func__ was standardized in C99. Since it's more standard, replace __FUNCTION__ with __func__ throughout MdeModulePkg. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* MdeModulePkg: Enable forward edge CFI in mem attributes tableArd Biesheuvel2023-04-073-1/+19
| | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4405 The memory attributes table has been extended with a flag that indicates whether or not the OS is permitted to map the EFI runtime code regions with strict enforcement for IBT/BTI landing pad instructions. Given that the PE/COFF spec now defines a DllCharacteristicsEx flag that indicates whether or not a loaded image is compatible with this, we can wire this up to the flag in the memory attributes table, and set it if all loaded runtime image are compatible with it. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com> Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com> Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Fix conditionally uninitialized variablesMichael Kubacki2023-04-031-8/+9
| | | | | | | | | | | | | | | | | | | Fixes CodeQL alerts for CWE-457: https://cwe.mitre.org/data/definitions/457.html Cc: Dandan Bi <dandan.bi@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Erich McMillan <emcmillan@microsoft.com> Cc: Guomin Jiang <guomin.jiang@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Michael Kubacki <mikuback@linux.microsoft.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Co-authored-by: Erich McMillan <emcmillan@microsoft.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
* MdePkg: Update MemoryAttributesTable to v2.10Ard Biesheuvel2023-03-301-1/+1
| | | | | | | | | | | | | | | | UEFI v2.10 introduces a new flag to the memory attributes table to inform the OS whether or not runtime services code regions were emitted by the compiler with guard instructions for forward edge control flow integrity enforcement. So update our definition accordingly. Link: https://uefi.org/specs/UEFI/2.10/04_EFI_System_Table.html#efi-memory-attributes-table Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Acked-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com> Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
* MdeModulePkg: Dxe: add RISCV64 to mMachineTypeInfoAndrei Warkentin2023-03-081-1/+2
| | | | | | | | | | | This fixes messages like: "Image type AARCH64 can't be loaded on <Unknown> UEFI system" Cc: Daniel Schaefer <git@danielschaefer.me> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Andrei Warkentin <andrei.warkentin@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-12 12:16:27 +0000