summaryrefslogtreecommitdiffstats
path: root/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
Commit message (Collapse)AuthorAgeFilesLines
* MdeModulePkg: Move Some DXE MAT Logic to ImagePropertiesRecordLibTaylor Beebe2023-11-271-23/+1
| | | | | | | | | | | Move some DXE MAT logic to ImagePropertiesRecordLib to consolidate code and enable unit testability. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Dandan Bi <dandan.bi@intel.com> Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Update code to be more C11 compliant by using __func__Rebecca Cran2023-04-101-3/+3
| | | | | | | | | | | | __FUNCTION__ is a pre-standard extension that gcc and Visual C++ among others support, while __func__ was standardized in C99. Since it's more standard, replace __FUNCTION__ with __func__ throughout MdeModulePkg. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* MdeModulePkg: Apply uncrustify changesMichael Kubacki2021-12-071-235/+268
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the MdeModulePkg package Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg: Add New Memory AttributesOleksiy Yakovlev2020-07-151-5/+2
| | | | | | | | | | | | | 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: disable properties table generation but retain the codeArd Biesheuvel2020-04-071-1/+0
| | | | | | | | | | | | | | | 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/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: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-091-7/+1
| | | | | | | | | | | | | | | | | | | | | 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/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: add freed-memory guard featureJian J Wang2018-10-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: remove PE/COFF header workaround for ELILO on IPFArd Biesheuvel2018-09-241-16/+1
| | | | | | | | | | | | 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: Remove redundant library classes and GUIDsshenglei2018-08-201-1/+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/Core: allow HeapGuard even before CpuArchProtocol installedJian J Wang2018-03-161-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* MdeModulePkg/Core: Fix feature conflict between NX and Stack guardHao Wu2018-03-071-4/+58
| | | | | | | | | | | | | | | | | | | If enabled, NX memory protection feature will mark some types of active memory as NX (non-executable), which includes the first page of the stack. This will overwrite the attributes of the first page of the stack if the stack guard feature is also enabled. The solution is to override the attributes setting to the first page of the stack by adding back the 'EFI_MEMORY_RP' attribute when the stack guard feature is enabled. 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: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* MdeModulePkg/Core: Refine handling NULL detection in NX settingHao Wu2018-03-071-11/+11
| | | | | | | | | | | | | | | | | | | | The commit rewrites the logic in function InitializeDxeNxMemoryProtectionPolicy() for handling the first page (page 0) when NULL pointer detection feature is enabled. Instead of skip setting the page 0, the codes will now override the attribute setting of page 0 by adding the 'EFI_MEMORY_RP' attribute. The purpose is to make it easy for other special handling of pages (e.g. the first page of the stack when stack guard feature is enabled). 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: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* MdeModulePkg/Core: fix feature conflict between NX and heap guardJian J Wang2018-02-021-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Considering following scenario (both NX memory protection and heap guard are enabled): 1. Allocate 3 pages. The attributes of adjacent memory pages will be |NOT-PRESENT| present | present | present |NOT-PRESENT| 2. Free the middle page. The attributes of adjacent memory pages should be |NOT-PRESENT| present |NOT-PRESENT| present |NOT-PRESENT| But the NX feature will overwrite the attributes of middle page. So it looks still like below, which is wrong. |NOT-PRESENT| present | PRESENT | present |NOT-PRESENT| The solution is checking the first and/or last page of a memory block to be marked as NX, and skipping them if they are Guard pages. 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: fix feature conflict between NX and NULL detectionJian J Wang2018-02-021-4/+18
| | | | | | | | | | | | | | | | If enabled, NX memory protection feature will mark all free memory as NX (non-executable), including page 0. This will overwrite the attributes of page 0 if NULL pointer detection feature is also enabled and then compromise the functionality of it. The solution is skipping the NX attributes setting to page 0 if NULL pointer detection feature is enabled. 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: Fix heap guard issuesJian J Wang2017-12-261-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Three issues addressed here: a. Make NX memory protection and heap guard to be compatible The solution is to check PcdDxeNxMemoryProtectionPolicy in Heap Guard to see if the free memory should be set to NX, and set the Guard page to NX before it's freed back to memory pool. This can solve the issue which NX setting would be overwritten by Heap Guard feature in certain configuration. b. Returned pool address was not 8-byte aligned sometimes This happened only when BIT7 is not set in PcdHeapGuardPropertyMask. Since 8-byte alignment is UEFI spec required, letting allocated pool adjacent to tail guard page cannot be guaranteed. c. NULL address handling due to allocation failure When allocation failure, normally a NULL will be returned. But Heap Guard code will still try to adjust the starting address of it, which will cause a non-NULL pointer returned. 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: Jiewen Yao <jiewen.yao@intel.com>
* MdeModulePkg/Core/Dxe: log informative memprotect msgs at DEBUG_INFO levelLaszlo Ersek2017-12-051-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 7eb927db3e25 ("MdeModulePkg/DxeCore: implement memory protection policy", 2017-02-24), we added two informative messages with the InitializeDxeNxMemoryProtectionPolicy() function: > InitializeDxeNxMemoryProtectionPolicy: applying strict permissions to > active memory regions and > InitializeDxeNxMemoryProtectionPolicy: applying strict permissions to > inactive memory regions The messages don't report errors or warnings, thus downgrade their log masks from DEBUG_ERROR to DEBUG_INFO. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1520485 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg: Fix unix style of EOLJian J Wang2017-11-211-3/+3
| | | | | | | | | Cc: Wu Hao <hao.a.wu@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: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/DxeCore: Implement heap guard feature for UEFIJian J Wang2017-11-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This feature makes use of paging mechanism to add a hidden (not present) page just before and after the allocated memory block. If the code tries to access memory outside of the allocated part, page fault exception will be triggered. This feature is controlled by three PCDs: gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPoolType gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPageType BIT0 and BIT1 of PcdHeapGuardPropertyMask can be used to enable or disable memory guard for page and pool respectively. PcdHeapGuardPoolType and/or PcdHeapGuardPageType are used to enable or disable guard for specific type of memory. For example, we can turn on guard only for EfiBootServicesData and EfiRuntimeServicesData by setting the PCD with value 0x50. Pool memory is not ususally integer multiple of one page, and is more likely less than a page. There's no way to monitor the overflow at both top and bottom of pool memory. BIT7 of PcdHeapGuardPropertyMask is used to control how to position the head of pool memory so that it's easier to catch memory overflow in memory growing direction or in decreasing direction. Note1: Turning on heap guard, especially pool guard, will introduce too many memory fragments. Windows 10 has a limitation in its boot loader, which accepts at most 512 memory descriptors passed from BIOS. This will prevent Windows 10 from booting if heap guard is enabled. The latest Linux distribution with grub boot loader has no such issue. Normally it's not recommended to enable this feature in production build of BIOS. Note2: Don't enable this feature for NT32 emulation platform which doesn't support paging. Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Suggested-by: Ayellet Wolman <ayellet.wolman@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* MdeModulePkg/Core/Dxe: Add EndOfDxe workaround for NULL pointer detectionJian J Wang2017-10-111-0/+65
| | | | | | | | | | | | | | | | | | | | One of issue caused by enabling NULL pointer detection is that some PCI device OptionROM, binary drivers and binary OS boot loaders may have NULL pointer access bugs, which will prevent BIOS from booting and is almost impossible to fix. BIT7 of PCD PcdNullPointerDetectionPropertyMask is used as a workaround to indicate BIOS to disable NULL pointer detection right after event gEfiEndOfDxeEventGroupGuid, and then let boot continue. Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Ayellet Wolman <ayellet.wolman@intel.com> Suggested-by: Ayellet Wolman <ayellet.wolman@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> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* MdeModulePkg/MemoryProtection: Fix coding style issueDandan Bi2017-03-281-1/+1
| | | | | | | | Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Feng Tian <feng.tian@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
* MdeModulePkg/MemoryProtection: split protect and unprotect pathsArd Biesheuvel2017-03-211-50/+35
| | | | | | | | | | | | | | | | | | | Currently, the PE/COFF image memory protection code uses the same code paths for protecting and unprotecting an image. This is strange, since unprotecting an image involves a single call into the CPU arch protocol to clear the permission attributes of the entire range, and there is no need to parse the PE/COFF headers again. So let's store the ImageRecord entries in a linked list, so we can find it again at unprotect time, and simply clear the permissions. Note that this fixes a DEBUG hang on an ASSERT() that occurs when the PE/COFF image fails to load, which causes UnprotectUefiImage() to be invoked before the image is fully loaded. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* MdeModulePkg/Core/Dxe: downgrade "CodeSegmentCount is 0" msg to DEBUG_WARNLaszlo Ersek2017-03-201-2/+10
| | | | | | | | | | | | | | | | | | | UEFI executables that consist of a single read+write+exec PE/COFF section trigger this message, but such a binary layout isn't actually an error. The image can be launched alright, only image protection cannot be applied to it fully. One example that elicits the message is (some) Linux kernels (with the EFI stub of course). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Feng Tian <feng.tian@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* MdeModulePkg/DxeCore: Fix coding style issuesBi, Dandan2017-03-071-2/+4
| | | | | | | | | | Add comments for functions. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/DxeCore: switch to MdePkg allocation granularity macrosArd Biesheuvel2017-03-061-2/+2
| | | | | | | | | | Remove the local definitions for the default and runtime page allocation granularity macros, and switch to the new MdePkg versions. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdeModulePkg: use LShiftU64() instead of "<<" to avoid IA32 build error.Fu Siyuan2017-03-011-1/+1
| | | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/DxeCore: implement memory protection policyArd Biesheuvel2017-02-281-1/+370
| | | | | | | | | | | | | | | | | | | | | | | This implements a DXE memory protection policy that ensures that regions that don't require executable permissions are mapped with the non-exec attribute set. First of all, it iterates over all entries in the UEFI memory map, and removes executable permissions according to the configured DXE memory protection policy, as recorded in PcdDxeNxMemoryProtectionPolicy. Secondly, it sets or clears the non-executable attribute when allocating or freeing pages, both for page based or pool based allocations. Note that this complements the image protection facility, which applies strict permissions to BootServicesCode/RuntimeServicesCode regions when the section alignment allows it. The memory protection configured by this patch operates on non-code regions only. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdeModulePkg/DxeCore: base code protection on permission attributesArd Biesheuvel2017-02-261-1/+9
| | | | | | | | | | | | | Instead of assuming that a PE/COFF section of type EFI_IMAGE_SCN_CNT_CODE can always be mapped read-only, classify a section as a code section only if it has the executable attribute set and the writable attribute cleared. This adheres more closely to the PE/COFF spec, and avoids issues with Linux OS loaders that may consist of a single read/write/execute section. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* MdeModulePkg/DxeCore: Add UEFI image protection.Jiewen Yao2017-02-221-0/+769
If the UEFI image is page aligned, the image code section is set to read only and the image data section is set to non-executable. 1) This policy is applied for all UEFI image including boot service driver, runtime driver or application. 2) This policy is applied only if the UEFI image meets the page alignment requirement. 3) This policy is applied only if the Source UEFI image matches the PcdImageProtectionPolicy definition. 4) This policy is not applied to the non-PE image region. The DxeCore calls CpuArchProtocol->SetMemoryAttributes() to protect the image. If the CpuArch protocol is not installed yet, the DxeCore enqueues the protection request. Once the CpuArch is installed, the DxeCore dequeues the protection request and applies policy. Once the image is unloaded, the protection is removed automatically. The UEFI runtime image protection is teared down at ExitBootServices(), the runtime image code relocation need write code segment at SetVirtualAddressMap(). We cannot assume OS/Loader has taken over page table at that time. NOTE: It is per-requisite that code section and data section should not be not merged. That is same criteria for SMM/runtime driver. We are not able to detect during BIOS boot, because we can only get LINK warning below: "LINK : warning LNK4254: section '.data' (C0000040) merged into '.text' (60000020) with different attributes" But final attribute in PE code section is same. Cc: Star Zeng <star.zeng@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-08 14:22:33 +0000