From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 165378216A for ; Thu, 23 Feb 2017 00:52:32 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2017 00:52:31 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,197,1484035200"; d="scan'208,217";a="1133766836" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga002.fm.intel.com with ESMTP; 23 Feb 2017 00:52:31 -0800 Received: from fmsmsx152.amr.corp.intel.com (10.18.125.5) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 23 Feb 2017 00:52:30 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX152.amr.corp.intel.com (10.18.125.5) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 23 Feb 2017 00:52:30 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.132]) with mapi id 14.03.0248.002; Thu, 23 Feb 2017 16:52:28 +0800 From: "Yao, Jiewen" To: Ard Biesheuvel , "edk2-devel@lists.01.org" , "afish@apple.com" , "leif.lindholm@linaro.org" , "Kinney, Michael D" , "Gao, Liming" CC: "lersek@redhat.com" , "Tian, Feng" , "Zeng, Star" , "Yao, Jiewen" Thread-Topic: [RFC PATCH 0/4] RFC: increased memory protection Thread-Index: AQHSjTkEaCACEY6LEUajcJ05Gp2qNKF2QSIA Date: Thu, 23 Feb 2017 08:52:27 +0000 Message-ID: <74D8A39837DF1E4DA445A8C0B3885C503A8F4220@shsmsx102.ccr.corp.intel.com> References: <1487787898-5222-1-git-send-email-ard.biesheuvel@linaro.org> In-Reply-To: <1487787898-5222-1-git-send-email-ard.biesheuvel@linaro.org> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [RFC PATCH 0/4] RFC: increased memory protection X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 08:52:32 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI Ard Thanks to protect more. :-) We did consider the idea to remove EXEC attribute for Data page before. But= we got compatibility issue. We documented some gaps in white paper - https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyon= d_BIOS_Memory_Map_And_Practices_in_UEFI_BIOS_V2.pdf I am glad that some limitation is already resolved or we have solution to m= itigate it. But there is still some other need consideration. 1) We observe some 3rd part code allocating data page for code. - That= is hardest part. (OS limitation #12) We might also need consider ReservedMemory/AcpiNvs. There might be code the= re, too. (Firmware limitation #6 and #7). If we want to apply the protection, we might need define a new PCD to disab= le the data protection for compatibility consideration. 2) About DxeCore in data page. (Firmware limitation #4) I am thinking if we can fix LoadFile implementation in PeiCore. MdeModulePkg\Core\Pei\Image\Image.c: LoadAndRelocatePeCoffImage() { ImageContext.ImageAddress =3D (EFI_PHYSICAL_ADDRESS)(UINTN) AllocatePages (= EFI_SIZE_TO_PAGES ((UINT32) AlignImageSize)); } AllocatePages means to allocate data page. I think we should use PeiAllocatePages(EfiBootServicesCode, EFI_SIZE_TO_PAG= ES ((UINT32) AlignImageSize), &ImageContext.ImageAddress); Does that fix the problem? 3) I am not worried about EBC. That can be handled separately. 4) I did not find patch 4/4 in my mail box. Maybe it is lost due to so= me unknown reason. Would you please send it again? Thank you Yao Jiewen > -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > Sent: Thursday, February 23, 2017 2:25 AM > To: edk2-devel@lists.01.org; afish@apple.com; leif.lindholm@linaro.org; K= inney, > Michael D ; Gao, Liming ; > Yao, Jiewen > Cc: lersek@redhat.com; Tian, Feng ; Zeng, Star > ; Ard Biesheuvel > Subject: [RFC PATCH 0/4] RFC: increased memory protection > > Hello all, > > This is a proof of concept implementation that removes all executable > permissions from writable memory regions, which greatly enhances security= . > It is based on Jiewen's recent work, which is a step in the right directi= on, > but still leaves most of memory exploitable due to the default R+W+X > permissions. > > The idea is that the implementation of the CPU arch protocol goes over th= e > memory map and removes exec permissions from all regions that are not alr= eady > marked as 'code. This requires some preparatory work to ensure that the > DxeCore > itself is covered by a BootServicesCode region, not a BootServicesData re= gion. > Exec permissions are re-granted selectively, when the PE/COFF loader allo= cates > the space for it. Combined with Jiewen's code/data split, this removes al= l > RWX mapped regions. > > There is a caveat, though (and there are likely more of that kind): the E= BC > driver will need some work to ensure the thunk buffers have the noexec > restriction lifted. This could be done in the EBC driver, but perhaps it = is > better to either > a) modify the DXE core so it always removes noexec restrictions when allo= cating > code pages, or > b) add AllocateExecPages/AllocateExecPool() functions to the > MemoryAllocationLib > API > > Comments please! > > Ard Biesheuvel (4): > MdeModulePkg/DxeCore: allow BootServicesData->BootServicesCode > conversion > MdeModulePkg/DxeCore: convert the DxeCore memory region to > BootServicesCode > MdeModulePkg/DxeCore: lift non-exec permissions on loaded images > ArmPkg/CpuDxe: remap all data regions non-executable > > ArmPkg/Drivers/CpuDxe/CpuDxe.c | 76 ++++++++++++++++++++ > MdeModulePkg/Core/Dxe/DxeMain.h | 8 +++ > MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 2 + > MdeModulePkg/Core/Dxe/Image/Image.c | 8 +++ > MdeModulePkg/Core/Dxe/Mem/Page.c | 18 ++++- > 5 files changed, 111 insertions(+), 1 deletion(-) > > -- > 2.7.4