Tianocore/edk2.git/MdeModulePkg/Core, branch trunk

Renormalized end-of-lines from master@27b044605cd5f6b33a3d231576003850b3fe305b

2024-06-04T03:43:08+00:00

MdeModulePkg: Update GCD attribute conversion to support SP attribute

2024-06-02T01:58:12+00:00

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

MdeModulePkg/SMM: Initialize 'WillReturn' variable

2024-05-30T01:57:35+00:00

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

MdeModulePkg: Use newly defined Unaccepted Memory Type

2024-05-08T11:34:49+00:00

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 Cc: Dhanaraj V Cc: Liming Gao Signed-off-by: Sachin Ganesh Reviewed-by: Liming Gao

MdeModulePkg/SMM: Support to unregister SMI handler in SMI handlers

2024-04-16T04:41:27+00:00

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 Cc: Jiaxin Wu Reviewed-by: Ray Ni Cc: Laszlo Ersek Signed-off-by: Zhiguang Liu

Revert ae1079b386a597108a8070652bf7cdaa4ec3dda3

2024-04-16T04:41:27+00:00

This reverts "MdeModulePkg/SMM: Support to unregister SMI handler inside SMI handler" for better design later. Cc: Liming Gao Cc: Jiaxin Wu Cc: Ray Ni Cc: Laszlo Ersek Reviewed-by: Ray Ni Cc: Laszlo Ersek Cc: Ard Biesheuvel Cc: Sami Mujawar Signed-off-by: Zhiguang Liu

Revert 17b28722008eab745ce186b72cd325944cbe6bf0

2024-04-16T04:41:27+00:00

This reverts commit "MdeModulePkg/SMM: Disallow unregister SMI handler in other SMI handler" for better design later. Cc: Liming Gao Cc: Jiaxin Wu Cc: Ray Ni Cc: Laszlo Ersek Reviewed-by: Ray Ni Cc: Laszlo Ersek Cc: Ard Biesheuvel Cc: Sami Mujawar Signed-off-by: Zhiguang Liu

MdeModulePkg: MemoryProtection: Use ImageRecordPropertiesLib

2024-03-29T23:56:16+00:00

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 Cc: Taylor Beebe Acked-by: Michael D Kinney Reviewed-by: Ard Biesheuvel Signed-off-by: Oliver Smith-Denny

MdeModulePkg: DxeCore: Do Not Apply Guards to Unsupported Types

2024-03-14T16:29:22+00:00

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 Cc: Ard Biesheuvel Cc: Sami Mujawar Cc: Liming Gao Signed-off-by: Oliver Smith-Denny Reviewed-by: Liming Gao

MdeModulePkg: DxeCore: Correct Runtime Granularity Memory Type

2024-03-14T16:29:22+00:00

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 Cc: Ard Biesheuvel Cc: Sami Mujawar Cc: Liming Gao Signed-off-by: Oliver Smith-Denny Suggested-by: Ard Biesheuvel Reviewed-by: Liming Gao