L'architecture des systèmes micrologiciels basés sur ARMv8

Depuis sa sortie en 2011, l'architecture du processeur ARMv8 est devenue assez répandue sur le marché des appareils mobiles. Selon les prévisions du PDG d'ARM Limited, les processeurs de cette génération acquerront jusqu'à 25 % de part de marché mondial d'ici 2020. Il est assez naturel que le support logiciel soit établi et se développe davantage en héritant des fonctionnalités et des principes de l'infrastructure historiquement formée.

Une situation fondamentalement différente est observée dans le segment des serveurs du marché. Les serveurs basés sur X86 dominent ce domaine depuis longtemps, tandis que ARMv8 fait tout juste son chemin (et uniquement dans des segments commerciaux spécifiques). La nouveauté de ce marché pour ARM et le fait que la plupart des normes et spécifications acceptées (principalement ACPI et UEFI) n'ont pas été adaptées aux systèmes ARM jusqu'à récemment a laissé sa marque sur le développement de l'infrastructure logicielle.

Cet article se concentre sur une vue d'ensemble du système de serveur basé sur ARM et des fonctionnalités du processeur et ne prétend pas être une description exhaustive. Les auteurs souhaitent également attirer l'attention du lecteur sur le fait que les données fournies peuvent rapidement devenir obsolètes. Bientôt, de nouveaux processeurs apporteront de nouvelles solutions techniques qui peuvent nécessiter une approche différente de la mise en œuvre de l'infrastructure logicielle.

Tout d'abord, il convient de souligner que les implémentations actuelles du firmware pour les systèmes serveurs ARMv8 se composent de plusieurs composants relativement indépendants. Cela donne un certain nombre d'avantages, tels que la possibilité d'utiliser les mêmes composants dans le firmware du serveur et des systèmes embarqués, ainsi que l'indépendance relative des changements introduits.

Alors, quels modules et composants sont utilisés dans ces systèmes, et quelles sont leurs fonctions ? Le graphique global pour le chargement et l'interaction des modules est illustré à la figure 1. Le processus commence par l'initialisation des sous-systèmes, tels que la RAM et les interfaces interprocesseurs. Dans les implémentations actuelles, cela est exécuté par un module séparé en mode EL3S immédiatement après la mise sous tension de la CPU principale. Ainsi, ce composant du système dispose du maximum de privilèges possibles. Il n'interagit généralement pas directement avec le système d'exploitation.

Fig 1. Le chargement et l'interaction des modules. (Source :Auriga)

Plus tard, le contrôle est transféré au composant suivant, le plus souvent le module ARM Trusted Firmware (ATF), qui est exécuté dans le même mode. Le contrôle ATF peut être transféré soit directement depuis le chargeur de niveau 0 décrit dans le paragraphe précédent, soit indirectement via un module UEFI spécial qui implémente le PEI (PreEFI Initialization). ATF se compose de plusieurs modules qui reçoivent le contrôle à des moments différents.

Le module de démarrage BL1 effectue l'initialisation des parties de la plate-forme affectées au mode processeur sécurisé. Étant donné que les systèmes basés sur ARMv8 utilisent une séparation matérielle pour les ressources approuvées et non approuvées, y compris la RAM, le module BL1 prépare un environnement dans lequel le code approuvé peut être exécuté. En particulier, ce type d'initialisation comprend la configuration des contrôleurs de mémoire/cache (les zones de confiance et non de confiance sont marquées par la programmation des registres dans ces appareils) et le marquage des appareils sur puce (contrôleurs de mémoire indépendants de l'énergie). Ce balisage introduit également le filtrage des transactions DMA sur la base des types d'appareils (de confiance/non de confiance). Compte tenu de tout cela, l'écriture/lecture mémoire n'est possible que vers/depuis des zones dont les paramètres de sécurité correspondent à ceux de l'appareil. Les implémentations d'un environnement de confiance peuvent être assez complexes; par exemple, ils peuvent inclure un système d'exploitation distinct. Cependant, la description de telles implémentations dépasse le cadre de cet article.

Le module BL1 configure la table de traduction d'adresses MMU, ainsi que la table de gestionnaire d'exceptions, où l'élément le plus important est le gestionnaire d'exceptions pour l'instruction Secure Monitor Call (SMC). À ce stade, le gestionnaire est minimal et ne peut en réalité transférer le contrôle qu'aux images chargées dans la RAM. Pendant l'exécution, le module BL1 charge l'étage suivant (BL2) dans la RAM et lui transfère le contrôle. Le module BL2 fonctionne en mode EL1S avec des privilèges réduits. Par conséquent, le transfert de contrôle à ce module est effectué à l'aide de l'instruction « ERET ».

L'objectif du module BL2 est de charger les modules de firmware restants (parties BL3) et de leur transférer le contrôle. Le niveau de privilège réduit est utilisé pour éviter d'endommager le code et les données EL3S déjà en mémoire. Le code de ces pièces est exécuté en appelant le code EL3S situé à l'étage BL1 à l'aide de l'instruction SMC.

La troisième étape du chargement et de l'initialisation de l'ATF peut comprendre trois étapes, mais la deuxième étape est généralement omise. Ainsi, en fait, il n'en reste que deux. Le module BL3-1 fait partie du code de confiance accessible aux logiciels généralistes (OS, etc.) en runtime. L'élément clé de ce module est le gestionnaire d'exceptions appelé par l'instruction « SMC ». Il existe des fonctions dans le module lui-même pour implémenter des appels SMC standard :le code qui implémente l'interface PSCI standard (conçue pour contrôler l'ensemble de la plate-forme, comme l'activation/la désactivation des cœurs de processeur, la gestion de l'alimentation à l'échelle de la plate-forme et le redémarrage) et gère également le fournisseur -appels spécifiques (fourniture d'informations sur la plate-forme, gestion des appareils embarqués, etc.).

Comme mentionné ci-dessus, la présence du module BL3-2 est facultative; son code (dans le cas d'un module) est exécuté en mode EL1S. Habituellement, il sert de service/moniteur spécialisé pour les événements qui se produisent pendant le fonctionnement de la plate-forme (interruptions de certains temporisateurs, appareils, etc.)

En fait, BL3-3 n'est pas un module ATF, mais une image de firmware exécuté en mode non sécurisé. Il prend généralement le contrôle en mode EL2 et représente une image soit d'un chargeur de démarrage similaire au célèbre U-Boot, soit de celui d'un environnement UEFI, qui est standard pour les systèmes de serveur.

Le graphique global de l'initialisation du module ATF est illustré à la Fig. 2.

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