Die Architektur von ARMv8-basierten Firmwaresystemen

Seit ihrer Veröffentlichung im Jahr 2011 hat sich die ARMv8-Prozessorarchitektur auf dem Markt für mobile Geräte weit verbreitet. Nach den Prognosen des CEO von ARM Limited werden die Prozessoren dieser Generation bis 2020 einen Weltmarktanteil von bis zu 25 % erreichen. Es ist selbstverständlich, dass die Softwareunterstützung durch die Vererbung der Features und generelle etabliert wurde und weiterentwickelt wurde Prinzipien der historisch geprägten Infrastruktur.

Eine grundlegend andere Situation ist im Serversegment des Marktes zu beobachten. X86-basierte Server dominieren diesen Bereich schon seit längerem, während ARMv8 gerade seinen Weg (und nur in bestimmte Geschäftsfelder) findet. Die Neuheit dieses Marktes für ARM und die Tatsache, dass die meisten akzeptierten Standards und Spezifikationen (hauptsächlich ACPI und UEFI) bis vor kurzem nicht für ARM-Systeme angepasst wurden, hat die Entwicklung der Software-Infrastruktur geprägt.

Dieser Artikel konzentriert sich auf einen Überblick über das ARM-basierte Serversystem und die Prozessorfunktionen und erhebt keinen Anspruch auf eine erschöpfende Beschreibung. Die Autoren möchten den Leser auch darauf aufmerksam machen, dass bereitgestellte Daten schnell veralten können – bald werden neue Prozessoren mit neuen technischen Lösungen kommen, die möglicherweise eine andere Herangehensweise an die Implementierung der Software-Infrastruktur erfordern.

Zunächst ist darauf hinzuweisen, dass die aktuellen Implementierungen von Firmware für ARMv8-Serversysteme aus mehreren relativ unabhängigen Komponenten bestehen. Dies bietet eine Reihe von Vorteilen, wie die Möglichkeit, dieselben Komponenten sowohl in der Firmware des Servers als auch der eingebetteten Systeme zu verwenden, sowie die relative Unabhängigkeit von eingeführten Änderungen.

Welche Module und Komponenten werden also in diesen Systemen verwendet und welche Funktionen haben sie? Das Gesamtdiagramm für das Laden und Zusammenwirken von Modulen ist in Abb. 1 dargestellt. Der Prozess beginnt mit der Initialisierung von Subsystemen wie RAM und Interprozessor-Schnittstellen. In aktuellen Implementierungen wird dies von einem separaten Modul im EL3S-Modus direkt nach dem Einschalten der Haupt-CPU-Power ausgeführt. Somit hat diese Komponente des Systems die maximal möglichen Privilegien. Es interagiert normalerweise nicht direkt mit dem Betriebssystem.

Abb 1. Das Laden und die Interaktion von Modulen. (Quelle:Auriga)

Später wird die Kontrolle an die nächste Komponente übertragen, meistens das ARM Trusted Firmware (ATF)-Modul, das im gleichen Modus ausgeführt wird. Die ATF-Steuerung kann entweder direkt von dem im vorherigen Absatz beschriebenen Level-0-Loader oder indirekt über ein spezielles UEFI-Modul übertragen werden, das die PEI (PreEFI-Initialisierung) implementiert. ATF besteht aus mehreren Modulen, die die Kontrolle zu unterschiedlichen Zeiten erhalten.

