Re: [PATCH V3 0/4] DXE Memory Protection

["Yao, Jiewen" <jiewen.yao@intel.com>]

Good to learn that ARM/ARCH64 behavior. That is interesting.

Yes, if that is the case, we need figure out a way to make it work.

IMHO, “Undo the protection” directly is also risky.
Maybe the protection is used or setup by OS purposely before EBS (WoW. ☺). Unprotecting them in BIOS might break the OS expectation.


Would you please provide more info on ARM Linux? When the OSLoader or OS takes over the page table? After EBS?

Thank you
Yao Jiewen

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 <jiewen.yao@intel.com>
Cc: Tian, Feng <feng.tian@intel.com>; edk2-devel@lists.01.org; Leif Lindholm <leif.lindholm@linaro.org>; Kinney, Michael D <michael.d.kinney@intel.com>; Fan, Jeff <jeff.fan@intel.com>; Zeng, Star <star.zeng@intel.com>
Subject: Re: [edk2] [PATCH V3 0/4] DXE Memory Protection



> On 10 Feb 2017, at 06:34, Ard Biesheuvel <ard.biesheuvel@linaro.org<mailto:ard.biesheuvel@linaro.org>> wrote:
>
>
>
>> On 10 Feb 2017, at 02:26, Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>> wrote:
>>
>> Very good question.
>>
>> 1)       Yes, I did test UEFI OS boot, which is mentioned in V1 summary:
>> ======
>> Tested OS: UEFI Win10, UEFI Ubuntu 16.04.
>> ======
>>
>> 2)       Star helps double confirm that OS already takes over the control of page table on SetVirtualAddressMap().
>> See below log on UEFI Win10.
>> ======
>> DXEIPL CR3 0x88140000
>> RUNTIMEDXE CR3 0x1AB000
>> ======
>>
>
> Not on AArch64/ARM linux, and the spec does not mandate it, so we need to deal with this imo
>

I think we should probably undo the protections for runtime drivers in EBS()


>> Thank you
>> Yao Jiewen
>>
>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard Biesheuvel
>> Sent: Thursday, February 9, 2017 8:48 AM
>> To: Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>
>> Cc: Tian, Feng <feng.tian@intel.com<mailto:feng.tian@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Leif Lindholm <leif.lindholm@linaro.org<mailto:leif.lindholm@linaro.org>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Fan, Jeff <jeff.fan@intel.com<mailto:jeff.fan@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
>> Subject: Re: [edk2] [PATCH V3 0/4] DXE Memory Protection
>>
>> On 9 February 2017 at 16:30, Ard Biesheuvel <ard.biesheuvel@linaro.org<mailto:ard.biesheuvel@linaro.org>> wrote:
>> > On 9 February 2017 at 16:29, Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>> 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
>> >>
>> >> “ImageRecord->ImageSize = ALIGN_VALUE(LoadedImage->ImageSize,
>> >> EFI_PAGE_SIZE);”
>> >>
>> >
>>
>> 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<mailto:edk2-devel@lists.01.org>
>> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel