[edk2-devel] ArmVirt and Self-Updating Code

[Ard Biesheuvel]

On Thu, 22 Jul 2021 at 16:54, Bret Barkelew <Bret.Barkelew at microsoft.com> wrote:
>
> Expanding audience to the full dev list…
>
> See below…
>
>
>
> - Bret
>
>
>
> From: Thomas Abraham
> Sent: Wednesday, July 7, 2021 11:07 PM
> To: Bret Barkelew; Ard Biesheuvel (TianoCore); Lindholm, Leif; Laszlo Ersek; Marvin Häuser; Sami Mujawar
> Cc: nd
> Subject: [EXTERNAL] RE: ArmVirt and Self-Updating Code
>
>
>
> + Sami
>
>
>
> From: Bret Barkelew <Bret.Barkelew at microsoft.com>
> Sent: Thursday, July 8, 2021 11:05 AM
> To: Thomas Abraham <thomas.abraham at arm.com>; Ard Biesheuvel (TianoCore) <ardb+tianocore at kernel.org>; Lindholm, Leif <leif at nuviainc.com>; Laszlo Ersek <lersek at redhat.com>; Marvin Häuser <mhaeuser at posteo.de>
> Subject: ArmVirt and Self-Updating Code
>
>
>
> All,
>
>
>
> Marvin asked me a question on the UEFI Talkbox Discord that’s a little beyond my ken…
>
>
>
> “There is self-relocating code in ArmVirtPkg:
>
> https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aaf/ArmVirtPkg/PrePi/PrePi.c#L133-L165
>
> According to comments in the ASM, it seems like this is for Linux-based RAM boot (I saw further stuff for KVM, so it makes sense I guess?). It seems unfortunate it cannot be mapped into a known address range so that self-relocation is not necessary, but that's out of my scope to understand.
>

"Mapping" implies that the MMU is on, but this code boots with the MMU
off. Unlike x86, ARM does not define any physical address ranges that
are guaranteed to be backed by DRAM, so a portable image either needs
to be fully position independent, or carry the metadata it needs to
relocate itself as it is invoked.

>
>
> “Now, StandaloneMmPkg has similar (self-)relocation code too: https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c#L379-L386
>
> Because I cannot find such elsewhere, I assume it must be for the same ARM virtualised environment as above.

No.

> The binary it applies the Relocations to is documented to be the Standalone MM core, but in fact SecCore is located:
>
> https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/SetPermissions.c#L131-L158
>
>
>
> “This yields the following questions to me:
>
> 1) What even invokes Standalone MM on ARM? It is documented it is spawned during SEC, but I could not find any actual invocation.
>

It is not spawned by the normal world code that runs UEFI. It is a
secure world component that runs in a completely different execution
context (TrustZone). The code does run with the MMU enabled from the
start, but running from an a priori fixed offset was considered to be
a security hazard, so we added self relocation support.

The alternative would have been to add metadata to the StMmCore
component that can be interpreted by the secure world component that
loads it, but this would go beyond any existing specs, and make
portability more problematic.

> 2) Why does Standalone MM (self-)relocation locate SecCore? Should it not already have been relocated with the code from ArmPlatformPkg? Is Standalone MM embedded into ARM SecCore?
>

No and no. Standalone MM has nothing to do with the code that runs as
part of UEFI itself. ArmPlatformPkg is completely separate from
StandaloneMmPkg.

> 3) Why is SecCore the only module relocated? Are all others guaranteed to be "properly" loaded?
>

SecCore contains a PE/COFF loader, so all subsequent modules are
loaded normally. This is similar to the ArmVirtQemuKernel
self-relocating SEC module, which only relocates itself in this
manner, and relies on standard PE/COFF metadata for loading other
modules.


> 4) Is there maybe some high-level documented about the ARM boot flow? It seems to be significantly different from the x86 routes quite vastly.”
>

trustedfirmware.org may have some useful documentation.

>
>
> Hoping that one of you could get me closer to an answer for him. Also happy to take this to the greater mailing list, but thought I’d avoid churn.
>
>
>
> Thanks in advance!
>
> - Bret
>
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78097): https://edk2.groups.io/g/devel/message/78097
Mute This Topic: https://groups.io/mt/84380729/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-