VOSySofficial
Systèmes à Criticité Mixte pour Architectures ARM
Une tendance importante dans la conception des systèmes embarqués concerne l'intégration d'applications comportant différents niveaux de criticité afin d'interagir et de coexister sur une plate-forme hardware commune. La plupart des systèmes embarqués complexes présents, par exemple, dans l'industrie automobile évoluent vers des systèmes à criticité mixte dans le but de répondre aux différentes exigences liées à la taille, la consommation, la puissance et au coût. Par exemple, une voiture connectée est composée de systèmes critiques liés à la conduite (freinage, direction assistée électrique, etc.) qui doivent être isolés du système d'info-divertissement pour les passagers (IVI). Les principaux challenges présents dans les systèmes à criticité mixte sont liés à l'isolation des mémoires et des périphériques, le couplage des commandes et des données ainsi que les contraintes temps réel.
L'architecture proposée par Virtual Open Systems est basée sur la fonctionnalité ARM TrustZone qui permet d'exécuter simultanément un noyau temps réel isolé dans le "Secure world" pour les opérations critiques et un système d'exploitation universel possédant les extensions de virtualisation dans le "Normal world". TrustZone définit un mode opérationnel qui est complètement isolé (mémoire, périphérique, etc) des accès provenant de l'autre mode. De plus, cette architecture est définie de manière à donner la totale priorité à l'application s'exécutant dans le "Secure world" afin de respecter les contraintes temps réel.
Pour la réalisation d'une première disponible sur le marché (JUNO ARM Development Platform), le développement a été basé sur la structure du code ARM Trusted Firmware (ATF). ATF est un code open source pour architecture ARMv8 qui utilise la fonctionnalité TrustZone afin d'exécuter simultanément un software sécurisé ainsi qu'un software non fiable (U-Boot), respectivement, dans le "Secure world" et le "Normal world". Le changement de contexte entre l'exécution du "Secure world" et du Normal world" est seulement possible dans un niveau d'exception appelé "Secure monitor" ou EL3. La contribution de Virtual Open Systems est lié à la couche software BL31 du ARM Trusted Firmware contenant le code source du "Secure monitor".
Extensions du code ARM trusted firmware, source modifiée http://community.arm.com/docs/DOC-9306
Les nouvelles fonctionnalités développées par Virtual Open Systems dans le code du "Secure monitor" sont:
- Modification de la gestion des interruptions pour le "Secure world" afin de les router en EL3
- Ajout d'un service en EL3 pour exécuter un noyau temps réel dans le "Secure world"
- Optimisation des opérations liées au changement de contexte pour une application 32-bit
Fonctionnalités liées aux systèmes à criticité mixte développées, par Virtual Open Systems, dans ARM Trusted Firmware
Gestion des FIQs dans le "Secure monitor"
Virtual Open Systems a étendu les fonctionnalités du code ATF afin de router toutes les interruptions sécurisées dans le "Secure monitor". En effet, considérant la mise en oeuvre actuelle de l'ATF et sachant que notre architecture fournit la priorité totale d'exécution au Real Time Operating System (RTOS), le "Secure monitor" n'a aucun moyen de récupérer le contrôle dans le cas ou le RTOS monopoliserait les ressources du processeur (Crash du software sécurisé, boucle infinie, etc). Notre proposition ajoute une fonctionnalité au "Secure monitor" afin qu'il puisse gérer ces potentiels cas d'erreur.
Des active la gestion des interruptions sécurisées seulement dans la couche EL3, où le "Secure monitor" peut prendre, soit la décision de traiter l'interruption, soit la diriger vers le RTOS, en se basant sur l'ID de l'interruption. Le choix du management de l'interruption ne fait pas partie de cette contribution et est laissé libre au jugement du développeur en fonction des besoins spécifiques de la plate-forme cible. La solution proposée assumes que toutes les interruptions sécurisées sont dirigées vers le RTOS. Pour activer la gestion des interruptions en EL3, ARM Trusted Firmware doit être compilé avec l'option TSPD_ROUTE_FIQ_TO_EL3=1.
ATF fonctionne sensiblement de la même manière avec ou sans l'option TSPD_ROUTE_FIQ_TO_EL3 activée. Le principale changement concerne l'amélioration de la robustesse du système en permettant au "Secure monitor" d'exécuter une action lors de la génération d'une interruption. Cependant, cette solution software augmente la latence du traitement de l'interruption quand cette dernière est générée pendant l'exécution du "Secure world". En effet, ce genre d'interruption est directement routé vers le RTOS dans la version générique de l'ATF. La surcharge de travail se résume à:
- Opérations de sauvegarde
- Gestion du "Secure monitor"
- Opérations de restauration
La version ATF comprenant la gestion des FIQs en EL3 peut être téléchargée ici:
git clone https://github.com/virtualopensystems-kchappuis/arm-trusted-firmware.git -b fiq_el3_INTR_TYPE_S_EL1
Couche service pour supporter une système sécurisée 32-bit
Virtual Open Systems a ajouté, au code ATF, la possibilité d'exécuter une OS 32-bit dans le "Secure world". En effet, ce dernier ne peut exécuter seulement qu'une OS 64-bit avec la structure actuelle de l'ATF. Dans les extensions software, Virtual Open Systems ajoute un nouveau service dans l'ATF afin de supporter un noyau sécurisé 32-bit. Pour utiliser ce nouveau service, ARM Trusted Firmware doit être compilé avec les options TSP_AARCH32_MODE=1 et SPD=tspd_aarch32.
Afin de tester cette nouvelle fonctionnalité, Virtual Open Systems a porté FreeRTOS v8.2.2, l'un des noyaux temps réel 32-bit les plus populaires dans les systèmes embarqués, sur deux plate-formes ARM (ex: ARM Juno Development Board and ARM Fast Models) afin de l'exécuter en tant que OS 32-bit dans le ARM Trusted Firmware.
La version ATF comprenant le service pour exécuter une OS 32-bit peut être téléchargée ici:
git clone https://github.com/virtualopensystems-kchappuis/arm-trusted-firmware.git -b tspd_aarch32_service
Le portage de FreeRTOS v8.2.2 est disponible sur le forum FreeRTOS Community Contributions
Pour surmonter la limitation d'interruption de latence apporté avec cette mise en œuvre, Open Virtual Systems a développé son propre moniteur Firmware, appelé VOSYSmonitor, qui permet d'exécuter en même temps un RTOS dans le Monde sécurisé pour des opérations critiques ainsi qu'un General Purpose OS (GPOS) dans le monde normal. L'objectif de VOSYSmonitor est de transmettre une interruption au monde sécurisé en moins de 1 microseconde, alors que le monde normal est en cours d'exécution.
Services personnalisés de développement logiciel bas-niveau sur architecture ARM
De par son expérience liée à la virtualisation et aux systèmes hétérogènes (ex: SoCs basés sur l'architecture ARMv7 et ARMv8), Virtual Open Systems est un partenaire expérimenté pour la réalisation de services professionnels visant à développer des couches logiciels bas-niveaux, impliquant l'architecture ARM, pour les systèmes embarqués à criticité mixte:
- Architecture ARMv7-A & ARMv8-A
- Développement d'applications bas-niveau (ARM assembleur, GCC assembleur, C)
- Exception management (FIQ, IRQ, SMC, etc)
- Secure Monitor, Hypervisor
- Generic Interrupt Controller v2/v3
- Memory Management Unit
- KVM virtualization
