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.115; helo=mga14.intel.com; envelope-from=ruiyu.ni@intel.com; receiver=edk2-devel@lists.01.org Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (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 56B192194D387 for ; Tue, 11 Sep 2018 02:12:41 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2018 02:12:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,359,1531810800"; d="scan'208";a="82538792" Received: from ray-dev.ccr.corp.intel.com (HELO [10.239.9.8]) ([10.239.9.8]) by orsmga003.jf.intel.com with ESMTP; 11 Sep 2018 02:12:40 -0700 To: edk2-devel@lists.01.org References: <20180911051636.4888-1-jian.j.wang@intel.com> From: "Ni, Ruiyu" Message-ID: <599615e1-130a-79cb-467f-4afce7c13bda@Intel.com> Date: Tue, 11 Sep 2018 17:13:31 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Subject: Re: [PATCH 0/5] expire the use of PcdSetNxForStack X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 09:12:41 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 9/11/2018 4:57 PM, Ard Biesheuvel wrote: > On 11 September 2018 at 07:16, Jian J Wang wrote: >> BZ#: https://bugzilla.tianocore.org/show_bug.cgi?id=1116 >> >> Since the stack memory is allocated as EfiBootServicesData, its NX protection >> can be covered by BIT4 of PcdDxeNxMemoryProtectionPolicy. To avoid confusing >> in setting related PCDs, PcdSetNxForStack will be expired. Instead, If BIT4 >> of PcdDxeNxMemoryProtectionPolicy is set, the DxeIpl will set NX bit in page >> table entries mapping the stack memory. >> > > I disagree. This removes the possibility to map EfiBootServicesData as > executable while still mapping the stack NX. As we all know, an > executable stack is in a class of its own when it comes to > exploitability, and should *never* be mapped executable unless in > highly exceptional cases. Mapping all EfiBootServicesData as > non-executable may cause backward compatibility problems. Ard, Are you saying you want the capability of setting certain range of BS data as executable? Why does ARM need such capability? > > In particular, this makes it impossible for AArch64 to populate the > 1:1 mapping using 64k pages (which is necessary for 52-bit address > support) and still have a non-executable stack, since > PcdDxeNxMemoryProtectionPolicy is disabled in that scenario. > > So please disregard these patches. > > >> Jian J Wang (5): >> MdeModulePkg/DxeIplPeim: expire the use of PcdSetNxForStack >> OvmfPkg/PlatformPei: expire the use of PcdSetNxForStack >> OvmfPkg: expire the use of PcdSetNxForStack >> ArmVirtPkg/ArmVirt.dsc.inc: expire the use of PcdSetNxForStack >> MdeModulePkg: expire PcdSetNxForStack >> >> ArmVirtPkg/ArmVirt.dsc.inc | 5 ----- >> MdeModulePkg/Core/DxeIplPeim/Arm/DxeLoadFunc.c | 6 +++++- >> MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf | 2 +- >> MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c | 3 ++- >> MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c | 2 +- >> MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 14 +++++++++++--- >> MdeModulePkg/MdeModulePkg.dec | 10 +--------- >> MdeModulePkg/MdeModulePkg.uni | 10 +--------- >> OvmfPkg/OvmfPkgIa32.dsc | 1 - >> OvmfPkg/OvmfPkgIa32X64.dsc | 1 - >> OvmfPkg/OvmfPkgX64.dsc | 1 - >> OvmfPkg/PlatformPei/Platform.c | 1 - >> OvmfPkg/PlatformPei/PlatformPei.inf | 1 - >> 13 files changed, 22 insertions(+), 35 deletions(-) >> >> -- >> 2.16.2.windows.1 >> >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > -- Thanks, Ray