From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 EDC9E81F53 for ; Thu, 9 Feb 2017 08:30:51 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id j18so20951567ioe.2 for ; Thu, 09 Feb 2017 08:30:51 -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=bdCToxg3+pOccT5NYMlqGGh2UnfwbOks5yfww3MUq+I=; b=KWKfyQrOhHYy3+zveteTNV3BM/J+O8+y944k1YWQz17iB4xBTHDwLbINX/WumXDtNu lm8w1RDlYMMc94dSyQEEZyl9vmRrPStXHBOueVoH0uxz6Jiu1JAd2YRkMw5Mvb11fdvY UzW4n6aaNJsr0veIj5Qk09xil1GdnP50NwySE= 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=bdCToxg3+pOccT5NYMlqGGh2UnfwbOks5yfww3MUq+I=; b=VUD8XfP2iqIZzAocgyAW4JUuqvSz6OusobqpkuyqnDZYlf0yG1MyQsjK0+9jRNf/1f N0IaXw9mn2BpbGeye3MoG88T+YhTLaabyOlG1f+X2vUhlzpwFbRRyvpfsgaKvetVCY9x FSj4wRS7VLkJW0ovkERW8uLz4ZPr+g+vkCrKKdj1wEdjCNdqQZpqQ679EWfXOH87eJTQ XdC3gJNHK9/U0QnzUE40Ac45CxNsfuLxA4VJaN1w5fRff3UAiU6RF3UIVZIXxc+ko8P2 vBXfbxHDWPX+Q0m4/Mu77H5AkP3L0CMOjiI28JKi3Z34RIqPAPkZnlEyHA7HFo2TK6Or WO6w== X-Gm-Message-State: AMke39llgPm5uIeTFydO061pVjsGmY5qj8xcSs1rKMq2g7iJPsqXvuOtxORc20GtsgAwpy2moEfnKOJEpi/+XnCc X-Received: by 10.107.53.17 with SMTP id c17mr3754120ioa.45.1486657851326; Thu, 09 Feb 2017 08:30:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.144.139 with HTTP; Thu, 9 Feb 2017 08:30:50 -0800 (PST) In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503A8EC093@shsmsx102.ccr.corp.intel.com> References: <1486624832-15736-1-git-send-email-jiewen.yao@intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A8EBD52@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A8EBEC3@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A8EBF20@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A8EC023@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A8EC093@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Thu, 9 Feb 2017 16:30:50 +0000 Message-ID: To: "Yao, Jiewen" Cc: "Tian, Feng" , "edk2-devel@lists.01.org" , Leif Lindholm , "Kinney, Michael D" , "Fan, Jeff" , "Zeng, Star" Subject: Re: [PATCH V3 0/4] DXE 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, 09 Feb 2017 16:30:52 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 9 February 2017 at 16:29, Yao, Jiewen wrote: > Very good point. > > Can ARCH64 set 4K paging for 64K aligned runtime memory? > UEFI always uses 4 KB, but the OS may use 64 KB, so to create the virtual address map it needs the runtime regions to be 64 KB aligned. > > > If yes, how about we use > > =E2=80=9CImageRecord->ImageSize =3D ALIGN_VALUE(LoadedImage->ImageSize, > EFI_PAGE_SIZE);=E2=80=9D > Perfect, thanks. > > > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > Sent: Thursday, February 9, 2017 8:21 AM > To: Yao, Jiewen > Cc: Tian, Feng ; edk2-devel@lists.01.org; Leif Lindh= olm > ; Kinney, Michael D ; > Fan, Jeff ; Zeng, Star > Subject: Re: [edk2] [PATCH V3 0/4] DXE Memory Protection > > > > On 9 February 2017 at 15:28, Ard Biesheuvel > wrote: > > >> On 9 February 2017 at 15:27, Yao, Jiewen wrote: >>> 1) That is great. I appreciate your quick response and help. >>> >>> I will drop my patch for ARM 2/4, and wait for yours. >>> >> >> OK >> >>> >>> >>> 2) For ImageEnd alignment issue, I agree with you. >>> >>> I plan to round up with: >>> >>> ImageRecord->ImageSize =3D ALIGN_VALUE(LoadedImage->ImageSize, >>> SectionAlignment); >>> >>> before SetUefiImageProtectionAttributes (ImageRecord, Protect); >>> >> >> Great, that should fix my issue! >> > > Actually, does that still work correctly with 64 KB section alignment? > I don't think the PE/COFF loader rounds up the allocation to section > alignment, does it?