Re: post-ExitBootServices memory protection of RT_Data (ARM)

[Michael Zimmermann <sigmaepsilon92@gmail.com>]

If I understand this correctly this is just some MMU feature, right?
I'm talking about a pure ARM(with atag's) linux kernel which is not UEFI
aware.

Also the LinuxLoader disables almost everything(MMU, caches, it calls
exitbootservices etc).

I really can't explain technically what UEFI could have done to accomplish
this protection with the MMU being disabled.

Thanks
Michael

On Fri, Sep 2, 2016 at 10:30 PM, Laszlo Ersek <lersek@redhat.com> wrote:

> On 09/02/16 15:08, Michael Zimmermann wrote:
> > Hi,
> >
> > a friend of mine works with a hacked Luma WP device. he can already boot
> > Android by replacing UEFI with a linux bootloader.
> > What would be nice however is using UEFI's LinuxLoader. The problem with
> > that seems to be that even after ExitBootServices, booting linux from
> > addresses previously allocated as RT_Data seems to just not work(no UART
> > output etc and we don't have jtag).
> >
> > So, how can UEFI have such an influence at that point? Is there a ARM/TZ
> > feature for that? Can it be disabled?
> > I thought respecting the memory map would just be needed in case you want
> > to be able to call RuntimeServices and that you don't need to do that if
> > you don't need them.
>
> You most likely don't have execution rights for those pages.
>
> Refer to
>
> 4.6 EFI Configuration Table & Properties Table
>     EFI_MEMORY_ATTRIBUTES_TABLE
>
> in the UEFI 2.6 spec.
>
> See also git commit range 868d614a8532..47eb798d3619 for the
> implementation of the feature in the DXE Core.
>
> If you build the DXE Core with the DEBUG_VERBOSE bit (0x00400000)
> enabled in gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel, then the
> DXE Core will print the table at Ready-to-Boot.
>
> In my case, on aarch64 (Mustang), I can see two different attributes in
> total:
>
> - 0x8000000000004000 == EFI_MEMORY_RUNTIME | EFI_MEMORY_XP
>   (Read/Write Data)
>
> - 0x8000000000020000 == EFI_MEMORY_RUNTIME | EFI_MEMORY_RO
>   (Write-protected Code)
>
> which maps pretty well to runtime services data / runtime services code.
> For example, EFI_MEMORY_XP maps to TT_PXN_MASK in
> "ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c".
>
> Now, what is ultimately responsible for setting these attributes (mapped
> to the architecture) in the MMU is another question... I vaguely recall
> ties to the now-deprecated properties table /
> EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA (see
> them in the same chapter in the UEFI spec). I don't think I can tell you
> what is the thing that ultimately decides about setting up these page
> attributes.
>
> Thanks
> Laszlo
>