summaryrefslogtreecommitdiffstats
path: root/MdeModulePkg/Core
Commit message (Collapse)AuthorAgeFilesLines
* MdeModulePkg: Fix undefined reference to memcpy with XCODE5Vitaly Cheptsov2020-12-043-8/+8
| | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3098 XCODE5 toolchain in NOOPT mode generates memcpy when trying to copy PEI_CORE_FV_HANDLE structure. This breaks OVMF compilation with XCODE5. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Vitaly Cheptsov <cheptsov@ispras.ru> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Michael D Kinney <michael.d.kinney@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/DxeIplPeim: Support GHCB pages when creating page tablesTom Lendacky2020-08-165-16/+70
| | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 GHCB pages must be mapped as shared pages, so modify the process of creating identity mapped pagetable entries so that GHCB entries are created without the encryption bit set. The GHCB range consists of two pages per CPU, the first being the GHCB and the second being a per-CPU variable page. Only the GHCB page is mapped as shared. 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 <liming.gao@intel.com> Acked-by: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* MdeModulePkg/Core: Create Migrated FV Info Hob for calculating hash ↵Guomin Jiang2020-07-283-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | (CVE-2019-11098) REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1614 When we allocate pool to save the rebased PEIMs, the address will change randomly, therefore the hash will change and result PCR0 change as well. To avoid this, we save the raw PEIMs and use it to calculate hash. The MigratedFvInfo HOB will never produce when PcdMigrateTemporaryRamFirmwareVolumes is FALSE, because the PCD control the total feature. 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 <liming.gao@intel.com> Cc: Debkumar De <debkumar.de@intel.com> Cc: Harry Han <harry.han@intel.com> Cc: Catharine West <catharine.west@intel.com> Signed-off-by: Guomin Jiang <guomin.jiang@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdeModulePkg/PeiCore: Enable T-RAM evacuation in PeiCore (CVE-2019-11098)Michael Kubacki2020-07-287-9/+1099
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1614 Introduces new changes to PeiCore to move the contents of temporary RAM visible to the PeiCore to permanent memory. This expands on pre-existing shadowing support in the PeiCore to perform the following additional actions: 1. Migrate pointers in PPIs installed in PeiCore to the permanent memory copy of PeiCore. 2. Copy all installed firmware volumes to permanent memory. 3. Relocate and fix up the PEIMs within the firmware volumes. 4. Convert all PPIs into the migrated firmware volume to the corresponding PPI address in the permanent memory location. This applies to PPIs and PEI notifications. 5. Convert all status code callbacks in the migrated firmware volume to the corresponding address in the permanent memory location. 6. Update the FV HOB to the corresponding firmware volume in permanent memory. 7. Use PcdMigrateTemporaryRamFirmwareVolumes to control if enable the feature or not. when disable the PCD, the EvacuateTempRam() will never be called. The function control flow as below: PeiCore() DumpPpiList() EvacuateTempRam() ConvertPeiCorePpiPointers() ConvertPpiPointersFv() MigratePeimsInFv() MigratePeim() PeiGetPe32Data() LoadAndRelocatePeCoffImageInPlace() MigrateSecModulesInFv() ConvertPpiPointersFv() ConvertStatusCodeCallbacks() ConvertFvHob() RemoveFvHobsInTemporaryMemory() DumpPpiList() 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 <liming.gao@intel.com> Cc: Debkumar De <debkumar.de@intel.com> Cc: Harry Han <harry.han@intel.com> Cc: Catharine West <catharine.west@intel.com> Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* MdeModulePkg: Add New Memory AttributesOleksiy Yakovlev2020-07-154-28/+9
| | | | | | | | | | | | | 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/SmmIpl: expose MM communicate 2 protocolArd Biesheuvel2020-05-122-0/+81
| | | | | | | | | | | | | | | | | | | | The MM communicate 2 protocol was introduced to factor out the mismatch between traditional MM, which requires the physical address of the MM buffer to be passed, and standalone MM, which copies the MM communicate buffer data into a separate buffer, requiring the virtual address. For this reason, MM communicate 2 carries both addresses, allowing the implementation to decide which address it needs. This hides this implementation detail from the callers of the protocol, which simply passes both addresses without having to reason about what the implementation of the protocol actually needs. Note that the old version of the protocol is retained, in order to support existing implementations that don't require this flexibility. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
* MdeModulePkg/DxeIplPeim : RISC-V platform level DxeIPLAbner Chang2020-05-072-1/+79
| | | | | | | | | | | | | | | | | Implementation of RISC-V DxeIPL. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2672 Signed-off-by: Abner Chang <abner.chang@hpe.com> Co-authored-by: Gilbert Chen <gilbert.chen@hpe.com> Co-authored-by: Daniel Helmut <daniel.schaefer@hpe.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Gilbert Chen <gilbert.chen@hpe.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/PiSmmCore: log SMM image start failureLaszlo Ersek2020-03-041-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the CoreStartImage() function [MdeModulePkg/Core/Dxe/Image/Image.c], if the image entry point returns a failure code, then the DXE Core logs a helpful DEBUG_ERROR message, with the following format string: "Error: Image at %11p start failed: %r\n" Do similarly in the SMM Core (update the message slightly). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Eric Dong <eric.dong@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Ray Ni <ray.ni@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226221156.29589-2-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.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/PiSmmCore: Fix various typosAntoine Coeur2020-02-1014-53/+53
| | | | | | | | | | | | Fix various typos in comments and documentation. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-18-philmd@redhat.com>
* MdeModulePkg/Core/Pei: Fix various typosAntoine Coeur2020-02-105-11/+11
| | | | | | | | | | | | Fix various typos in comments and documentation. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-17-philmd@redhat.com>
* MdeModulePkg PeiCore: Improve comment semanticsMichael Kubacki2019-12-116-27/+31
| | | | | | | | | | | | | This patch clarifies wording in several PeiCore comments to improve reading comprehension. Cc: Dandan Bi <dandan.bi@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg PeiCore: Fix typosMichael Kubacki2019-12-1112-112/+112
| | | | | | | | | | | Cc: Dandan Bi <dandan.bi@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@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/DxeIplPeim: reserve page 0 for NULL pointer detectionJian J Wang2019-11-092-0/+8
| | | | | | | | | | | | | | | | | | | | | When a boot loader examines the memory map, it can see that location 0 is available memory. If it chooses to use that memory, and PcdNullPointerDetectionPropertyMask is enabled, use of memory in page 0 will cause an exception. This does occur when running the memtest86 program. Leaving page 0 available is for legacy support purpose. Since we have deprecated the support of legacy, the solution is just reserving it so that it cannot be allocated for other uses. 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/PiSmmCore: 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 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/PiSmmCore: make type punning consistentLaszlo Ersek2019-10-091-4/+4
| | | | | | | | | | | | | | | | | | The SmiHandlerRegister() function explicitly casts "SmiHandler" (of type (SMI_HANDLER*)) to EFI_HANDLE, when outputting "DispatchHandle". Apply the same cast in the counterpart function SmiHandlerUnRegister(), which compares multiple "SmiHandler"s against the input "DispatchHandle". This is a semantic cleanup; there is no functional change. Cc: Eric Dong <eric.dong@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg: PEI Core: clean up "AprioriFile" handling in FindFileEx()Laszlo Ersek2019-10-092-2/+2
| | | | | | | | | | | | | | | | | | | | | | | Clean up two issues around FindFileEx(): - The "AprioriFile" parameter's type differs between the function declaration and the function definition. The correct type is (EFI_PEI_FILE_HANDLE*). - "FfsFileHeader" has type (EFI_FFS_FILE_HEADER*); for clarity, we should cast it explicitly to EFI_PEI_FILE_HANDLE when assigning it to (*AprioriFile). This is a semantic cleanup, there is no functional change. 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: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg: document workaround for EFI_RUNTIME_EVENT_ENTRY PI spec bugLaszlo Ersek2019-10-092-1/+17
| | | | | | | | | | | | | | | | | | | | | | 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/DxeIplPeim: Initialize pointer PageMapLevel5EntryZhang, Shenglei2019-08-161-0/+5
| | | | | | | | | | | | | | | | Initialize PageMapLevel5Entry at the beginning of the function. This commit will fix a GCC 4.8.5 build failure introduced by commit b3527dedc3951f061c5a73cb4fb2b0f95f47e08b. OvmfPkg build failure wtih gcc 4.8.5 still exists at latest edk2 version. The commit 46f8a6891606746ca8b1e684ac379ce271306dc0 seems not to fix the build failure completely. Cc: Dandan Bi <dandan.bi@intel.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/DxeIplPeim: Relocate operation of PageMapLevel5Entry++Zhang, Shenglei2019-08-141-1/+2
| | | | | | | | | | | | | | | | This commit will fix a GCC 4.8.5 build failure introduced by commit b3527dedc3951f061c5a73cb4fb2b0f95f47e08b. PageMapLevel5Entry may be uninitialized in original code, which means uninitialized pointer will be modified at some circumstance. So relocate the operation of PageMapLevel5Entry++ in order to make sure the pointer could be modified only when it is initialized. Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* MdeModulePkg/DxeIpl: Create 5-level page table for long modeNi, Ray2019-08-092-77/+153
| | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2008 DxeIpl is responsible to create page table for DXE phase running either in long mode or in 32bit mode with certain protection mechanism enabled (refer to ToBuildPageTable()). The patch updates DxeIpl to create 5-level page table for DXE phase running in long mode when PcdUse5LevelPageTable is TRUE and CPU supports 5-level page table. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Eric Dong <eric.dong@intel.com>
* MdeModulePkg: Remove RecoveryLib.h and PeiRecoveryLibNullZhang, Shenglei2019-08-051-1/+0
| | | | | | | | | | | | RecoveryLib.h and PeiRecoveryLibNull have been deprecated from 2009, so remove them. https://bugzilla.tianocore.org/show_bug.cgi?id=1299 Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg: Remove S3Lib.h and PeiS3LibNullZhang, Shenglei2019-08-051-1/+0
| | | | | | | | | | | S3Lib.h and PeiS3LibNull have been deprecated since 2009, so remove them. https://bugzilla.tianocore.org/show_bug.cgi?id=1299 Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/PiSmmCore: Use unique structure signaturesMichael D Kinney2019-08-021-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1948 Update the data structure signatures in the PiSmmCore to be unique. Some of the signatures are the same as those used by the DxeCore. For example, the memory pool head and tail structures use the same signature in the PiSmmCore and DxeCore. This means the use of the wrong FreePool API will not be noticed at the time FreePool is called and a failure can occur much later. By making the signatures unique, misuse of an API is caught at that time the API is called. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/DxeIpl: Support Capsule On Disk.Wei6 Xu2019-06-263-11/+42
| | | | | | | | | | | | | | | | REF: https://github.com/tianocore/tianocore.github.io/wiki/ UEFI-Capsule-on-Disk-Introducation If Capsule On Disk mode, call Capsule On Disk Load PPI to load capsules. When it fails, still goes to Firmware Update boot path. BDS will clear corresponding indicator and reboot later on. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Chao B Zhang <chao.b.zhang@intel.com> Signed-off-by: Wei6 Xu <wei6.xu@intel.com> Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com> Acked-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/PeiMain: PeiAllocatePool: output NULL if HOB creation failsBret Barkelew2019-06-241-1/+6
| | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1901 The original logic is ASSERT if fail to create HOB. But that doesn't make sense for release version. So it is required to set the Buffer to null to indicate the failure. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Michael Turner <Michael.Turner@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Acked-by: Hao A Wu <hao.a.wu@intel.com>
* Revert "Capsule-on-Disk entire PatchZhang, Chao B2019-06-213-42/+11
| | | | | | | | | | | | | | | | This reverts commit 0d4aa276d1f6e0cb9d71a7fb88b30c416ba6d5a3, 6470a43160183cd48cad8901c912a48811f18b13, fd7286089542ee7a98cfea00be45ceb3561e0b20, 7837d1249807b4248079699097bc993254235d7a, 6b32af2e105f9b5454a55b581f2dc365c5eb6397, 8636f70b5a763ed1c03b292708f9c5543e531ea9, f17935321a5b818a66e999632ef371b374b98f0c due to incorrect review process. Cc: Wei6 Xu <wei6.xu@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Zhang, Chao B <chao.b.zhang@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/DxeIpl: Support Capsule On Disk.Wei6 Xu2019-06-203-11/+42
| | | | | | | | | | | | | | | | https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Capsule- on-Disk-Introducation If Capsule On Disk mode, call Capsule On Disk Load PPI to load capsules. When it fails, still goes to Firmware Update boot path. BDS will clear corresponding indicator and reboot later on. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Chao B Zhang <chao.b.zhang@intel.com> Signed-off-by: Wei6 Xu <wei6.xu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
* MdeModulePkg/Core: Remove PcdFrameworkCompatibilitySupport usageDandan Bi2019-05-095-286/+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/PeiMain: Change comments of PeiResetSystem2Zhichao Gao2019-04-282-7/+3
| | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1460 Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific or not. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Michael Turner <Michael.Turner@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Hao Wu <hao.a.wu@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-09107-737/+107
| | | | | | | | | | | | | | | | | | | | | 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/PiSmmCore: Control S3 related functionality through flag.Eric Dong2019-03-212-22/+53
| | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1590 Use PcdAcpiS3Enable to control whether need to enable S3 related functionality in Pi SMM Core. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Hao Wu <hao.a.wu@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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-16 14:24:49 +0000