From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.136; helo=mga12.intel.com; envelope-from=jian.j.wang@intel.com; receiver=edk2-devel@lists.01.org Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3663822492750 for ; Mon, 12 Mar 2018 19:28:34 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Mar 2018 19:34:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,463,1515484800"; d="scan'208";a="38224896" Received: from jwang36-mobl2.ccr.corp.intel.com ([10.239.192.32]) by orsmga001.jf.intel.com with ESMTP; 12 Mar 2018 19:34:53 -0700 From: Jian J Wang To: edk2-devel@lists.01.org Cc: Star Zeng , Eric Dong , Jiewen Yao Date: Tue, 13 Mar 2018 10:34:50 +0800 Message-Id: <20180313023450.18336-1-jian.j.wang@intel.com> X-Mailer: git-send-email 2.15.1.windows.2 Subject: [PATCH] MdeModulePkg/Core: fix mem alloc issues in heap guard X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 02:28:34 -0000 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 Cc: Eric Dong Cc: Jiewen Yao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang --- MdeModulePkg/Core/Dxe/Mem/HeapGuard.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c index 19245049c2..ac043b5d9b 100644 --- a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c +++ b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c @@ -225,8 +225,8 @@ FindGuardedMemoryMap ( // // Adjust current map table depth according to the address to access // - while (mMapLevel < GUARDED_HEAP_MAP_TABLE_DEPTH - && + while (AllocMapUnit && + mMapLevel < GUARDED_HEAP_MAP_TABLE_DEPTH && RShiftU64 ( Address, mLevelShift[GUARDED_HEAP_MAP_TABLE_DEPTH - mMapLevel - 1] @@ -904,6 +904,10 @@ AdjustMemoryS ( } Target = Start + Size - SizeRequested; + ASSERT (Target >= Start); + if (Target == 0) { + return 0; + } if (!IsGuardPage (Start + Size)) { // No Guard at tail to share. One more page is needed. -- 2.16.2.windows.1