From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.126; helo=mga18.intel.com; envelope-from=ruiyu.ni@intel.com; receiver=edk2-devel@lists.01.org Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) (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 AEC6E21128700 for ; Tue, 11 Sep 2018 17:55:16 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2018 17:55:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,362,1531810800"; d="scan'208";a="70141256" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga008.fm.intel.com with ESMTP; 11 Sep 2018 17:55:15 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 11 Sep 2018 17:55:15 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.143]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.205]) with mapi id 14.03.0319.002; Wed, 12 Sep 2018 08:55:12 +0800 From: "Ni, Ruiyu" To: Ard Biesheuvel CC: "edk2-devel@lists.01.org" Thread-Topic: [edk2] [PATCH 0/5] expire the use of PcdSetNxForStack Thread-Index: AQHUSY6zabo8V5kPr02nhC9w72QSpKTqQcwAgACKgYCAAEAAgIAAxKtw Date: Wed, 12 Sep 2018 00:55:12 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5BE03AED@SHSMSX104.ccr.corp.intel.com> References: <20180911051636.4888-1-jian.j.wang@intel.com> <599615e1-130a-79cb-467f-4afce7c13bda@Intel.com> In-Reply-To: Accept-Language: en-US, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzIyYTQ0NjktZTNiOS00MTM2LTllMWUtNmFjMjVlOWE1YThjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoib0VLc0xvamk3MlV2UDQzVTZDMG1hZkpicWZWdGJLOWdRUjJGdGVURGh6Sm1rcERSZlV3NnNmazE5cXhDbFFcL1YifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 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: Wed, 12 Sep 2018 00:55:16 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ar= d > Biesheuvel > Sent: Wednesday, September 12, 2018 5:03 AM > To: Ni, Ruiyu > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH 0/5] expire the use of PcdSetNxForStack >=20 > On 11 September 2018 at 11:13, Ni, Ruiyu wrote: > > On 9/11/2018 4:57 PM, Ard Biesheuvel wrote: > >> > >> On 11 September 2018 at 07:16, Jian J Wang wro= te: > >>> > >>> BZ#: https://bugzilla.tianocore.org/show_bug.cgi?id=3D1116 > >>> > >>> 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? > > >=20 > No, I am saying that mapping all BS data executable should be a separate > decision from mapping the stack executable: if your platform cannot suppo= rt the > former (for historical reasons) you will likely still want the latter. Let me try to understand the specific problem in ARM64: ARM64 uses 64KB page size to support 2^52 memory space. With 4KB page size, it can only support 2^48 memory space. But due to the DXE core AllocatePages() implementation, the hard-code 4KB g= ranularity (defined by UEFI spec) causes the page table protection for BS_DATA/BS_CODE= is impossible. So ARM64 chooses to disable the BS_DATA/BS_CODE protection, but only enable the stack protection. Correct? If so, is changing spec to allow page-size platform configurable a better o= ption? > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel