From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 0A5B982171 for ; Thu, 23 Feb 2017 03:39:18 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id 203so171680184ith.0 for ; Thu, 23 Feb 2017 03:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QX39J/v2J2UA7v44LWSGGc83furO7MvewjwXOsmokbQ=; b=HHlM1etb4czuNYtog9c+nae5qnY0OZTNzPS3rfzBh1SqFZq9NIrKhOpN1Oen8X6geF /BKgE4sT2OjF7KwlCZ3RXYuCJNMh/tb14wEB4EOwVhgvCsZkmB7tNiCc+2DY7AjiYLQU +Unm5opx5pvgx/IRiNll1Hq+VRnNHNKQV0idQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QX39J/v2J2UA7v44LWSGGc83furO7MvewjwXOsmokbQ=; b=Yc58CsBe0nFL2sFMjV1lYBi9lkme7rAWtuMvddmJHaPhR1pdPDVo2BYT6Gv601WEIL Lt/G5HbMvUoY6VAQ2TmS0frUh+Kbh1X52NvfcRxpjHL/vM2F4UbfqoISxCydgaAFsFJo AeY4QWzLhtsJfaAl6BxP4Zc9ke6Ujf27KWhAqg/zEuC3ZQ3UjDliTqgld6h9xvZ3HOT3 40Ezga1dx0VeTRDnxum3xcwRx+mGdSftL2FyyBtljDQDwxDoveMKQDO0qTYb+NjH0NxY Cbx61X9LgOvBoSA2kh7KhcGW7zrVe5f+uq6mRuwzdEXxOu8mrfbtiP6/JbmvJHuK+yAa MfMA== X-Gm-Message-State: AMke39kGLbM3DZl0t0uN5U+YZuJzRmTn5B3lUWnQWRPc4OH6QfABZ+WzYR5VIqw+i7gymRAvvx6BwAt+6QCuUuDa X-Received: by 10.107.13.130 with SMTP id 124mr18581185ion.83.1487849957345; Thu, 23 Feb 2017 03:39:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.198.134 with HTTP; Thu, 23 Feb 2017 03:39:16 -0800 (PST) In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503A8F4220@shsmsx102.ccr.corp.intel.com> References: <1487787898-5222-1-git-send-email-ard.biesheuvel@linaro.org> <74D8A39837DF1E4DA445A8C0B3885C503A8F4220@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Thu, 23 Feb 2017 11:39:16 +0000 Message-ID: To: "Yao, Jiewen" Cc: "edk2-devel@lists.01.org" , "afish@apple.com" , "leif.lindholm@linaro.org" , "Kinney, Michael D" , "Gao, Liming" , "lersek@redhat.com" , "Tian, Feng" , "Zeng, Star" 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 11:39:18 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 23 February 2017 at 08:52, Yao, Jiewen wrote: > HI Ard > > Thanks to protect more. :-) > Of course! This is a very important topic for me. > We did consider the idea to remove EXEC attribute for Data page before. B= ut > we got compatibility issue. > > > > We documented some gaps in white paper - > > https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Bey= ond_BIOS_Memory_Map_And_Practices_in_UEFI_BIOS_V2.pdf > Thanks for the link. > I am glad that some limitation is already resolved or we have solution to > mitigate it. But there is still some other need consideration. > > > > 1) We observe some 3rd part code allocating data page for code. =E2= =80=93 That > is hardest part. (OS limitation #12) > > We might also need consider ReservedMemory/AcpiNvs. There might be code > there, too. (Firmware limitation #6 and #7). > OK > If we want to apply the protection, we might need define a new PCD to > disable 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_PAGES ((UINT32) AlignImageSize), &ImageContext.ImageAddress); > > > > Does that fix the problem? > Using PeiServicesAllocatePage() in the way that you describe does indeed remove the problem, so I will use that instead. > 3) I am not worried about EBC. That can be handled separately. > OK > 4) I did not find patch 4/4 in my mail box. Maybe it is lost due to > some unknown reason. Would you please send it again? > https://lists.01.org/pipermail/edk2-devel/2017-February/007685.html I will send out a v2 shortly which, as you suggest, moves the handling to DXE core. The only problem is that ARM's SyncCacheConfig() removes the noexec attributes again, so I need to fix that first. Then, the arch CPU protocol installation event can iterate over the memory map to set the permissions according to a policy PCD Thanks, Ard.