summaryrefslogtreecommitdiff
path: root/MdeModulePkg/Core
AgeCommit message (Collapse)Author
2020-05-12MdeModulePkg/SmmIpl: expose MM communicate 2 protocolArd Biesheuvel
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>
2020-05-07MdeModulePkg/DxeIplPeim : RISC-V platform level DxeIPLAbner Chang
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>
2020-04-07MdeModulePkg/DxeCore: merge properties table routines into MAT handlingArd Biesheuvel
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>
2020-04-07MdeModulePkg: disable properties table generation but retain the codeArd Biesheuvel
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>
2020-03-04MdeModulePkg/PiSmmCore: log SMM image start failureLaszlo Ersek
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>
2020-03-04MdeModulePkg/DxeCore: defer PE/COFF emulator registration to StartImageArd Biesheuvel
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>
2020-02-19MdeModulePkg: Make retval in UninstallMultipleProtocol follow SpecHeinrich Schuchardt
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>
2020-02-10MdeModulePkg/Core/PiSmmCore: Fix various typosAntoine Coeur
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>
2020-02-10MdeModulePkg/Core/Pei: Fix various typosAntoine Coeur
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>
2019-12-11MdeModulePkg PeiCore: Improve comment semanticsMichael Kubacki
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>
2019-12-11MdeModulePkg PeiCore: Fix typosMichael Kubacki
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>
2019-11-09MdeModulePkg/Core/Dxe: free page 0 after disabling NULL pointer detectionJian J Wang
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>
2019-11-09MdeModulePkg/DxeIplPeim: reserve page 0 for NULL pointer detectionJian J Wang
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>
2019-11-04MdeModulePkg/Mem: Initialize the variable MapMemoryShenglei Zhang
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>
2019-10-17MdeModulePkg/PiSmmCore: Fix typo in function namePhilippe Mathieu-Daude
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>
2019-10-17MdeModulePkg DxeCore: Fix typo in function namePhilippe Mathieu-Daude
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>
2019-10-09MdeModulePkg/PiSmmCore: make type punning consistentLaszlo Ersek
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>
2019-10-09MdeModulePkg: PEI Core: clean up "AprioriFile" handling in FindFileEx()Laszlo Ersek
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>
2019-10-09MdeModulePkg: document workaround for EFI_RUNTIME_EVENT_ENTRY PI spec bugLaszlo Ersek
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>
2019-08-20MdeModulePkg DxeCore: Fix for missing Memory Attributes Table (MAT) updateMike Turner
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>
2019-08-16MdeModulePkg/DxeIplPeim: Initialize pointer PageMapLevel5EntryZhang, Shenglei
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>
2019-08-14MdeModulePkg/DxeIplPeim: Relocate operation of PageMapLevel5Entry++Zhang, Shenglei
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>
2019-08-09MdeModulePkg/DxeIpl: Create 5-level page table for long modeNi, Ray
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>
2019-08-05MdeModulePkg: Remove RecoveryLib.h and PeiRecoveryLibNullZhang, Shenglei
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>
2019-08-05MdeModulePkg: Remove S3Lib.h and PeiS3LibNullZhang, Shenglei
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>
2019-08-02MdeModulePkg/PiSmmCore: Use unique structure signaturesMichael D Kinney
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>
2019-06-26MdeModulePkg/DxeIpl: Support Capsule On Disk.Wei6 Xu
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>
2019-06-24MdeModulePkg/PeiMain: PeiAllocatePool: output NULL if HOB creation failsBret Barkelew
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>
2019-06-21Revert "Capsule-on-Disk entire PatchZhang, Chao B
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>
2019-06-20MdeModulePkg/DxeIpl: Support Capsule On Disk.Wei6 Xu
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>
2019-05-09MdeModulePkg/Core: Remove PcdFrameworkCompatibilitySupport usageDandan Bi
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>
2019-04-28MdeModulePkg/PeiMain: Change comments of PeiResetSystem2Zhichao Gao
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>
2019-04-28MdeModulePkg/DxeCore: Please static checker for false reportHao Wu
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>
2019-04-14MdeModulePkg/DxeCore: remove explicit EBC handlingArd Biesheuvel
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>
2019-04-14MdeModulePkg/DxeCore: invoke the emulator protocol for foreign imagesArd Biesheuvel
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>
2019-04-09MdeModulePkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney
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>
2019-03-21MdeModulePkg/PiSmmCore: Control S3 related functionality through flag.Eric Dong
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>
2019-02-28MdeModulePkg/DxeCore: Ensure FfsFileHeader 8 bytes alignedStar Zeng
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>
2019-02-28MdeModulePkg/PeiCore: Ensure FfsFileHeader 8 bytes alignedStar Zeng
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=864 REF: CVE-2018-3630 To follow PI spec, ensure FfsFileHeader 8 bytes aligned. 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>
2019-02-15MdeModulePkg/PeiMain: Support EFI_PEI_CORE_FV_LOCATION_PPIChasel, Chiu
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1524 When shadowing PeiCore the EFI_PEI_CORE_FV_LOCATION_PPI should be checked to see if PeiCore not in BFV, otherwise just shadowing PeiCore from BFV. Test: Verified on internal platform and booting successfully. 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> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
2018-12-20MdeModulePkg/Dxe/Page: take MAX_ALLOC_ADDRESS into accountArd Biesheuvel
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>
2018-12-20MdeModulePkg/Dxe/Gcd: disregard memory above MAX_ALLOC_ADDRESSArd Biesheuvel
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>
2018-12-19MdeModulePkg PeiCore: Remove the using of PcdPeiCoreMaxPpiSupportedStar Zeng
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1405 Background as below. Problem: As static configuration from the PCDs, the binary PeiCore (for example in FSP binary with dispatch mode) could not predict how many FVs, Files or PPIs for different platforms. Burden: Platform developers need configure the PCDs accordingly for different platforms. To solve the problem and remove the burden, we can update code to remove the using of PcdPeiCoreMaxFvSupported, PcdPeiCoreMaxPeimPerFv and PcdPeiCoreMaxPpiSupported by extending buffer dynamically for FV, File and PPI management. This patch removes the using of PcdPeiCoreMaxPpiSupported in PeiCore. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Chasel Chiu <chasel.chiu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
2018-12-19MdeModulePkg PeiCore: Remove the using of PcdPeiCoreMaxFvSupportedStar Zeng
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1405 Background as below. Problem: As static configuration from the PCDs, the binary PeiCore (for example in FSP binary with dispatch mode) could not predict how many FVs, Files or PPIs for different platforms. Burden: Platform developers need configure the PCDs accordingly for different platforms. To solve the problem and remove the burden, we can update PeiCore to remove the using of PcdPeiCoreMaxFvSupported, PcdPeiCoreMaxPeimPerFv and PcdPeiCoreMaxPpiSupported by extending buffer dynamically for FV, File and PPI management. This patch removes the using of PcdPeiCoreMaxFvSupported in PeiCore. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Chasel Chiu <chasel.chiu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
2018-12-19MdeModulePkg PeiCore: Remove the using of PcdPeiCoreMaxPeimPerFvStar Zeng
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1405 Background as below. Problem: As static configuration from the PCDs, the binary PeiCore (for example in FSP binary with dispatch mode) could not predict how many FVs, Files or PPIs for different platforms. Burden: Platform developers need configure the PCDs accordingly for different platforms. To solve the problem and remove the burden, we can update code to remove the using of PcdPeiCoreMaxFvSupported, PcdPeiCoreMaxPeimPerFv and PcdPeiCoreMaxPpiSupported by extending buffer dynamically for FV, File and PPI management. This patch removes the using of PcdPeiCoreMaxPeimPerFv in PeiCore. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Chasel Chiu <chasel.chiu@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> Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
2018-11-07MdeModulePkg/Core: fix ineffective guard page issueJian J Wang
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>
2018-11-07MdeModulePkg/Core: fill logic hole in MemoryProtectionCpuArchProtocolNotifyJian J Wang
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>
2018-11-01MdeModulePkg/PiSmmIpl: Do not reset SMRAM to UC when CPU driver runsRuiyu Ni
Today's PiSmmIpl implementation initially sets SMRAM to WB to speed up the SMM core/modules loading before SMM CPU driver runs. When SMM CPU driver runs, PiSmmIpl resets the SMRAM to UC. It's done in SmmIplDxeDispatchEventNotify(). COMM_BUFFER_SMM_DISPATCH_RESTART is returned from SMM core that SMM CPU driver is just dispatched. Since now the SMRR is widely used to control the SMRAM cache setting. It's not needed to reset the SMRAM to UC anymore. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
2018-10-30MdeModulePkg/Core: fix an issue of potential NULL pointer accessJian J Wang
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>
2018-10-27MdeModulePkg/Core: correct one coding styleJian J Wang
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-22 11:02:10 +0000