Das Startmodul BL1 führt die Initialisierung der dem sicheren Prozessormodus zugeordneten Plattformteile durch. Da ARMv8-basierte Systeme eine Hardwaretrennung für vertrauenswürdige und nicht vertrauenswürdige Ressourcen verwenden, einschließlich RAM, bereitet das BL1-Modul eine Umgebung vor, in der der vertrauenswürdige Code ausgeführt werden kann. Diese Art der Initialisierung umfasst insbesondere die Konfiguration von Memory/Cache-Controllern (Trusted und Non-Trusted Zones werden durch die Programmierung der Register in diesen Geräten markiert) und das Markieren von On-Chip-Devices (energieunabhängige Speichercontroller). Dieses Markup führt auch die Filterung von DMA-Transaktionen auf Basis von Gerätetypen (vertrauenswürdig/nicht vertrauenswürdig) ein. Vor diesem Hintergrund ist das Schreiben/Lesen des Speichers nur in/aus Bereichen möglich, deren Sicherheitseinstellungen denen des Geräts entsprechen. Implementierungen einer vertrauenswürdigen Umgebung können ziemlich komplex sein; Sie können beispielsweise ein separates Betriebssystem enthalten. Die Beschreibung solcher Implementierungen würde jedoch den Rahmen dieses Artikels sprengen.

Das BL1-Modul konfiguriert die MMU-Adressübersetzungstabelle sowie die Ausnahmebehandlungstabelle, wobei das wichtigste Element die Ausnahmebehandlungsroutine für den Secure Monitor Call (SMC)-Befehl ist. An diesem Punkt ist der Handler minimal und kann die Kontrolle eigentlich nur auf Bilder übertragen, die in den RAM geladen werden. Während des Betriebs lädt das BL1-Modul die nächste Stufe (BL2) in den RAM und übergibt diesem die Kontrolle. Das BL2-Modul arbeitet im EL1S-Modus mit reduzierten Privilegien. Daher erfolgt die Übergabe der Steuerung an dieses Modul mit der Anweisung „ERET“.

Der Zweck des BL2-Moduls besteht darin, die restlichen Firmware-Module (BL3-Teile) zu laden und ihnen die Kontrolle zu übertragen. Die reduzierte Berechtigungsstufe wird verwendet, um eine mögliche Beschädigung des Codes und der EL3S-Daten bereits im Speicher zu vermeiden. Der Code dieser Teile wird ausgeführt, indem der EL3S-Code, der sich in der BL1-Stufe befindet, mit dem SMC-Befehl aufgerufen wird.

Die dritte Stufe des Ladens und Initialisierens des ATF kann aus drei Stufen bestehen, aber die zweite Stufe wird in der Regel weggelassen. Somit bleiben tatsächlich nur noch zwei übrig. Das BL3-1-Modul ist Teil des vertrauenswürdigen Codes, der zur Laufzeit für allgemeine Software (OS usw.) zugänglich ist. Der Schlüsselteil dieses Moduls ist der Ausnahmehandler, der von der Anweisung „SMC“ aufgerufen wird. Im Modul selbst befinden sich Funktionen zur Implementierung von Standard-SMC-Aufrufen:der Code, der die Standard-PSCI-Schnittstelle implementiert (entwickelt, um die gesamte Plattform zu steuern, z -spezifische Anrufe (Informationen über die Plattform bereitstellen, eingebettete Geräte verwalten usw.).

Wie oben erwähnt, ist das Vorhandensein des BL3-2-Moduls optional; sein Code (bei einem Modul) wird im EL1S-Modus ausgeführt. Normalerweise dient es als spezialisierter Dienst/Monitor für die Ereignisse, die während des Plattformbetriebs auftreten (Interrupts von bestimmten Timern, Geräten usw.)

Tatsächlich ist BL3-3 kein ATF-Modul, sondern ein Abbild einer Firmware, die im unsicheren Modus ausgeführt wird. Es übernimmt normalerweise die Kontrolle im EL2-Modus und stellt entweder ein Abbild eines Bootloaders ähnlich dem weithin bekannten U-Boot oder das einer UEFI-Umgebung dar, die für Serversysteme Standard ist.

Das Gesamtdiagramm der Initialisierung des ATF-Moduls ist in Abb. 2 dargestellt.

Abb. 2. Initialisierung des ATF-Moduls. (Quelle:Auriga)