summaryrefslogtreecommitdiffstats
path: root/MdeModulePkg/Core/Dxe
Commit message (Collapse)AuthorAgeFilesLines
* MdeModulePkg/Gcd: Suppress incorrect compiler/analyzer warningsStar Zeng2018-08-141-1/+5
| | | | | | | | | | | | | | | It is caused by 0c9f2cb10b7ddec56a3440e77219fd3ab1725e5c and false positive. Initialize CpuArchAttributes to suppress incorrect compiler/analyzer warnings. Cc: Dandan Bi <dandan.bi@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com> (cherry picked from commit e037e88cd81d4ac63dd627719c87c305bf0b439e)
* MdeModulePkg/Core: remove SMM check for Heap Guard feature detectionJian J Wang2018-07-271-10/+0
| | | | | | | | | | | | | | | | CpuDxe driver is updated to be able to access DXE page table in SMM mode, which means Heap Guard can get correct memory paging attributes in what environment. It's not necessary to exclude SMM from detecting Heap Guard feature support. Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> (cherry picked from commit 855abe0204cb932c8059a573a06a59ddc714ca49)
* MdeModulePkg/DxeCore: add sanity check for SetMemoryAttributesJian J Wang2018-07-271-2/+7
| | | | | | | | | | | | | | | | Heap Guard feature needs enough memory and paging to work. Otherwise calling SetMemoryAttributes to change page attribute will fail. This patch add necessary check of result of calling SetMemoryAttributes. This can help users to debug their problem in enabling this feature. Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> (cherry picked from commit a5cd613cdbf1edef1a98536fb2723b5d88bd53cd)
* MdeModulePkg/Gcd: Filter gCpu->SetMemoryAttributes() callsKinney, Michael D2018-07-271-3/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes an issue with VlvTbltDevicePkg introduced by commit 5b91bf82c67b586b9588cbe4bbffa1588f6b5926. The history is as below. To support heap guard feature, 14dde9e903bb9a719ebb8f3381da72b19509bc36 added support for SetMemorySpaceAttributes() to handle page attributes, but after that, a combination of CPU arch attributes and other attributes was not allowed anymore, for example, UC + RUNTIME. It is a regression. Then 5b91bf82c67b586b9588cbe4bbffa1588f6b5926 was to fix the regression, and we thought 0 CPU arch attributes may be used to clear CPU arch attributes, so 0 CPU arch attributes was allowed to be sent to gCpu->SetMemoryAttributes(). But some implementation of CPU driver may return error for 0 CPU arch attributes. That fails the case that caller just calls SetMemorySpaceAttributes() with none CPU arch attributes (for example, RUNTIME), and the purpose of the case is not to clear CPU arch attributes. This patch filters the call to gCpu->SetMemoryAttributes() if the requested attributes is 0. It also removes the #define INVALID_CPU_ARCH_ATTRIBUTES that is no longer used. Cc: Heyi Guo <heyi.guo@linaro.org> Cc: Yi Li <phoenix.liyi@huawei.com> Cc: Renhao Liang <liangrenhao@huawei.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> (cherry picked from commit 0c9f2cb10b7ddec56a3440e77219fd3ab1725e5c)
* MdeModulePkg/Gcd: Fix bug of attribute conversionHeyi Guo2018-07-271-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | For gDS->SetMemorySpaceAttributes(), when user passes a combined memory attribute including CPU arch attribute and other attributes, like EFI_MEMORY_RUNTIME, ConverToCpuArchAttributes() will return INVALID_CPU_ARCH_ATTRIBUTES and skip setting page/cache attribute for the specified memory space. We don't see any reason to forbid combining CPU arch attributes and non-CPU-arch attributes when calling gDS->SetMemorySpaceAttributes(), so we remove the check code in ConverToCpuArchAttributes(); the remaining code is enough to grab the interested bits for Cpu->SetMemoryAttributes(). Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Heyi Guo <heyi.guo@linaro.org> Signed-off-by: Yi Li <phoenix.liyi@huawei.com> Signed-off-by: Renhao Liang <liangrenhao@huawei.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> (cherry picked from commit 5b91bf82c67b586b9588cbe4bbffa1588f6b5926)
* MdeModulePkg/DxeCore: Not update RtCode in MemAttrTable after EndOfDxeJiewen Yao2018-07-261-0/+13
| | | | | | | | | | | | | | | We want to provide precise info in MemAttribTable to both OS and SMM, and SMM only gets the info at EndOfDxe. So we do not update RtCode entry in EndOfDxe. The impact is that if 3rd part OPROM is runtime, it cannot be executed at UEFI runtime phase. Currently, we do not see compatibility issue, because the only runtime OPROM we found before in UNDI, and UEFI OS will not use UNDI interface in OS. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
* MdeModulePkg/DxeCore: Install UEFI mem attrib table at EndOfDxe.Jiewen Yao2018-07-261-1/+35
| | | | | | | | So that the SMM can consume it to set page protection for the UEFI runtime page with EFI_MEMORY_RO attribute. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
* MdeModulePkg/DxeMain: Fix BSP interrupts reenabled in ExitBootServicesHao Wu2018-03-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Within function CoreExitBootServices(), this commit will move the call of: MemoryProtectionExitBootServicesCallback(); before: SaveAndSetDebugTimerInterrupt (FALSE); and gCpu->DisableInterrupt (gCpu); The reason is that, within MemoryProtectionExitBootServicesCallback(), APIs like RaiseTpl and RestoreTpl maybe called. An example will be: DebugLib (using PeiDxeDebugLibReportStatusCode instance) | v ReportStatusCodeLib (using DxeReportStatusCodeLib instance) | v Raise/RestoreTpl The call of Raise/RestoreTpl APIs will re-enable BSP interrupts. Hence, this commit refine the calling sequence to ensure BSP interrupts before leaving CoreExitBootServices(). Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> (cherry picked from commit bce776a5b695b5bf1f063f5417e48c56b43b88a7)
* MdeModulePkg/Core: fix bits operation error on a boundary conditionJian J Wang2018-03-161-6/+10
| | | | | | | | | | | | | | | | | If given address is on 64K boundary and the requested bit number is 64, all SetBits(), ClearBits() and GetBits() will encounter ASSERT problem in trying to do a 64 bits of shift, which is not allowed by LShift() and RShift(). This patch tries to fix this issue by turning bits operation into whole integer operation in such situation. Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> (cherry picked from commit 36f2f049a83d82f7c0c847202c9ce2974492c1ab)
* MdeModulePkg/Core: allow HeapGuard even before CpuArchProtocol installedJian J Wang2018-03-164-1/+154
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to the fact that HeapGuard needs CpuArchProtocol to update page attributes, the feature is normally enabled after CpuArchProtocol is installed. Since there're some drivers are loaded before CpuArchProtocl, they cannot make use HeapGuard feature to detect potential issues. This patch fixes above situation by updating the DXE core to skip the NULL check against global gCpu in the IsMemoryTypeToGuard(), and adding NULL check against gCpu in SetGuardPage() and UnsetGuardPage() to make sure that they can be called but do nothing. This will allow HeapGuard to record all guarded memory without setting the related Guard pages to not- present. Once the CpuArchProtocol is installed, a protocol notify will be called to complete the work of setting Guard pages to not-present. Please note that above changes will cause a #PF in GCD code during cleanup of map entries, which is initiated by CpuDxe driver to update real mtrr and paging attributes back to GCD. During that time, CpuDxe doesn't allow GCD to update memory attributes and then any Guard page cannot be unset. As a result, this will prevent Guarded memory from freeing during memory map cleanup. The solution is to avoid allocating guarded memory as memory map entries in GCD code. It's done by setting global mOnGuarding to TRUE before memory allocation and setting it back to FALSE afterwards in GCD function CoreAllocateGcdMapEntry(). Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> (cherry picked from commit 7fef06af4ec100f3f8856e3fa08ef067a9fd40d2)
* MdeModulePkg/Core: fix mem alloc issues in heap guardJian J Wang2018-03-141-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | There're two ASSERT issues which will be triggered by boot loader of Windows 10. The first is caused by allocating memory in heap guard during another memory allocation, which is not allowed in DXE core. Avoiding reentry of memory allocation has been considered in heap guard feature. But there's a hole in the code of function FindGuardedMemoryMap(). The fix is adding AllocMapUnit parameter in the condition of while(), which will prevent memory allocation from happenning during Guard page check operation. The second is caused by the core trying to allocate page 0 with Guard page, which will cause the start address rolling back to the end of supported system address. According to the requirement of heap guard, the fix is just simply skipping the free memory at page 0 and let the core continue searching free memory after it. 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> (cherry picked from commit dd12683e1f82a8d17fb6167ce4b3f6f3a1d10559)
* MdeModulePkg/Core: fix too many available pages between BS_DataJian J Wang2018-03-081-8/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The root cause is an unnecessary check to Size parameter in function AdjustMemoryS(). It will cause one standalone free page (happen to have Guard page around) in the free memory list cannot be allocated, even if the requested memory size is less than a page. // // At least one more page needed for Guard page. // if (Size < (SizeRequested + EFI_PAGES_TO_SIZE (1))) { return 0; } The following code in the same function actually covers above check implicitly. So the fix is simply removing above check. 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> (cherry picked from commit 8b13bca9b81490fc0e42df25d5feb82bbb47833e)
* MdeModulePkg/Core: Fix feature conflict between NX and Stack guardHao Wu2018-03-072-5/+61
| | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 7db1458f759c2e22ebb4c66bc61aa5dbae1e5fa1)
* 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> (cherry picked from commit a10acf0e207ed49cb3bcce14f3de172605df6ce7)
* MdeModulePkg/Core: fix feature conflict between NX and heap guardJian J Wang2018-02-023-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit a6a0a59756173148099d66638fcb4b3bca52434b)
* 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> (cherry picked from commit 9b17c6511d50db493c49324aaf81c50c3676a111)
* MdeModulePkg/Core: fix guard page missing issueJian J Wang2018-02-022-12/+11
| | | | | | | | | | | | | | | | | | | This issue is a regression one caused by a patch at 425d25699be83c35e12df8470b827d7fbcef3bce That fix didn't take the 0 page to free into account, which still needs to call UnsetGuardPage() even no memory needs to free. The fix is just moving the calling of UnsetGuardPage() to the place right after calling AdjustMemoryF(). 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: Ruiyu Ni <ruiyu.ni@intel.com> (cherry picked from commit 1263ecf2ffc9302663a304e7a6467c6e00cebf4a)
* MdeModulePkg/Core: fix a logic hole in page freeJian J Wang2018-01-223-36/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This hole will cause page fault randomly. The root cause is that Guard page, which is just freed back to page pool but not yet cleared not- present attribute, will be allocated right away by internal function CoreFreeMemoryMapStack(). The solution to this issue is to clear the not-present attribute for freed Guard page before doing any free operation, instead of after those operation. The reason we didn't do this before is due to the fact that manipulating page attributes might cause memory allocation action which would cause a dead lock inside a memory allocation/free operation. So we always set or unset Guard page outside the memory lock. After a thorough analysis, we believe clearing a Guard page will not cause memory allocation because memory we're to manipulate was already manipulated before for sure. Therefore there should be no memory allocation occurring in this situation. Since we cleared Guard page not-present attribute before freeing instead of after freeing, the debug code to clear freed memory can now be restored to its original way (aka no checking and bypassing Guard page). Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Eric Dong <eric.dong@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: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> (cherry picked from commit 425d25699be83c35e12df8470b827d7fbcef3bce)
* MdeModulePkg/Core: Fix heap guard issuesJian J Wang2017-12-262-8/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Fix incorrect memory map generated in a rare caseJian J Wang2017-12-191-2/+2
| | | | | | | | | | | | | | The root cause is that mImagePropertiesPrivateData.CodeSegmentCountMax was not updated with correct value due to the fact that SortImageRecord() called before might change the content of current ImageRecord. This will in turn cause incorrect memory map entries generated in SplitTable(). 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/DxeCore: Fix issues in Heap GuardJian J Wang2017-12-134-28/+88
| | | | | | | | | | | | | | | | | | | | | | | | | One issue is that macros defined in HeapGuard.h GUARD_HEAP_TYPE_PAGE GUARD_HEAP_TYPE_POOL doesn't match the definition of PCD PcdHeapGuardPropertyMask in MdeModulePkg.dec. This patch fixed it by exchanging the BIT0 and BIT1 of them. Another is that method AdjustMemoryF() will return a bigger NumberOfPages than the value passed in. This is caused by counting twice of a shared Guard page which can be used for both head and tail Guard of the memory before it and after it. This happens only when partially freeing just one page in the middle of a bunch of allocated pages. The freed page should be turned into a new Guard page. Cc: Jie Lin <jie.lin@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: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/Core/Dxe: Call new API InitializeCpuExceptionHandlersEx insteadJian J Wang2017-12-081-1/+1
| | | | | | | | | | | | | | | | | | | | | Original API InitializeCpuExceptionHandlers is used in DxeMain to initialize exception handlers but it does not support setting up stack switch required by Stack Guard feature. Using the new API instead to make sure Stack Guard feature is applicable to most part of code. Since this API is called before memory service initialization, there's no way to call AllocateXxx API to reserve memory. Global variables are used for this special case. GDT table is reserved at least 2KB which should be big enough for all current use cases. Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@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: Jeff Fan <vanjeff_919@hotmail.com> Reviewed-by: 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 DxeCore: Support USED_SIZE FV_EXT_TYPEStar Zeng2017-12-011-1/+83
| | | | | | | | | | | | | | | | The USED_SIZE FV_EXT_TYPE is introduced by PI 1.6 spec. The EFI_FIRMWARE_VOLUME_EXT_ENTRY_USED_SIZE_TYPE can be used to find out how many EFI_FVB2_ERASE_POLARITY bytes are at the end of the FV. When the FV gets shadowed into memory you only need to copy the used bytes into memory and fill the rest of the memory buffer with the erase value. Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdeModulePkg DxeCore: Check FvImage alignmentStar Zeng2017-12-011-13/+19
| | | | | | | | | | | | | No need to allocate aligned buffer if FvImage has been at required alignment. Then the code logic will be aligned with ProcessFvFile() in MdeModulePkg/Core/Pei/FwVol/FwVol.c. Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdeModulePkg/Core: Merge memory map after filtering paging capabilityJian J Wang2017-11-283-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | Once the paging capabilities were filtered out, there might be some adjacent entries sharing the same capabilities. It's recommended to merge those entries for the OS compatibility purpose. This patch makes use of existing method MergeMemoryMap() to do it. This is done by simply turning this method from static to extern, and call it after filter code. This patch is related to an issue described at https://bugzilla.tianocore.org/show_bug.cgi?id=753 This patch is also passed test of booting follow OSs: Windows 10 Windows Server 2016 Fedora 26 Fedora 25 Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Star Zeng <star.zeng@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> Acked-by: Laszlo Ersek <lersek@redhat.com>
* MdeModulePkg/DxeCore: Filter out all paging capabilitiesJian J Wang2017-11-241-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really set attributes and change memory paging attribute accordingly. But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by value from Capabilities in GCD memory map. This might cause boot problems. Clearing all paging related capabilities can workaround it. The code added in this patch is supposed to be removed once the usage of EFI_MEMORY_DESCRIPTOR.Attribute is clarified in UEFI spec and adopted by both EDK-II Core and all supported OSs. Laszlo did a thorough test on OVMF emulated platform. The details can be found at https://bugzilla.tianocore.org/show_bug.cgi?id=753#c10 Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* MdeModulePkg/Core: Fix potential array overflowJian J Wang2017-11-241-1/+3
| | | | | | | | | | | | | | | In the method DumpGuardedMemoryBitmap() and SetAllGuardPages(), the code didn't check if the global mMapLevel is legal value or not, which leaves a logic hole causing potential array overflow in code followed. This patch adds sanity check before any array reference in those methods. 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: Wu Hao <hao.a.wu@intel.com>
* MdeModulePkg/Core: Add missing header files into infJian J Wang2017-11-241-0/+1
| | | | | | | | | | | | The coding style requires that header files must be also added in module's inf file, as long as they're included by c files. This patch will fix this issue. Cc: Dandan Bi <dandan.bi@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: Dandan Bi <dandan.bi@intel.com>
* MdeModulePkg: Fix unix style of EOLJian J Wang2017-11-217-1859/+1859
| | | | | | | | | 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/Core: Fix build error with old Visual StudioJian J Wang2017-11-201-4/+9
| | | | | | | | | | | | | | | | | | The build error is introduced by following check in: 2930ef9809976ce693d1d377851344c3b06bd926 235a4490c8ce8b6dbac49e6ae3559cb73d6bf620 The Visual Studio older than 2015 doesn't support constant integer in binary format (0bxxx). This patch changes them to BIT macro to fix it. This patch also cleans up coding style about unmatched comment for return value. Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Bi Dandan <dandan.bi@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/DxeCore: Implement heap guard feature for UEFIJian J Wang2017-11-177-67/+1854
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Remove extra connects for UEFI ApplicationsMichael D Kinney2017-11-131-2/+10
| | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=765 The UEFI Specification Boot Services chapter, StartImage() service, EFF 1.10 Extension requires extra calls to ConnectController() if a UEFI Driver produces handles. The DXE Core is performing these extra calls to ConnectController() without evaluating the ImageType. A filter is added to not make extra calls to ConnectController() if the ImageType is EFI_IMAGE_SUBSYSTEM_EFI_APPLICATION. Without this filter, extra calls to ConnectController() may be performed by UEFI Applications or a UEFI Shell Applications that also call ConnectController(). Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/Core/Dxe: Add EndOfDxe workaround for NULL pointer detectionJian J Wang2017-10-113-1/+69
| | | | | | | | | | | | | | | | | | | | 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 Core: Propagate PEI-phase FV authentication status to DXEStar Zeng2017-10-103-17/+60
| | | | | | | | | | | | | FV3 HOB was introduced by new (>= 1.5) PI spec, it is intended to be used to propagate PEI-phase FV authentication status to DXE. This patch is to update PeiCore to build FV3 HOB with the authentication status and DxeCore to get the authentication status from FV3 HOB when producing FVB Protocol. Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdeModulePkg: Update Ppi/Protocol/Guid usage in INF filesLiming Gao2017-10-101-1/+1
| | | | | | | | Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg: Update DxeCore to consume PI EfiGcdMemoryTypePersistentLiming Gao2017-10-102-4/+4
| | | | | | Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/DxeCore: Add comments for the ASSERT to check NULL ptrHao Wu2017-10-091-1/+9
| | | | | | | | | | | | | | | | | Commit 8932679df5be046feba30fae80776c5815232a08 adds an ASSERT for checking NULL pointer dereference. The ASSERT added here is for addressing a false positive NULL pointer dereference issue raised from static analysis. This commit adds comments to clarify the reason for using ASSERT as the check. Cc: Star Zeng <star.zeng@intel.com> Cc: Michael D Kinney <michael.d.kinney@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>
* MdeModulePkg/Tpl: Fix negative value left shiftHao Wu2017-09-291-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=695 Within function CoreRestoreTpl(), left shift a negative value -2 is used in: "while (((-2 << NewTpl) & gEventPending) != 0) {" which involves undefined behavior. According to the C11 spec, Section 6.5.7: > 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated > bits are filled with zeros. If E1 has an unsigned type, the value > of the result is E1 * 2^E2 , reduced modulo one more than the > maximum value representable in the result type. If E1 has a signed > type and nonnegative value, and E1 * 2^E2 is representable in the > result type, then that is the resulting value; otherwise, the > behavior is undefined. This commit refines the code logic to avoid left shifting the negative value. Cc: Steven Shi <steven.shi@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg Core: Support FFS_ATTRIB_DATA_ALIGNMENT_2Star Zeng2017-09-261-12/+25
| | | | | | | | | | Follow PI 1.6 spec to support FFS_ATTRIB_DATA_ALIGNMENT_2 for FFS alignment extended to support maximum 16MB. Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdeModulePkg/DxeCore: Add check to ensure no possible NULL ptr derefHao Wu2017-09-261-0/+1
| | | | | | Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/DxeCore: Fixed Interface returned by CoreOpenProtocolAmit Kumar2017-09-221-13/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change since v4: Revise the patch based on V4 sent by Amit Kumar 1) Only return the corresponding protocol interface in *Interface if the return status is EFI_SUCCESS or EFI_ALREADY_STARTED. 2) Interface is returned unmodified for all error conditions except EFI_UNSUPPORTED and EFI_ALREADY_STARTED, NULL will be returned in *Interface when EFI_UNSUPPORTED and Attributes is not EFI_OPEN_PROTOCOL_TEST_PROTOCOL, the protocol interface will be returned in *Interface when EFI_ALREADY_STARTED. Change since v3: 1) Fixed issue when Attributes = EFI_OPEN_PROTOCOL_TEST_PROTOCOL and Inteface = NULL case. [Reported by:star.zeng at intel.com] Change Since v2: 1) Modified to use EFI_ERROR to get status code Change since v1: 1) Fixed typo protocal to protocol 2) Fixed coding style Cc: Laszlo Ersek <lersek@redhat.com> Cc: Amit Kumar <amit.ak@samsung.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Gabriel Somlo <gsomlo@gmail.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Amit Kumar <amit.ak@samsung.com> Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gabriel Somlo <gsomlo@gmail.com>
* MdeModulePkg/Core: Fix out-of-sync issue in GCDJian J Wang2017-09-211-18/+27
| | | | | | | | | | | | | | | | | | From GCD perspective, its SetMemorySpaceAttributes() method doesn't accept page related attributes. That means users cannot use it to change page attributes, and have to turn to CPU arch protocol to do it, which is not be allowed by PI spec. Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Suggested-by: 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> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg DxeCore: Enhance "ConvertPages: Incompatible memory types"Star Zeng2017-08-141-2/+7
| | | | | | | | | | | | | | | | | | | | When double free pages by FreePages() or allocate allocated pages by AllocatePages() with AllocateAddress type, the code will print debug message "ConvertPages: Incompatible memory types", but the debug message is not very obvious for the error paths by FreePages() or AllocatePages(). Refer https://lists.01.org/pipermail/edk2-devel/2017-August/013075.html for the discussion. This patch is to enhance the debug message for the error paths by FreePages() or AllocatePages. Cc: Liming Gao <liming.gao@intel.com> Cc: Andrew Fish <afish@apple.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdeModulePkg DxeCore: Fix double free pages on LoadImage failure pathStar Zeng2017-08-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=667 reported there is double free pages on LoadImage failure path. CoreLoadPeImage() ... return EFI_SUCCESS; Done: // // Free memory. // if (DstBufAlocated) { CoreFreePages (Image->ImageContext.ImageAddress, Image->NumberOfPages); } ... CoreUnloadAndCloseImage() ... if ((Image->ImageBasePage != 0) && FreePage) { CoreFreePages (Image->ImageBasePage, Image->NumberOfPages); } ... This patch is to follow the suggestion at https://lists.01.org/pipermail/edk2-devel/2017-August/013112.html to set Image->ImageContext.ImageAddress and Image->ImageBasePage to 0 after the free in CoreLoadPeImage(). Cc: Liming Gao <liming.gao@intel.com> Cc: Andrew Fish <afish@apple.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdeModulePkg/DxeCore: Avoid accessing non-owned memoryRuiyu Ni2017-07-181-27/+27
| | | | | | | | | | | | | | | | | | | | The patch fixes two kinds of bugs in DxeCore that accesses memory which might be freed or owned by other modules. The two bugs don't cause functionality issue. 1. CoreValidateHandle() checks whether the handle is valid by validating its signature. The proper way is to check whether the handle is in the handle database. 2. CoreDisconnectControllersUsingProtocolInterface() and CoreOpenProtocol() de-reference Link pointer which is already freed. The proper way is to not de-reference the pointer. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com>
* Revert "MdeModulePkg/DxeCore: Fixed Interface returned by CoreOpenProtocol"Star Zeng2017-06-271-14/+12
| | | | | | | | | | | | This reverts commit 45cfcd8dccf84b8abbc1d6f587fedb5d2037ec79 since it is breaking OVMF platform and also real platforms. REF: https://www.mail-archive.com/edk2-devel@lists.01.org/msg26882.html https://www.mail-archive.com/edk2-devel@lists.01.org/msg26820.html Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg DxeCore: Only free ScratchBuffer when it is not NULLStar Zeng2017-06-261-2/+4
| | | | | | | | | | | | | | There is a case that ExtractGuidedSectionGetInfo return 0 for ScratchBufferSize and ScratchBuffer will be NULL, after AllocatePool fails to allocate buffer for AllocatedOutputBuffer, the code will call FreePool (ScratchBuffer), but ScratchBuffer == NULL. This patch is to only free ScratchBuffer when it is not NULL. Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdeModulePkg/DxeCore: Fixed Interface returned by CoreOpenProtocolAmit Kumar2017-06-261-12/+14
| | | | | | | | | | | | | | | | | | | | | | | Change since v3: 1) Fixed issue when Attributes = EFI_OPEN_PROTOCOL_TEST_PROTOCOL and Inteface = NULL case. [Reported by:star.zeng at intel.com] Change Since v2: 1) Modified to use EFI_ERROR to get status code Change since v1: 1) Fixed typo protocal to protocol 2) Fixed coding style Modified source code to update Interface as per spec. 1) In case of Protocol is un-supported, interface should be returned NULL. 2) In case of any error, interface should not be modified. 3) In case of Test Protocol, interface is optional. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Amit Kumar <amit.ak@samsung.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg: Enhance the debug message for InstallProtocolInterfaceStar Zeng2017-06-231-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | Current code is using debug message like below for InstallProtocolInterface. InstallProtocolInterface: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX XXX User could not know whether the installation is failed or not by the debug message, for example, the code below does not initialize Handle before calling InstallProtocolInterface, EFI_INVALID_PARAMETER will be returned. EFI_HANDLE Handle; Status = gBS->InstallProtocolInterface ( &Handle, &XXX, EFI_NATIVE_INTERFACE, XXX ); This patch is to add additional debug message if the installation is failed and specific debug message for the case that the input handle is invalid. Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-06 22:08:24 +0000