Tianocore/edk2.git/MdeModulePkg/Core/Dxe/Hand, branch master

MdeModulePkg/Core: Validate DXE event signature before usage

2026-03-23T18:43:11+00:00

fixes: #11112 Currently, function RegisterProtocolNotify() doesn't check the validity of event and it accepts any event pointer as long as pointer isn't NULL. However event could be closed and freed which could lead to use after free. Always check event signature before usage and return EFI_INVALID_PARAMTER for events with invalid signature. Signed-off-by: Khalid Ali

MdeModulePkg/Core: Increment handle key outside if block

2026-03-09T09:19:06+00:00

Fixes: #11113 Currently, the global handle key and key inside handle structure is incremented only when a new handle is allocated for protocol interface to be installed. However, when caller already supplies a handle gHandleDatabaseKey never get incremented. Move handle key incremental outside if block, just below the else statement which allows gHandleDatabaseKey to always incremented whether handle is supplied or not. Signed-off-by: Khalid Ali

MdeModulePkg: Replace include guards with #pragma once

2026-02-23T21:01:28+00:00

Replace traditional `#ifndef`/`#define`/`#endif` include guards with `#pragma` once. `#pragma once` is a widely supported preprocessor directive that prevents header files from being included multiple times. It is supported by all toolchains used to build edk2: GCC, Clang/LLVM, and MSVC. Compared to macro-based include guards, `#pragma once`: - Eliminates the risk of macro name collisions or copy/paste errors where two headers inadvertently use the same guard macro. - Eliminate inconsistency in the way include guard macros are named (e.g., some files use `__FILE_H__`, others use `FILE_H_`, etc.). - Reduces boilerplate (three lines replaced by one). - Avoids polluting the macro namespace with guard symbols. - Can improve build times as the preprocessor can skip re-opening the file entirely, rather than re-reading it to find the matching `#endif` ("multiple-include optimization"). - Note that some compilers may already optimize traditional include guards, by recognzining the idiomatic pattern. This change is made acknowledging that overall portability of the code will technically be reduced, as `#pragma once` is not part of the C/C++ standards. However, this is considered acceptable given: 1. edk2 already defines a subset of supported compilers in BaseTools/Conf/tools_def.template, all of which have supported `#pragma once` for over two decades. 2. There have been concerns raised to the project about inconsistent include guard naming and potential macro collisions. Approximate compiler support dates: - MSVC: Supported since Visual C++ 4.2 (1996) - GCC: Supported since 3.4 (2004) (http://gnu.ist.utl.pt/software/gcc/gcc-3.4/changes.html) - Clang (LLVM based): Since initial release in 2007 Signed-off-by: Michael Kubacki

MdeModulePkg: Fix missing NULL tests.

2025-11-22T18:58:47+00:00

https://github.com/github/codeql/blob/codeql-cli-2.7.3/cpp/ql/src/Critical/MissingNullTest.qhelp For items which allocate memory, or get a pointer from another structure, it is important to validate that the pointers are not null before they are dereferenced. Signed-off-by: Aaron Pop

MdeModulePkg: fix warning about uninitialized variable

2025-01-29T16:20:57+00:00

Handle.c:1302:24: error: 'Prot' may be used uninitialized in this function [-Werror=maybe-uninitialized] *Interface = Prot->Interface; ~~~~^~~~~~~~~~~ cc1: all warnings being treated as errors Signed-off-by: Mike Maslenkin

MdeModulePkg: CoreValidateHandle Optimization

2024-08-30T11:42:41+00:00

REF : https://bugzilla.tianocore.org/show_bug.cgi?id=4817 Before entering BIOS setup, CoreValidateHandle function executed over 600,000 times during BDS phase on latest 8S server platform. In CoreValidateHandle function, current implementation will go through the doubly-linked list handle database in each call, and this will have big impact on boot performance. The optimization is using Red-black tree to store the EFI handle address when insert each EFI handle into the handle database, and remove the handle from Red-black tree if the handle is removed from the handle database. CoreValidateHandle function changed to go through the Red-black tree. After verification on latest 8S server platform, BDS boot time can save 20s+ after this change. Cc: Ray Ni Cc: Star Zeng Cc: Liming Gao Signed-off-by: Andrew Fish Tested-by: Xiaoqiang Zhang

MdeModulePkg: Optimize CoreConnectSingleController

2024-02-06T17:54:53+00:00

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 Reviewed-by: Liming Gao Reviewed-by: Michael D Kinney Signed-off-by: Zhi Jin

MdeModulePkg: Remove handle validation check in CoreGetProtocolInterface

2024-02-06T17:54:53+00:00

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 Reviewed-by: Liming Gao Reviewed-by: Michael D Kinney Signed-off-by: Zhi Jin

MdeModulePkg: Optimize CoreInstallMultipleProtocolInterfaces

2023-12-01T00:53:56+00:00

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 Cc: Liming Gao Cc: Dandan Bi Cc: Ray Ni Signed-off-by: Zhi Jin Reviewed-by: Ray Ni Reviewed-by: Liming Gao

MdeModulePkg: Fix memory leak in LocateHandleBuffer()

2023-08-31T19:35:19+00:00

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 Cc: Liming Gao Cc: Jian J Wang Cc: Dandan Bi Signed-off-by: Nate DeSimone