post-ExitBootServices memory protection of RT_Data (ARM)

post-ExitBootServices memory protection of RT_Data (ARM)

[Michael Zimmermann]

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.

Thanks
Michael

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

[Laszlo Ersek]

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

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

[Michael Zimmermann]

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
>

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

[Ard Biesheuvel]

On 2 September 2016 at 21:45, Michael Zimmermann
<sigmaepsilon92@gmail.com> wrote:
> 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.
>

No, the kernel is entered with the MMU and caches off. The LinuxLoader
is a poorly maintained hack, and it is badly broken on AARCH64. On
ARM, however, it should still work. Does the system have an L2 cache
which may need invalidation/disabling?

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

[Michael Zimmermann]

> The LinuxLoader is a poorly maintained hack, and it is badly broken on
AARCH64
I'm actually just using the shutdown code from linux loader. I wrote my
own, very complete loader which does definitely work in terms of correct
loading and argument passing.

> Does the system have an L2 cache which may need invalidation/disabling.
I doubt that this is the problem because I can even load the soc vendor's
linux bootloader first(to a available addr) which fully works(usb, mmc,
...). and from there I can fastboot boot linux - which then just doesn't
work depending on the loading addr.

I'll ask him to do more tests like reading back data, loading other stuff
to that location to prevent problems linux might have with other memory
locations passed by atags, etc.


On Fri, Sep 2, 2016 at 11:02 PM, Ard Biesheuvel <ard.biesheuvel@linaro.org>
wrote:

> On 2 September 2016 at 21:45, Michael Zimmermann
> <sigmaepsilon92@gmail.com> wrote:
> > 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.
> >
>
> No, the kernel is entered with the MMU and caches off. The LinuxLoader
> is a poorly maintained hack, and it is badly broken on AARCH64. On
> ARM, however, it should still work. Does the system have an L2 cache
> which may need invalidation/disabling?
>