Re: ArmVirt and Self-Updating Code
|
Ard Biesheuvel
On Thu, 22 Jul 2021 at 16:54, Bret Barkelew <Bret.Barkelew@microsoft.com> wrote:
"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. No. The binary it applies the Relocations to is documented to be the Standalone MM core, but in fact SecCore is located: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.
|
|
|