Architecture firmware ARMv8 : Composants clés et flux de démarrage dans les systèmes serveurs

Depuis ses débuts en 2011, l'architecture ARMv8 est devenue ubiquitaire dans les appareils mobiles. Les prévisions du PDG d'ARM Limited projetaient que les processeurs ARMv8 captureraient jusqu'à 25 % du marché mondial d'ici 2020. Naturellement, le support logiciel a suivi, évoluant en héritant les fonctionnalités et principes de l'écosystème ARM de longue date.

Dans l'arène des serveurs, cependant, le paysage diffère nettement. Les serveurs basés x86 ont dominé pendant des décennies, tandis qu'ARMv8 n'a commencé que récemment à se tailler une niche dans certains segments d'entreprise. La nouveauté d'ARM dans ce domaine, couplée à l'adaptation tardive de standards clés comme ACPI et UEFI, a façonné l'évolution de sa pile firmware.

Cet article fournit une vue d'ensemble de haut niveau de l'architecture firmware qui alimente les systèmes serveurs ARMv8. Il n'est pas exhaustif, et les lecteurs doivent noter que de nouvelles versions de processeurs peuvent introduire différentes solutions techniques nécessitant des approches mises à jour.

Les implémentations firmware actuelles pour serveurs ARMv8 sont modulaires, offrant l'avantage de réutiliser des composants entre firmware serveur et embarqué tout en isolant les changements. La Figure 1 illustre la séquence de chargement et les interactions entre modules.

Fig 1. Flux de chargement et d'interaction des modules. (Source : Auriga)

Le démarrage commence par l'initialisation des sous-systèmes de bas niveau — RAM, communication inter-processeurs, etc. — gérée par un module dédié qui s'exécute en mode EL3S immédiatement après la mise sous tension du CPU. Ce composant jouit des privilèges les plus élevés et n'interagit généralement pas directement avec le système d'exploitation.

Le contrôle est ensuite passé au module ARM Trusted Firmware (ATF), s'exécutant aussi en EL3S. L'ATF peut être invoqué directement depuis le chargeur niveau-0 ou indirectement via un module UEFI PEI. La chaîne ATF consiste en plusieurs étapes, chacune activée à un point spécifique du processus de démarrage.

La première étape, BL1, configure les ressources matérielles sécurisées. L'isolation matérielle d'ARMv8 entre mémoire de confiance et non-confiance impose que BL1 établisse un environnement sécurisé : il programme les contrôleurs mémoire et cache, désigne les zones de confiance vs non-confiance, et définit les règles de filtrage DMA. Seuls les dispositifs avec attributs de sécurité correspondants peuvent accéder aux régions mémoire correspondantes. BL1 construit aussi les tables de traduction MMU et la table de vecteurs d'exception, particulièrement le gestionnaire Secure Monitor Call (SMC) qui peut déléguer le contrôle aux étapes ultérieures.

Une fois BL1 terminé, il charge BL2 en RAM et passe l'exécution via l'instruction ERET. BL2 s'exécute en EL1S, un mode à privilèges réduits qui protège les données et code BL1 de modifications accidentelles. Son rôle principal est de charger les étapes firmware restantes (variantes BL3) et de transférer le contrôle à elles.

La troisième étape peut comprendre jusqu'à trois sous-étapes, bien que BL3-2 soit souvent omise. BL3-1 est le code d'exécution de confiance avec lequel le système d'exploitation interagit pendant l'opération. Il contient le gestionnaire SMC et implémente l'interface PSCI — appels standards pour la gestion d'énergie et le contrôle des cœurs — ainsi que des extensions vendeur-spécifiques. BL3-2, si présente, opère en EL1S et sert de moniteur léger pour les événements de plateforme comme les interruptions de temporisateur ou signaux périphériques.

BL3-3 ne fait pas partie de l'ATF ; c'est une image non-sécurisée qui prend le relais en mode EL2. Des exemples typiques incluent U-Boot ou un environnement UEFI, tous deux standards pour les flux de démarrage serveur.

La séquence d'initialisation ATF est résumée dans la Figure 2.

Fig 2. Initialisation du module ATF. (Source : Auriga)