summaryrefslogtreecommitdiffstats
path: root/MdeModulePkg/Core/Dxe
Commit message (Collapse)AuthorAgeFilesLines
* 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: 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-271-0/+9
| | | | | | | | | | | | | | | 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-271-156/+28
| | | | | | | | | | | | | 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: 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: 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: Update code to be more C11 compliant by using __func__Rebecca Cran2023-04-104-6/+6
| | | | | | | | | | | | __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>
* MdeModulePkg: EfiUnacceptedMemoryType is not allowed in AllocatePoolMin M Xu2023-02-071-1/+1
| | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4315 MemoryType of EfiUnacceptedMemoryType should not be allocated in AllocatePool. Instead it should return EFI_INVALID_PARAMETER. Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Michael Roth <michael.roth@amd.com> Reported-by: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Min Xu <min.m.xu@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Notify BeforeExitBootServices in CoreExitBootServicesDionna Glaze2023-01-122-0/+7
| | | | | | | | | | | | | | | | | | | Location of notification is has been specified in UEFI v2.9. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: "Min M. Xu" <min.m.xu@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: "Michael D. Kinney" <michael.d.kinney@intel.com> Cc: Ray Ni <ray.ni@intel.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Dionna Glaze <dionnaglaze@google.com> Message-Id: <20221108164616.3251967-4-dionnaglaze@google.com>
* MdeModulePkg/DxeCore: Use correct type for alignment maskArd Biesheuvel2022-12-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | The page allocator code in CoreFindFreePagesI() uses a mask derived from its UINTN Alignment argument to align the descriptor end address of a MEMORY_MAP entry to the requested alignment, in order to check whether the descriptor covers enough sufficiently aligned area to satisfy the request. However, on 32-bit architectures, 'Alignment' is a 32-bit type, whereas DescEnd is a 64-bit type, and so the resulting operation performed on the end address comes down to masking with 0xfffff000 instead of the intended 0xffffffff_fffff000. Given the -1 at the end of the expression, the resulting address is 0xffffffff_fffffffff for any descriptor that ends on a 4G aligned boundary, and this is certainly not what was intended. So cast Alignment to UINT64 to ensure that the mask has the right size. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reported-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* MdeModulePkg: Update Dxe to handle unaccepted memory typeMin M Xu2022-11-012-17/+52
| | | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937 Unaccepted memory is a kind of new memory type, CoreInitializeGcdServices() and CoreGetMemoryMap() are updated to handle the unaccepted memory type. Ref: microsoft/mu_basecore@97e9c31 Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Ray Ni <ray.ni@intel.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Min Xu <min.m.xu@intel.com>
* MdeModulePkg: Fix imbalanced debug macrosMichael Kubacki2022-09-091-1/+1
| | | | | | | | | | | | | | | | | | | Updates debug macros in the package that have an imbalanced number of print specifiers to arguments. These changes try to preserve what was likely intended by the author. In cases information was missing due to the bug, the specifier may be removed since it was not previously accurately printing the expected value. Cc: Dandan Bi <dandan.bi@intel.com> Cc: Guomin Jiang <guomin.jiang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* UefiCpuPkg: Simplify InitializeSeparateExceptionStacksLiu, Zhiguang2022-08-091-2/+2
| | | | | | | | | | | | | | | | Hide the Exception implementation details in CpuExcetionHandlerLib and caller only need to provide buffer Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* MdeModulePkg/CoreDxe: Allow DXE Drivers to use untested memoryStacy Howell2022-07-221-0/+14
| | | | | | | | | | | | REF: https://https://bugzilla.tianocore.org/show_bug.cgi?id=3795 Cc: Dandan Bi <dandan.bi@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Updated CoreInternalAllocatePages() to call PromoteMemoryResource() and re-attempt the allocation if unable to convert the specified memory range Signed-off-by: Stacy Howell <stacy.howell@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* DxeMain: Fix the bug that StackGuard is not enabledRay Ni2022-06-141-0/+8
| | | | | | | | | | | | Commit e7abb94d1 removed InitializeCpuExceptionHandlersEx and updated DxeMain to call InitializeCpuExceptionHandlers for exception setup. But the old behavior that calls *Ex() sets up the stack guard as well. To match the old behavior, the patch calls InitializeSeparateExceptionStacks. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn>
* CpuException: Add InitializeSeparateExceptionStacksRay Ni2022-06-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Today InitializeCpuExceptionHandlersEx is called from three modules: 1. DxeCore (links to DxeCpuExceptionHandlerLib) DxeCore expects it initializes the IDT entries as well as assigning separate stacks for #DF and #PF. 2. CpuMpPei (links to PeiCpuExceptionHandlerLib) and CpuDxe (links to DxeCpuExceptionHandlerLib) It's called for each thread for only assigning separate stacks for #DF and #PF. The IDT entries initialization is skipped because caller sets InitData->X64.InitDefaultHandlers to FALSE. Additionally, SecPeiCpuExceptionHandlerLib, SmmCpuExceptionHandlerLib also implement such API and the behavior of the API is simply to initialize IDT entries only. Because it mixes the IDT entries initialization and separate stacks assignment for certain exception handlers together, in order to know whether the function call only initializes IDT entries, or assigns stacks, we need to check: 1. value of InitData->X64.InitDefaultHandlers 2. library instance This patch cleans up the code to separate the stack assignment to a new API: InitializeSeparateExceptionStacks(). Only when caller calls the new API, the separate stacks are assigned. With this change, the SecPei and Smm instance can return unsupported which gives caller a very clear status. The old API InitializeCpuExceptionHandlersEx() is removed in this patch. Because no platform module is consuming the old API, the impact is none. Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg: Apply uncrustify changesMichael Kubacki2021-12-0741-5195/+5186
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the MdeModulePkg package Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Change complex DEBUG_CODE() to DEBUG_CODE_BEGIN/END()Michael D Kinney2021-12-071-4/+4
| | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3767 Update use of DEBUG_CODE(Expression) if Expression is a complex code block with if/while/for/case statements that use {}. Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael Kubacki <michael.kubacki@microsoft.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Change OPTIONAL keyword usage styleMichael D Kinney2021-12-072-17/+16
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3760 Update all use of ', OPTIONAL' to ' OPTIONAL,' for function params. Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael Kubacki <michael.kubacki@microsoft.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Change use of EFI_D_* to DEBUG_*Michael D Kinney2021-12-078-28/+24
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3739 Update all use of EFI_D_* defines in DEBUG() macros to DEBUG_* defines. Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael Kubacki <michael.kubacki@microsoft.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/Core/Dxe: Acquire a lock when iterating gHandleListHua Ma2021-10-144-41/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3680 This patch fixes the following issue: The global variable gHandleList is a linked list. This list is locked when a entry is added or removed from the list, but there is no lock when iterating this list in function CoreValidateHandle(). It can lead to "Handle.c (76): CR has Bad Signature" assertion if the iterated entry in the list is just removed by other task during iterating. Currently some caller functions of CoreValidateHandle() have CoreAcquireProtocolLock(), but some caller functions of CoreValidateHandle() do not CoreAcquireProtocolLock(). Add CoreAcquireProtocolLock() always when CoreValidateHandle() is called, Also, A lock check is added in the CoreValidateHandle(). 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: Hua Ma <hua.ma@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg/Core/Dxe: Add lock protection in CoreLocateHandleBuffer()Hua Ma2021-10-081-13/+51
| | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3666 Currently, CoreLocateHandleBuffer() follows three steps: 1) get the size of protocol database firstly 2) allocate the buffer based on the size 3) get the protocol database into the buffer There is no lock protection for the whole three steps. If a new protocol added in step 2) by other task, e.g. (event timer handle USB device hotplug). The size of protocol database may be increased and cannot fit into the previous buffer in step 3). The protocol database cannot be returned successfully, EFI_BUFFER_TOO_SMALL error will be returned. This patch adds the lock to protect the whole three steps. It can make sure the correct protocol database be returned. 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: Hua Ma <hua.ma@intel.com> Reviewed-by: Dandan Bi dandan.bi@intel.com Reviewed-by: Liming Gao gaoliming@byosoft.com.cn
* MdeModulePkg: Fix various typosRebecca Cran2021-05-171-1/+1
| | | | | | | | Fix various typos throughout MdeModulePkg. Signed-off-by: Rebecca Cran <rebecca@nuviainc.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/Core/Dxe: limit FwVol encapsulation section recursionLaszlo Ersek2020-11-212-2/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DXE Core sets up a protocol notify function in its entry point, for instances of the Firmware Volume Block2 Protocol: DxeMain() [DxeMain/DxeMain.c] FwVolDriverInit() [FwVol/FwVol.c] Assume that a 3rd party UEFI driver or application installs an FVB instance, with crafted contents. The notification function runs: NotifyFwVolBlock() [FwVol/FwVol.c] installing an instance of the Firmware Volume 2 Protocol on the handle. (Alternatively, assume that a 3rd party application calls gDS->ProcessFirmwareVolume(), which may also produce a Firmware Volume 2 Protocol instance.) The EFI_FIRMWARE_VOLUME2_PROTOCOL.ReadSection() member performs "a depth-first, left-to-right search algorithm through all sections found in the specified file" (quoting the PI spec), as follows: FvReadFileSection() [FwVol/FwVolRead.c] GetSection() [SectionExtraction/CoreSectionExtraction.c] FindChildNode() [SectionExtraction/CoreSectionExtraction.c] FindChildNode() // recursive call FindChildNode() is called recursively for encapsulation sections. Currently this recursion is not limited. Introduce a new PCD (fixed-at-build, or patchable-in-module), and make FindChildNode() track the section nesting depth against that PCD. Cc: Dandan Bi <dandan.bi@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1743 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20201119105340.16225-3-lersek@redhat.com>
* MdeModulePkg/Core/Dxe: assert SectionInstance invariant in FindChildNode()Laszlo Ersek2020-11-211-6/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FindChildNode() has two callers: GetSection(), and FindChildNode() itself. - At the GetSection() call site, a positive (i.e., nonzero) SectionInstance is passed. This is because GetSection() takes a zero-based (UINTN) SectionInstance, and then passes Instance=(SectionInstance+1) to FindChildNode(). - For reaching the recursive FindChildNode() call site, a section type mismatch, or a section instance mismatch, is necessary. This means, respectively, that SectionInstance will either not have been decreased, or not to zero anyway, at the recursive FindChildNode() call site. Add two ASSERT()s to FindChildNode(), for expressing the (SectionSize>0) invariant. In turn, the invariant provides the explanation why, after the recursive call, a zero SectionInstance implies success. Capture it in a comment. Cc: Dandan Bi <dandan.bi@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20201119105340.16225-2-lersek@redhat.com>
* MdeModulePkg/Core/Dxe: log memory base and length, after lib ctors againLaszlo Ersek2020-11-061-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CoreInitializeMemoryServices() logs "BaseAddress" and "Length" with DEBUG() before DxeMain() calls ProcessLibraryConstructorList() explicitly. (Library construction is not an automatic part of the DXE Core entry point.) So those DEBUG()s in CoreInitializeMemoryServices() are issued against an un-constructed DebugLib, and also against a -- possibly underlying -- un-constructed SerialPortLib. Some DebugLib instances can deal with this (see for example commit 91a5b1365075, "OvmfPkg/PlatformDebugLibIoPort: fix port detection for use in the DXE Core", 2018-08-06), while some others can't (see for example the DebugLib instance "MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf" coupled with the SerialPortLib instance "ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.inf"). Addressing this issue in a SerialPortLib instance that underlies BaseDebugLibSerialPort seems wrong; either the DebugLib instance should cope directly with being called un-constructed (see again commit 91a5b1365075), or the DXE Core should log relevant information *at least* after library instances have been constructed. This patch implements the latter (only for the "BaseAddress" and "Length" values calculated by CoreInitializeMemoryServices()). Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jeff Brasen <jbrasen@nvidia.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201103161557.30621-1-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/Gcd: Check memory allocation when initializing memoryJeff Brasen2020-11-051-0/+58
| | | | | | | | | | | | CoreInitializeMemoryServices was not checking for any existing memory allocation created in the HOB producer phase. If there are memory allocations outside of the region covered by the HOB List then Gcd could select that region for memory which can result in the memory allocation to not be handled and memory overwrites. Signed-off-by: Jeff Brasen <jbrasen@nvidia.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* MdeModulePkg/Core: Support standalone MM in FV2 protocol GetNextFile().Siyuan Fu2020-10-291-3/+3
| | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3028 The FirmwareVolume2Protocol->GetNextFile() produced by DXE Core can be used to search for a file based on the value of *FileType input. However, this service will always return EFI_NOT_FOUND if the input FileType is set to EFI_FV_FILETYPE_MM_STANDALONE or EFI_FV_FILETYPE_MM_CORE_STANDALONE, Which means user can't use this service to search any standalone MM image in that FV. This patch update the FirmwareVolume2Protocol->GetNextFile() service to support searching standalone MM module. Signed-off-by: Siyuan Fu <siyuan.fu@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/Core/Dxe: expose SP and CRYPTO capabilities in UEFI memmapMalgorzata Kukiello2020-10-101-6/+6
| | | | | | | | | | | | | | | | | | OSs are now capable of treating SP and CRYPTO memory as true capabilities and therefore these should be exposed. This requires usage of a separate ACCESS_MASK to hide all page-access permission capabilities. Change in masking and hiding of SP and CRYPTO was introduced in 3bd5c994c879f78e8e3d5346dc3b627f199291aa Signed-off-by: Malgorzata Kukiello <jacek.kukiello@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Oleksiy Yakovlev <oleksiyy@ami.com> Cc: Ard Biesheuvel (ARM address) <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Fix spelling mistake for occurredMichael D Kinney2020-08-191-1/+1
| | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2361 Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Guomin Jiang <guomin.jiang@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg: Add New Memory AttributesOleksiy Yakovlev2020-07-153-20/+7
| | | | | | | | | | | | | Add usage of EFI_MEMORY_SP and EFI_MEMORY_CPU_CRYPTO attributes introduced in UEFI 2.8 (UEFI 2.8, mantis 1919 and 1872) Use attributes bitmasks, defined in MdePkg. Signed-off-by: Oleksiy Yakovlev <oleksiyy@ami.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200702205039.52400-3-oleksiyy@ami.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
* MdeModulePkg/DxeCore: merge properties table routines into MAT handlingArd Biesheuvel2020-04-075-1299/+1219
| | | | | | | | | | | | | | The memory attributes table handling code shared some parts of the properties table handling code when it was introduced. The latter has been dropped, and so we can merge the remaining pieces into the former. Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2633 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg: disable properties table generation but retain the codeArd Biesheuvel2020-04-074-103/+14
| | | | | | | | | | | | | | | This is the minimal change required to stop exposing the EFI properties table, which is deprecated. Given how the implementation is entangled with the code that exposes the related memory attributes table, most of the code is retained, and further cleanups are relegated to subsequent patches. Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2633 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg/DxeCore: defer PE/COFF emulator registration to StartImageArd Biesheuvel2020-03-041-11/+13
| | | | | | | | | | | | | | | | | | | | | | | | EDK2's implementation of the LoadImage() boot service permits non-native binaries to be loaded (i.e., X64 images on IA32 firmware), but any attempts to start such an image using StartImage() will return EFI_UNSUPPORTED. The integration of the PE/COFF emulator protocol into the DXE core deviates slightly from this paradigm, given that its IsImageSupported hook as well as its RegisterImage hook are invoked from LoadImage, and by the time StartImage is called, no opportunity is given to the provider of the PE/COFF emulator protocol to prevent an image from being started if it only supports loading it. To address this disparity, let's move the invocation of RegisterImage() to the implementation of the StartImage() boot service, allowing the emulator to permit LoadImage() but reject StartImage() on images that turn out not to meet the requirements of the emulator as it is being started. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Liming Gao <liming.gao@intel.com>
* MdeModulePkg: Make retval in UninstallMultipleProtocol follow SpecHeinrich Schuchardt2020-02-191-6/+14
| | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1869 The UEFI spec requires that if any error occurs in UninstallMultipleProtocolInterfaces(), EFI_INVALID_PARAMETER is returned and not the return code of UninstallProtocolInterface(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-12 16:15:27 +0000