From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 308CE81F39 for ; Fri, 10 Feb 2017 03:42:45 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id v77so45779230wmv.0 for ; Fri, 10 Feb 2017 03:42:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wRyBAL2VMcSZsMw7lzfCsoPYPVmLiS3HAAmDKaVoGtE=; b=d/oZPXFUDkOBqikM6Kf2LsdA4auPLyhSmwu6UBl8IzWrvy1wGz4MddyPPHdXxXUmkt /V9mDtgNYZD0Pex3gULsukVp75IKy9N/G4fnVfbj0owBnDkjWFAHz4i48RiJzteqeWHu 1HggXl/be/xo8CPO8c5RdYbvoyXAcNv0Hd2l4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wRyBAL2VMcSZsMw7lzfCsoPYPVmLiS3HAAmDKaVoGtE=; b=oGMh0/Qcav4OhxGNcu7Ak3owxJ9XDK6Gvk6nZiKommeeZK/tw0467RfiyruEk9D5Eo HpQUHElsaYlTv8glczxvtawGqzWSVxvH9DUe91CENcyCVIQ83LhW/ND/hnY2cCdkvhJX LGqEOfGOGK8iRbiHycMjINf9f/cRwezDsLEitNfvwvYaPHZtdYoOshpUqBXybDYrHb5+ ZGaC+TqgmkHdDwtgfypQDN0UwNMj/y2poG4qmH1WGT72lck8zSQQQve0bz+UYryNPVSd 7Ggg2FaEMqNddDyoFCduQa8oHyaQ2itQ0DC9/jkwgyPPYraLuzpxSU1cm2VJAeAR9UGF UmZA== X-Gm-Message-State: AMke39lR/w6ypW8mkEyBTnSlrMkud7x5CXzMWEidK9mzj7h5sRw2zS7nyAAWl/DhhXDXd+6s X-Received: by 10.28.167.68 with SMTP id q65mr7502359wme.126.1486726963539; Fri, 10 Feb 2017 03:42:43 -0800 (PST) Received: from [197.131.23.99] ([197.131.23.99]) by smtp.gmail.com with ESMTPSA id w69sm1177541wmw.22.2017.02.10.03.42.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 03:42:42 -0800 (PST) Mime-Version: 1.0 (1.0) From: Ard Biesheuvel X-Mailer: iPhone Mail (14D27) In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503A8ECA37@shsmsx102.ccr.corp.intel.com> Date: Fri, 10 Feb 2017 11:42:35 +0000 Cc: "Tian, Feng" , "edk2-devel@lists.01.org" , Leif Lindholm , "Kinney, Michael D" , "Fan, Jeff" , "Zeng, Star" Message-Id: 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> <74D8A39837DF1E4DA445A8C0B3885C503A8EC562@shsmsx102.ccr.corp.intel.com> <4F3E8C94-BFF2-42A5-8E12-C03F955627F8@linaro.org> <0ACD6B44-66A4-474E-A9E5-55A322FD169B@linaro.org> <74D8A39837DF1E4DA445A8C0B3885C503A8ECA37@shsmsx102.ccr.corp.intel.com> To: "Yao, Jiewen" X-Content-Filtered-By: Mailman/MimeDel 2.1.21 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: Fri, 10 Feb 2017 11:42:45 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 10 Feb 2017, at 11:32, Yao, Jiewen wrote: >=20 > Good to learn that ARM/ARCH64 behavior. That is interesting. > =20 > Yes, if that is the case, we need figure out a way to make it work. > =20 > IMHO, =E2=80=9CUndo the protection=E2=80=9D directly is also risky. > Maybe the protection is used or setup by OS purposely before EBS (WoW. J).= Unprotecting them in BIOS might break the OS expectation. > =20 > =20 > Would you please provide more info on ARM Linux? When the OSLoader or OS t= akes over the page table? After EBS? On ARM, we call SetVirtualAddressMap directly after EBS, in the OS loader. T= he caches are disabled much later. It is the OS itself that reenables the MM= U, and install the UEFI virtual mapping as per-process mapping, which is onl= y live when a runtime services call is in progress. Therefore, we use a low virtual mapping for runtime services, which may conf= lict with the 1:1 mapping, so we never map any uefi regions 1:1 under the os= . This implies that the virtual mapping we install is not yet live when we ins= tall it, and so the easiest way to do that is to install it immediately afte= r ebs, when the firmware's 1:1 mapping is still live. > Thank you > Yao Jiewen > =20 > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard= Biesheuvel > Sent: Thursday, February 9, 2017 10:42 PM > To: Yao, Jiewen > Cc: Tian, Feng ; edk2-devel@lists.01.org; Leif Lindho= lm ; Kinney, Michael D ; Fan, Jeff ; Zeng, Star > Subject: Re: [edk2] [PATCH V3 0/4] DXE Memory Protection > =20 >=20 >=20 > > On 10 Feb 2017, at 06:34, Ard Biesheuvel wro= te: > >=20 > >=20 > >=20 > >> On 10 Feb 2017, at 02:26, Yao, Jiewen wrote: > >>=20 > >> Very good question. > >> =20 > >> 1) Yes, I did test UEFI OS boot, which is mentioned in V1 summary= : > >> =3D=3D=3D=3D=3D=3D > >> Tested OS: UEFI Win10, UEFI Ubuntu 16.04. > >> =3D=3D=3D=3D=3D=3D > >> =20 > >> 2) Star helps double confirm that OS already takes over the contr= ol of page table on SetVirtualAddressMap(). > >> See below log on UEFI Win10. > >> =3D=3D=3D=3D=3D=3D > >> DXEIPL CR3 0x88140000 > >> RUNTIMEDXE CR3 0x1AB000 > >> =3D=3D=3D=3D=3D=3D > >> =20 > >=20 > > Not on AArch64/ARM linux, and the spec does not mandate it, so we need t= o deal with this imo > >=20 >=20 > I think we should probably undo the protections for runtime drivers in EBS= () >=20 >=20 > >> Thank you > >> Yao Jiewen > >> =20 > >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of A= rd Biesheuvel > >> Sent: Thursday, February 9, 2017 8:48 AM > >> To: Yao, Jiewen > >> Cc: Tian, Feng ; edk2-devel@lists.01.org; Leif Lin= dholm ; Kinney, Michael D ; Fan, Jeff ; Zeng, Star > >> Subject: Re: [edk2] [PATCH V3 0/4] DXE Memory Protection > >> =20 > >> On 9 February 2017 at 16:30, Ard Biesheuvel = wrote: > >> > 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->ImageSi= ze, > >> >> EFI_PAGE_SIZE);=E2=80=9D > >> >> > >> > > >>=20 > >> Another question: did you try SetVirtualAddressMap()? It looks like we > >> need to lift read-only permissions to allow the runtime PE/COFF > >> relocation to apply the fixups > >> _______________________________________________ > >> 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