De architectuur van op ARMv8 gebaseerde firmwaresystemen

Sinds de release in 2011 is de ARMv8-processorarchitectuur behoorlijk wijdverbreid op de markt voor mobiele apparaten. Volgens de voorspellingen van de CEO van ARM Limited zullen de processors van deze generatie tegen 2020 een wereldmarktaandeel van maximaal 25% verwerven. Het is logisch dat de software-ondersteuning is opgericht en zich verder heeft ontwikkeld door de functies en algemene principes van de historisch gevormde infrastructuur.

Een fundamenteel andere situatie wordt waargenomen in het serversegment van de markt. X86-gebaseerde servers domineren dit gebied al een lange tijd, terwijl ARMv8 net zijn weg vindt (en alleen in specifieke bedrijfssegmenten). De nieuwigheid van deze markt voor ARM en het feit dat de meeste geaccepteerde standaarden en specificaties (voornamelijk ACPI en UEFI) tot voor kort niet zijn aangepast voor ARM-systemen, heeft zijn stempel gedrukt op de ontwikkeling van de software-infrastructuur.

Dit artikel richt zich op een overzicht van het op ARM gebaseerde serversysteem en de processorfuncties en pretendeert niet een uitputtende beschrijving te zijn. De auteurs willen de aandacht van de lezer ook vestigen op het feit dat verstrekte gegevens snel verouderd kunnen raken - binnenkort zullen nieuwe processors komen met nieuwe technische oplossingen die mogelijk een andere benadering van de implementatie van de software-infrastructuur vereisen.

Ten eerste moeten we erop wijzen dat de huidige implementaties van firmware voor ARMv8-serversystemen uit verschillende relatief onafhankelijke componenten bestaan. Dit biedt een aantal voordelen, zoals de mogelijkheid om dezelfde componenten te gebruiken in de firmware van zowel de server als de embedded systemen, evenals de relatieve onafhankelijkheid van aangebrachte wijzigingen.

Welke modules en componenten worden er in deze systemen gebruikt en wat zijn hun functies? Het algemene diagram voor het laden en interactie van modules wordt getoond in Fig. 1. Het proces begint met de initialisatie van subsystemen, zoals RAM en interprocessorinterfaces. In huidige implementaties wordt dit direct na het inschakelen van de CPU-hoofdstroom uitgevoerd door een aparte module in de EL3S-modus. Dit onderdeel van het systeem heeft dus de maximaal mogelijke privileges. Het heeft meestal geen directe interactie met het besturingssysteem.

Fig 1. Het laden en de interactie van modules. (Bron:Auriga)

Later wordt de besturing overgedragen aan de volgende component, meestal de ARM Trusted Firmware (ATF) -module, die in dezelfde modus wordt uitgevoerd. ATF-besturing kan rechtstreeks worden overgedragen van de niveau 0-lader die in de vorige paragraaf is beschreven, of indirect via een speciale UEFI-module die de PEI (PreEFI-initialisatie) implementeert. ATF bestaat uit verschillende modules die de besturing op verschillende tijdstippen ontvangen.

De startmodule BL1 voert de initialisatie uit van de platformdelen die zijn toegewezen aan de beveiligde processormodus. Aangezien op ARMv8 gebaseerde systemen hardwarescheiding gebruiken voor vertrouwde en niet-vertrouwde bronnen, inclusief RAM, bereidt de BL1-module een omgeving voor waarin de vertrouwde code kan worden uitgevoerd. Dit type initialisatie omvat met name de configuratie van geheugen-/cachecontrollers (vertrouwde en niet-vertrouwde zones worden gemarkeerd door de programmering van de registers in deze apparaten) en markering van on-chip-apparaten (energieonafhankelijke geheugencontrollers). Deze markup introduceert ook het filteren van DMA-transacties op basis van apparaattypes (vertrouwd/niet-vertrouwd). Gezien dit alles is het schrijven/lezen van geheugen alleen mogelijk naar/van gebieden waarvan de beveiligingsinstellingen overeenkomen met die van het apparaat. Implementaties van een vertrouwde omgeving kunnen behoorlijk complex zijn; ze kunnen bijvoorbeeld een afzonderlijk besturingssysteem bevatten. De beschrijving van dergelijke implementaties valt echter buiten het bestek van dit artikel.

De BL1-module configureert de MMU-adresvertaaltabel, evenals de uitzonderingsbehandelaarstabel, waarbij het belangrijkste element de uitzonderingsbehandelaar is voor de Secure Monitor Call (SMC)-instructie. Op dit punt is de handler minimaal en kan hij eigenlijk alleen de controle overdragen aan afbeeldingen die in het RAM zijn geladen. Tijdens het draaien laadt de BL1-module de volgende trap (BL2) in het RAM en draagt ​​de besturing daaraan over. De BL2-module werkt in de EL1S-modus met beperkte rechten. Daarom wordt de overdracht van de besturing naar deze module uitgevoerd met behulp van de "ERET"-instructie.

Het doel van de BL2-module is om de resterende firmwaremodules (BL3-onderdelen) te laden en de besturing daarop over te dragen. Het verlaagde privilegeniveau wordt gebruikt om mogelijke schade aan de code en EL3S-gegevens die al in het geheugen staan, te voorkomen. De code van deze onderdelen wordt uitgevoerd door de EL3S-code aan te roepen die zich in de BL1-trap bevindt met behulp van de SMC-instructie.

De derde fase van het laden en initialiseren van de ATF kan uit drie fasen bestaan, maar de tweede fase wordt meestal weggelaten. Er blijven er dus eigenlijk nog maar twee over. De BL3-1-module maakt deel uit van de vertrouwde code die tijdens runtime toegankelijk is voor algemene software (OS, enz.). Het belangrijkste onderdeel van deze module is de exception-handler die wordt aangeroepen door de "SMC"-instructie. Er zijn functies in de module zelf voor het implementeren van standaard SMC-aanroepen:de code die de standaard PSCI-interface implementeert (ontworpen om het hele platform te besturen, zoals het in-/uitschakelen van processorkernen, platformbreed energiebeheer en opnieuw opstarten) en die ook de leveranciers afhandelt -specifieke oproepen (informatie verstrekken over het platform, embedded apparaten beheren, enz.).

Zoals hierboven vermeld, is de aanwezigheid van de BL3-2-module optioneel; zijn code (in het geval van een module) wordt uitgevoerd in de EL1S-modus. Gewoonlijk dient het als een gespecialiseerde service/monitor voor de gebeurtenissen die plaatsvinden tijdens het gebruik van het platform (onderbrekingen van bepaalde timers, apparaten, enz.)

In feite is BL3-3 geen ATF-module, maar een afbeelding van firmware uitgevoerd in de niet-beveiligde modus. Het neemt meestal de controle over in de EL2-modus en vertegenwoordigt een afbeelding van een bootloader die lijkt op de algemeen bekende U-Boot of die van een UEFI-omgeving, die standaard is voor serversystemen.

Het algemene schema van de initialisatie van de ATF-module wordt getoond in Fig. 2.

Afb. 2. Initialisatie van de ATF-module. (Bron:Auriga)