ARMv8 Firmware Architectuur: Sleutelcomponenten en Boot Flow in Server Systemen

Sinds zijn debuut in 2011 is de ARMv8-architectuur alomtegenwoordig in mobiele apparaten. Voorspellingen van ARM Limited's CEO projecteerden dat ARMv8-processors tot 25% van de wereldwijde markt zouden veroveren tot 2020. Natuurlijk is software-ondersteuning gevolgd, geëvolueerd door het overerven van de features en principes van het langgevestigde ARM-ecosysteem.

In de server-arena verschilt het landschap echter merkbaar. x86-gebaseerde servers hebben decennialang gedomineerd, terwijl ARMv8 pas onlangs begonnen is een niche uit te snijden in geselecteerde enterprise-segmenten. De nieuwheid van ARM in dit domein, gecombineerd met de late adaptatie van sleutelstandaarden zoals ACPI en UEFI, heeft de evolutie van de firmware-stack gevormd.

Dit artikel biedt een high-level overzicht van de firmware-architectuur die ARMv8-server-systemen aandrijft. Het is niet uitputtend, en lezers moeten noteren dat nieuwe processor-releases verschillende technische oplossingen kunnen introduceren die bijgewerkte benaderingen rechtvaardigen.

Huidige firmware-implementaties voor ARMv8-servers zijn modulair, wat het voordeel biedt van component-hergebruik over server- en embedded-firmware terwijl wijzigingen geïsoleerd blijven. Figuur 1 illustreert de laadvolgorde en interacties tussen modules.

Fig 1. Module laadvolgorde en interactie flow. (Bron: Auriga)

Boot begint met de initialisatie van low-level subsysteem – RAM, inter-processor communicatie, en zo verder – afgehandeld door een dedicate module die draait in EL3S-mode onmiddellijk na de CPU power-on. Deze component geniet de hoogste privileges en interacteert typisch niet direct met het besturingssysteem.

Controle wordt dan doorgegeven aan de ARM Trusted Firmware (ATF) module, ook executend in EL3S. ATF kan direct aangeroepen worden vanuit de level-0 loader of indirect via een UEFI PEI-module. De ATF-keten bestaat uit meerdere stadia, elk geactiveerd op een specifiek punt in het boot-proces.

Het eerste stadium, BL1, configureert secure hardware-bronnen. ARMv8's hardware-gebaseerde isolatie tussen trusted en non-trusted geheugen vereist dat BL1 een veilige omgeving vestigt: het programmeert geheugen- en cache-controllers, wijst trusted vs. non-trusted zones toe, en stelt DMA-filterregels in. Alleen apparaten met matching security-attributen kunnen de overeenkomstige geheugenregio's benaderen. BL1 bouwt ook de MMU-vertalingstabellen en de exception-vector-tabel, met name de Secure Monitor Call (SMC) handler die controle kan delegeren aan latere stadia.

Zodra BL1 klaar is, laadt het BL2 in RAM en geeft de uitvoering door via de ERET-instructie. BL2 draait in EL1S, een reduced-privilege mode die de BL1-data en -code beschermt tegen onbedoelde wijziging. De primaire rol is om de overige firmware-stadia (BL3-varianten) te laden en controle over te dragen aan hen.

Het derde stadium kan tot drie sub-stadia omvatten, hoewel BL3‑2 vaak weggelaten wordt. BL3‑1 is de trusted runtime-code waarmee het besturingssysteem tijdens operatie interacteert. Het bevat de SMC-handler en implementeert de PSCI-interface – standaard calls voor power-management en core-control – alsook vendor-specifieke extensies. BL3‑2, indien aanwezig, draait in EL1S en fungeert als een lichtgewicht monitor voor platform-events zoals timer-interrupts of perifere signalen.

BL3‑3 is geen deel van ATF; het is een non-secure image die overneemt in EL2-mode. Typische voorbeelden zijn U‑Boot of een UEFI-omgeving, beide standaard voor server-boot-flows.

De ATF-initialisatie-sequentie wordt samengevat in Figuur 2.

Fig 2. ATF-module initialisatie. (Bron: Auriga)