summaryrefslogtreecommitdiffstats
path: root/MdeModulePkg/Core/Dxe
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* MdeModulePkg/Core/Dxe: free page 0 after disabling NULL pointer detectionJian J Wang2019-11-091-0/+5
| | | | | | | | | | | | | | | | | To solve access issue reported by BZ1885, page 0 will be allocated to avoid misuses if NULL pointer detection is enabled. It should be better to be freed after EndOfDxe if BIT7 of PcdNullPointerDetectionPropertyMask is set, because NULL pointer detection is no longer available after EndOfDxe and there will be no access conflict. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1885 Cc: Dandan Bi <dandan.bi@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/Mem: Initialize the variable MapMemoryShenglei Zhang2019-11-041-0/+2
| | | | | | | | | | | MapMemory is not initialized by FindGuardedMemoryMap or CoreInternalAllocatePages which calls MapMemory. So we give a 0 to it. Cc: Dandan Bi <dandan.bi@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
* MdeModulePkg DxeCore: Fix typo in function namePhilippe Mathieu-Daude2019-10-171-2/+2
| | | | | | | | | | An extra 's' slipped into the FvIsBeingProcessed function name. Drop it to fix the typo. Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
* MdeModulePkg: document workaround for EFI_RUNTIME_EVENT_ENTRY PI spec bugLaszlo Ersek2019-10-091-0/+8
| | | | | | | | | | | | | | | | | | | | | | The PI spec (v1.7) correctly specifies "EFI_RUNTIME_EVENT_ENTRY.Event" in natural language, but the field type in the structure definition itself is wrong -- it should be EFI_EVENT, not (EFI_EVENT*). This spec bug is likely unfixable for compatibility reasons, and so edk2 works it around already. We should clearly document the workaround. Functionally, this patch is a no-op. (I've also requested a non-normative (informative) clarification for the PI spec: <https://mantis.uefi.org/mantis/view.php?id=2017>.) 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 <liming.gao@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg DxeCore: Fix for missing Memory Attributes Table (MAT) updateMike Turner2019-08-201-6/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Fpdt driver (FirmwarePerformanceDxe) saves a memory address across reboots, and then does an AllocatePage for that memory address. If, on this boot, that memory comes from a Runtime memory bucket, the MAT table is not updated. This causes Windows to boot into Recovery. This patch blocks the memory manager from changing the page from a special bucket to a different memory type. Once the buckets are allocated, we freeze the memory ranges for the OS, and fragmenting the special buckets will cause errors resuming from hibernate (S4). The references to S4 here are the use case that fails. This failure is root caused to an inconsistent behavior of the core memory services themselves when type AllocateAddress is used. The main issue is apparently with the UEFI memory map -- the UEFI memory map reflects the pre-allocated bins, but the actual allocations at fixed addresses may go out of sync with that. Everything else, such as: - EFI_MEMORY_ATTRIBUTES_TABLE (page protections) being out of sync, - S4 failing are just symptoms / consequences. This patch is cherry pick from Project Mu: https://github.com/microsoft/mu_basecore/commit/a9be767d9be96af94016ebd391ea6f340920735a With the minor change, 1. Update commit message format to keep the message in 80 characters one line. 2. Remove // MU_CHANGE comments in source code. 3. Update comments style to follow edk2 style. 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: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Liming Gao <liming.gao@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Acked-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/Core: Remove PcdFrameworkCompatibilitySupport usageDandan Bi2019-05-093-220/+3
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1464 Currently Framework compatibility is not needed and PcdFrameworkCompatibilitySupport will be removed from edk2. So remove the usage of this PCD firstly. Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdeModulePkg/DxeCore: Please static checker for false reportHao Wu2019-04-281-9/+14
| | | | | | | | | | | | | | | | | | | | | | After commit 57df17fe26, some static check reports suspicious NULL pointer deference at line: Entry->MachineType = Entry->Emulator->MachineType; ^^^^^^^^^^^^^^^ within function PeCoffEmuProtocolNotify(). However, 'Entry->Emulator' is guaranteed to have a non-NULL value when previous call to the CoreHandleProtocol() returns EFI_SUCCESS. This commit will re-write the return status check for CoreHandleProtocol() to add explicit NULL pointer check for protocol instance pointer. Cc: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Hao Wu <hao.a.wu@intel.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* MdeModulePkg/DxeCore: remove explicit EBC handlingArd Biesheuvel2019-04-143-54/+3
| | | | | | | | | | | Now that the EBC machine type is no longer classified as a natively supported machine type on the architectures that can support it via the EBC interpreter, the EBC specific handling in DXE core is no longer used and can be removed. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/DxeCore: invoke the emulator protocol for foreign imagesArd Biesheuvel2019-04-143-11/+164
| | | | | | | | | | | When encountering PE/COFF images that cannot be supported natively, attempt to locate an instance of the PE/COFF image emulator protocol, and if it supports the image, proceed with loading it and register it with the emulator. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-0945-315/+45
| | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg/DxeCore: Ensure FfsFileHeader 8 bytes alignedStar Zeng2019-02-281-51/+14
| | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=864 REF: CVE-2018-3630 To follow PI spec, ensure FfsFileHeader 8 bytes aligned. For the integrity of FV(especially non-MemoryMapped FV) layout, let CachedFv point to FV beginning, but not (FV + FV header). And current code only handles (FwVolHeader->ExtHeaderOffset != 0) path, update code to also handle (FwVolHeader->ExtHeaderOffset == 0) path. Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg/Dxe/Page: take MAX_ALLOC_ADDRESS into accountArd Biesheuvel2018-12-201-26/+26
| | | | | | | | | | | Take MAX_ALLOC_ADDRESS into account in the implementation of the page allocation routines, so that they will only return memory that is addressable by the CPU at boot time, even if more memory is available in the GCD memory map. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg/Dxe/Gcd: disregard memory above MAX_ALLOC_ADDRESSArd Biesheuvel2018-12-201-4/+4
| | | | | | | | | | | | | Update the GCD memory map initialization code so it disregards memory that is not addressable by the CPU at boot time. This only affects the first memory descriptor that is added, other memory descriptors are permitted that describe memory ranges that may be accessible to the CPU itself only when executing under the OS. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg/Core: fix ineffective guard page issueJian J Wang2018-11-071-19/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1295 This issue originates from following patch which allows to enable paging if PcdImageProtectionPolicy and PcdDxeNxMemoryProtectionPolicy (in addition to PcdSetNxForStack) are set to enable related features. 5267926134d17e86672b84fd57b438f05ffa68e1 Due to above change, PcdImageProtectionPolicy will be set to 0 by default in many platforms, which, in turn, cause following code in MdeModulePkg\Core\Dxe\Misc\MemoryProtection.c fail the creation of notify event of CpuArchProtocol. 1138: if (mImageProtectionPolicy != 0 || PcdGet64 (PcdDxeNxMemoryProtectionPolicy) != 0) { 1139: Status = CoreCreateEvent ( ... 1142: MemoryProtectionCpuArchProtocolNotify, ... 1145: ); Then following call flow won't be done and Guard pages will not be set as not-present in SetAllGuardPages() eventually. MemoryProtectionCpuArchProtocolNotify() => HeapGuardCpuArchProtocolNotify() => SetAllGuardPages() The solution is removing the if(...) statement so that the notify event will always be created and registered. This won't cause unnecessary code execution because, in the notify event handler, the related PCDs like PcdImageProtectionPolicy and PcdDxeNxMemoryProtectionPolicy will be checked again before doing related jobs. Cc: Star Zeng <star.zeng@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/Core: fill logic hole in MemoryProtectionCpuArchProtocolNotifyJian J Wang2018-11-071-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the end of of MemoryProtectionCpuArchProtocolNotify there's cleanup code to free resource. But at line 978, 994, 1005 the function returns directly. This patch use "goto" to replace "return" to make sure the resource is freed before exit. 1029: CoreCloseEvent (Event); 1030: return; There's another memory leak after calling gBS->LocateHandleBuffer() in the same function: Status = gBS->LocateHandleBuffer ( ByProtocol, &gEfiLoadedImageProtocolGuid, NULL, &NoHandles, &HandleBuffer ); HandleBuffer is allocated in above call but never freed. This patch will also add code to free it. Cc: Star Zeng <star.zeng@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/Core: fix an issue of potential NULL pointer accessJian J Wang2018-10-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1286 This issue is introduced by bb685071c2602cf786ea84c69bbebf2158194a38. The *MemorySpaceMap assigned with NULL (line 1710) value might be accessed (line 1726/1730) without any sanity check. Although it won't happen in practice because of line 1722, we still need to add check against NULL to make static code analyzer happy. 1710 *MemorySpaceMap = NULL; .... ... 1722 if (DescriptorCount == *NumberOfDescriptors) { .... ... 1726 Descriptor = *MemorySpaceMap; .... ... 1730 BuildMemoryDescriptor (Descriptor, Entry); Tests: Pass build and boot to shell. Cc: Hao Wu <hao.a.wu@intel.com> Cc: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/Core: correct one coding styleJian J Wang2018-10-271-1/+1
| | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1284 Non-Boolean comparisons should use a compare operator (==, !=, >, < >=, <=) Cc: Dandan Bi <dandan.bi@intel.com> Cc: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
* MdeModulePkg/Core: fix an IA32 build failureJian J Wang2018-10-261-5/+5
| | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1277 The failure is caused by data type conversion between UINTN and UINT64, which is checked in at 63ebde8ef6d4ff497d054ccc010904ecd4441198. Cc: Star Zeng <star.zeng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/Core: add freed-memory guard featureJian J Wang2018-10-266-34/+525
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Freed-memory guard is used to detect UAF (Use-After-Free) memory issue which is illegal access to memory which has been freed. The principle behind is similar to pool guard feature, that is we'll turn all pool memory allocation to page allocation and mark them to be not-present once they are freed. This also implies that, once a page is allocated and freed, it cannot be re-allocated. This will bring another issue, which is that there's risk that memory space will be used out. To address it, the memory service add logic to put part (at most 64 pages a time) of freed pages back into page pool, so that the memory service can still have memory to allocate, when all memory space have been allocated once. This is called memory promotion. The promoted pages are always from the eldest pages which haven been freed. This feature brings another problem is that memory map descriptors will be increased enormously (200+ -> 2000+). One of change in this patch is to update MergeMemoryMap() in file PropertiesTable.c to allow merge freed pages back into the memory map. Now the number can stay at around 510. Cc: Star Zeng <star.zeng@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/Core: prevent re-acquire GCD memory lockJian J Wang2018-10-261-25/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This issue is hidden in current code but exposed by introduction of freed-memory guard feature due to the fact that the feature will turn all pool allocation to page allocation. The solution is moving the memory allocation in CoreGetMemorySpaceMap() to be out of the GCD memory map lock. CoreDumpGcdMemorySpaceMap() => CoreGetMemorySpaceMap() => CoreAcquireGcdMemoryLock () * AllocatePool() => InternalAllocatePool() => CoreAllocatePool() => CoreAllocatePoolI() => CoreAllocatePoolPagesI() => CoreAllocatePoolPages() => FindFreePages() => PromoteMemoryResource() => CoreAcquireGcdMemoryLock() ** Cc: Star Zeng <star.zeng@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg: remove PE/COFF header workaround for ELILO on IPFArd Biesheuvel2018-09-243-62/+3
| | | | | | | | | | | | Now that Itanium support has been dropped, we can remove the various occurrences of the ELILO on Itanium PE/COFF header workaround. Link: https://bugzilla.tianocore.org/show_bug.cgi?id=816 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg: Removing ipf which is no longer supported from edk2.Chen A Chen2018-09-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Removing rules for Ipf sources file: * Remove the source file which path with "ipf" and also listed in [Sources.IPF] section of INF file. * Remove the source file which listed in [Components.IPF] section of DSC file and not listed in any other [Components] section. * Remove the embedded Ipf code for MDE_CPU_IPF. Removing rules for Inf file: * Remove IPF from VALID_ARCHITECTURES comments. * Remove DXE_SAL_DRIVER from LIBRARY_CLASS in [Defines] section. * Remove the INF which only listed in [Components.IPF] section in DSC. * Remove statements from [BuildOptions] that provide IPF specific flags. * Remove any IPF sepcific sections. Removing rules for Dec file: * Remove [Includes.IPF] section from Dec. Removing rules for Dsc file: * Remove IPF from SUPPORTED_ARCHITECTURES in [Defines] section of DSC. * Remove any IPF specific sections. * Remove statements from [BuildOptions] that provide IPF specific flags. Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Chen A Chen <chen.a.chen@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg DxeCore: Handle multiple FV images in one FV fileStar Zeng2018-09-031-115/+130
| | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1131 PI spec and BaseTools support to generate multiple FV images in one FV file. This patch is to update DxeCore to handle the case. Cc: Liming Gao <liming.gao@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdeModulePkg Core/Dxe: Remove redundant functionsshenglei2018-08-213-113/+0
| | | | | | | | | | | | | | | | The functions that are never called have been removed. They are ClearGuardMapBit,SetGuardMapBit,IsHeadGuard, IsTailGuard and CoreEfiNotAvailableYetArg0. https://bugzilla.tianocore.org/show_bug.cgi?id=1062 Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: shenglei <shenglei.zhang@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg: Remove redundant library classes and GUIDsshenglei2018-08-203-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some redundant library classes and GUIDs have been removed in inf, .c and .h files. https://bugzilla.tianocore.org/show_bug.cgi?id=1044 https://bugzilla.tianocore.org/show_bug.cgi?id=1045 https://bugzilla.tianocore.org/show_bug.cgi?id=1047 https://bugzilla.tianocore.org/show_bug.cgi?id=1049 https://bugzilla.tianocore.org/show_bug.cgi?id=1051 https://bugzilla.tianocore.org/show_bug.cgi?id=1052 https://bugzilla.tianocore.org/show_bug.cgi?id=1053 https://bugzilla.tianocore.org/show_bug.cgi?id=1054 https://bugzilla.tianocore.org/show_bug.cgi?id=1055 https://bugzilla.tianocore.org/show_bug.cgi?id=1056 https://bugzilla.tianocore.org/show_bug.cgi?id=1017 https://bugzilla.tianocore.org/show_bug.cgi?id=1035 https://bugzilla.tianocore.org/show_bug.cgi?id=1033 https://bugzilla.tianocore.org/show_bug.cgi?id=1012 https://bugzilla.tianocore.org/show_bug.cgi?id=1011 https://bugzilla.tianocore.org/show_bug.cgi?id=1062 v2: 1. Correct copyright year. 2. Fix alignment issue in AcpiPlatformDxe.inf. 3. Add DevicePathLib which is removed before in I2cHostDxe.inf. 4. Update NvmExpressPei.inf, NvmExpressPei.h, IScsiDxe.inf, IScsiDxe.inf, IScsiDxe.h, DxeMain.inf, DxeMain.h, PiSmmCore.inf and PiSmmCore.h for https://bugzilla.tianocore.org/show_bug.cgi?id=1062. v3: 1. Add https://bugzilla.tianocore.org/show_bug.cgi?id=1062 to the link list. 2. Remove DevicePathLib from I2cHostDxe.inf. 3. Update NvmExpressPei.inf, NvmExpressPei.h, UfsPciHcDxe.inf, UfsPciHcDxe.h, I2cHostDxe.inf, AtaBusDxe.inf, IScsiDxe.inf, IScsiDxe.h, DxeMain.inf, DxeMain.h, PiSmmCore.inf and PiSmmCore.h for https://bugzilla.tianocore.org/show_bug.cgi?id=1062. (Forget to add UfsPciHcDxe.inf, UfsPciHcDxe.h, AtaBusDxe.inf, and I2cHostDxe.inf previously.) Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: shenglei <shenglei.zhang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/DxeCore: Not update RtCode in MemAttrTable after EndOfDxeJiewen Yao2018-07-261-0/+13
| | | | | | | | | | | | | | | | We want to provide precise info in MemAttribTable to both OS and SMM, and SMM only gets the info at EndOfDxe. So we do not update RtCode entry in EndOfDxe. The impact is that if 3rd part OPROM is runtime, it cannot be executed at UEFI runtime phase. Currently, we do not see compatibility issue, because the only runtime OPROM we found before in UNDI, and UEFI OS will not use UNDI interface in OS. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/DxeCore: Install UEFI mem attrib table at EndOfDxe.Jiewen Yao2018-07-261-1/+35
| | | | | | | | | So that the SMM can consume it to set page protection for the UEFI runtime page with EFI_MEMORY_RO attribute. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg: Clean up source filesLiming Gao2018-06-2824-285/+285
| | | | | | | | | | 1. Do not use tab characters 2. No trailing white space in one line 3. All files must end with CRLF Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg: Use new added Perf macrosBi, Dandan2018-06-264-33/+20
| | | | | | | | | | | Replace old Perf macros with the new added ones. Cc: Liming Gao <liming.gao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdeModulePkg/Core: remove SMM check for Heap Guard feature detectionJian J Wang2018-06-191-10/+0
| | | | | | | | | | | | | | | CpuDxe driver is updated to be able to access DXE page table in SMM mode, which means Heap Guard can get correct memory paging attributes in what environment. It's not necessary to exclude SMM from detecting Heap Guard feature support. Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/DxeCore: add sanity check for SetMemoryAttributesJian J Wang2018-04-131-2/+7
| | | | | | | | | | | | | | | Heap Guard feature needs enough memory and paging to work. Otherwise calling SetMemoryAttributes to change page attribute will fail. This patch add necessary check of result of calling SetMemoryAttributes. This can help users to debug their problem in enabling this feature. Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/Gcd: Suppress incorrect compiler/analyzer warningsStar Zeng2018-04-081-1/+5
| | | | | | | | | | | | | | It is caused by 0c9f2cb10b7ddec56a3440e77219fd3ab1725e5c and false positive. Initialize CpuArchAttributes to suppress incorrect compiler/analyzer warnings. Cc: Dandan Bi <dandan.bi@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
* MdeModulePkg/Gcd: Filter gCpu->SetMemoryAttributes() callsKinney, Michael D2018-04-051-3/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes an issue with VlvTbltDevicePkg introduced by commit 5b91bf82c67b586b9588cbe4bbffa1588f6b5926. The history is as below. To support heap guard feature, 14dde9e903bb9a719ebb8f3381da72b19509bc36 added support for SetMemorySpaceAttributes() to handle page attributes, but after that, a combination of CPU arch attributes and other attributes was not allowed anymore, for example, UC + RUNTIME. It is a regression. Then 5b91bf82c67b586b9588cbe4bbffa1588f6b5926 was to fix the regression, and we thought 0 CPU arch attributes may be used to clear CPU arch attributes, so 0 CPU arch attributes was allowed to be sent to gCpu->SetMemoryAttributes(). But some implementation of CPU driver may return error for 0 CPU arch attributes. That fails the case that caller just calls SetMemorySpaceAttributes() with none CPU arch attributes (for example, RUNTIME), and the purpose of the case is not to clear CPU arch attributes. This patch filters the call to gCpu->SetMemoryAttributes() if the requested attributes is 0. It also removes the #define INVALID_CPU_ARCH_ATTRIBUTES that is no longer used. Cc: Heyi Guo <heyi.guo@linaro.org> Cc: Yi Li <phoenix.liyi@huawei.com> Cc: Renhao Liang <liangrenhao@huawei.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* MdeModulePkg/Gcd: Fix bug of attribute conversionHeyi Guo2018-04-021-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | For gDS->SetMemorySpaceAttributes(), when user passes a combined memory attribute including CPU arch attribute and other attributes, like EFI_MEMORY_RUNTIME, ConverToCpuArchAttributes() will return INVALID_CPU_ARCH_ATTRIBUTES and skip setting page/cache attribute for the specified memory space. We don't see any reason to forbid combining CPU arch attributes and non-CPU-arch attributes when calling gDS->SetMemorySpaceAttributes(), so we remove the check code in ConverToCpuArchAttributes(); the remaining code is enough to grab the interested bits for Cpu->SetMemoryAttributes(). Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Heyi Guo <heyi.guo@linaro.org> Signed-off-by: Yi Li <phoenix.liyi@huawei.com> Signed-off-by: Renhao Liang <liangrenhao@huawei.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
* MdeModulePkg/DxeMain: Fix BSP interrupts reenabled in ExitBootServicesHao Wu2018-03-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Within function CoreExitBootServices(), this commit will move the call of: MemoryProtectionExitBootServicesCallback(); before: SaveAndSetDebugTimerInterrupt (FALSE); and gCpu->DisableInterrupt (gCpu); The reason is that, within MemoryProtectionExitBootServicesCallback(), APIs like RaiseTpl and RestoreTpl maybe called. An example will be: DebugLib (using PeiDxeDebugLibReportStatusCode instance) | v ReportStatusCodeLib (using DxeReportStatusCodeLib instance) | v Raise/RestoreTpl The call of Raise/RestoreTpl APIs will re-enable BSP interrupts. Hence, this commit refine the calling sequence to ensure BSP interrupts before leaving CoreExitBootServices(). Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* MdeModulePkg/Core: fix bits operation error on a boundary conditionJian J Wang2018-03-161-6/+10
| | | | | | | | | | | | | | | | If given address is on 64K boundary and the requested bit number is 64, all SetBits(), ClearBits() and GetBits() will encounter ASSERT problem in trying to do a 64 bits of shift, which is not allowed by LShift() and RShift(). This patch tries to fix this issue by turning bits operation into whole integer operation in such situation. Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* MdeModulePkg/Core: allow HeapGuard even before CpuArchProtocol installedJian J Wang2018-03-164-1/+154
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to the fact that HeapGuard needs CpuArchProtocol to update page attributes, the feature is normally enabled after CpuArchProtocol is installed. Since there're some drivers are loaded before CpuArchProtocl, they cannot make use HeapGuard feature to detect potential issues. This patch fixes above situation by updating the DXE core to skip the NULL check against global gCpu in the IsMemoryTypeToGuard(), and adding NULL check against gCpu in SetGuardPage() and UnsetGuardPage() to make sure that they can be called but do nothing. This will allow HeapGuard to record all guarded memory without setting the related Guard pages to not- present. Once the CpuArchProtocol is installed, a protocol notify will be called to complete the work of setting Guard pages to not-present. Please note that above changes will cause a #PF in GCD code during cleanup of map entries, which is initiated by CpuDxe driver to update real mtrr and paging attributes back to GCD. During that time, CpuDxe doesn't allow GCD to update memory attributes and then any Guard page cannot be unset. As a result, this will prevent Guarded memory from freeing during memory map cleanup. The solution is to avoid allocating guarded memory as memory map entries in GCD code. It's done by setting global mOnGuarding to TRUE before memory allocation and setting it back to FALSE afterwards in GCD function CoreAllocateGcdMapEntry(). Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-01 21:36:33 +0000