Prise en charge de deux systèmes d'exploitation pour TEE dans l'informatique confidentielle

Dans une série de textes sur l'informatique privée, l'article « From Privacy to Private Computing » mentionne trois voies techniques principales pour parvenir à l'informatique privée, notamment : le chiffrement sécurisé multipartite, l'apprentissage fédéré et les environnements d'exécution fiables. Parmi eux, dans « A Little Knowledge of Trusted Execution Environment in Privacy Computing », il existe également deux méthodes principales de mise en œuvre de Trusted Execution Environment (TEE), à savoir l'isolation physique TrustZone et l'isolation de virtualisation.

Alors, comment mettre en œuvre l’environnement d’exécution fiable de TrustZone pour prendre en charge l’informatique privée ?

1. À propos de TrustZone

La technologie TrustZone est une technologie d'extension de sécurité système développée par ARM. L'objectif principal de la technologie TrustZone est d'assurer la sécurité des systèmes embarqués et d'empêcher les données sensibles du système de fuir ou les fonctions critiques du système d'être attaquées par des programmes malveillants. L'architecture technique de TrustZone est présentée dans la figure ci-dessous :

TrustZone divise les ressources de l'ensemble du système via une combinaison de logiciels et de matériel, et divise une partie en un domaine de sécurité et l'autre partie en un domaine normal. Le domaine de sécurité fournit les services de sécurité correspondants pour l'ensemble du système et ne peut exécuter qu'un seul service de sécurité ou un système d'exploitation complet ; le domaine ordinaire est un système d'exploitation traditionnel à usage général. Les deux zones d'exécution sont indépendantes l'une de l'autre. Généralement, la durée d'exécution du système des deux ne sera pas affectée par l'autre.

Pour garantir l'indépendance entre le domaine de sécurité et le domaine normal au sein du système, les données sensibles du domaine de sécurité sont gérées par ses dispositifs internes. Un système prenant en charge la technologie TrustZone dispose de tables de mappage d'adresses indépendantes dans son domaine de sécurité et son domaine commun, rendant la traduction d'adresses dans les deux zones d'exécution complètement indépendantes, éliminant ainsi la possibilité que le domaine de sécurité soit attaqué pendant le processus de traduction d'adresses.

1.1 Architecture CPU de TrustZone

Lors de la mise en œuvre de la technologie TrustZone, les processeurs ARM sont généralement divisés en deux cœurs virtuels, appelés mode normal et mode sans échec, qui sont respectivement responsables de l'exécution des tâches dans le domaine normal et dans le domaine sécurisé du système.

Comme le montre la figure ci-dessus, en prenant ARMv8 comme exemple, lorsque le système est dans un état normal, EL0 exécute généralement des programmes utilisateur ordinaires ; EL1 exécute généralement des logiciels privilégiés tels qu'un noyau de système d'exploitation général ; EL2 est utilisé pour implémenter la technologie de virtualisation et prend généralement en charge la virtualisation.Code lié à la technologie. Pour des raisons de sécurité du système, le mode EL3 n'existe pas dans les domaines ordinaires. Lorsque le système est dans un état sûr, EL0 exécute généralement des services de sécurité liés à la sécurité tels que le cryptage et le déchiffrement ; le logiciel dans EL1 est responsable de la prise en charge de ses applications de couche supérieure ; le mode EL3 a la plus haute autorité sur l'ensemble du système. , et exécute généralement le micrologiciel sous-jacent du système, tel que le moniteur de sécurité pour changer de région d'exécution. Dans le domaine de la sécurité, le mode EL2 n'existe généralement pas, mais après la sortie d'ARMv8.4, les développeurs peuvent l'utiliser en fonction des besoins réels.

1.2 Architecture logicielle TrustZone

Les applications du domaine de la sécurité sont principalement chargées de fournir des services de sécurité spécifiques au système, tels que le cryptage, le déchiffrement et le stockage sécurisé des données sensibles. Le noyau de confiance est principalement utilisé pour prendre en charge le fonctionnement normal des applications de couche supérieure et est responsable de la gestion des interruptions de sécurité dans le domaine de sécurité, de la communication avec les domaines ordinaires et de la fourniture d'une interface de sécurité unifiée pour les applications de couche supérieure.

Les applications dans l'espace utilisateur des domaines ordinaires ne connaissent généralement pas l'existence de TrustZone, et le système fournira les interfaces correspondantes pour ces applications via l'espace utilisateur. Lors de la communication entre les zones d'exécution, des files d'attente de messages et d'autres méthodes sont généralement utilisées. La mémoire où se trouvent ces structures de données est appelée mémoire partagée. Étant donné que les logiciels du domaine de sécurité et du domaine normal doivent fonctionner sur les données de la mémoire partagée et que le système ne peut obtenir aucune ressource dans le domaine de sécurité lorsqu'il est dans l'état normal, la mémoire partagée doit être non sécurisée. mémoire.

Après avoir reçu les informations traitées par le noyau de confiance, le service de sécurité du domaine de sécurité traitera la requête correspondante et enverra le résultat à la mémoire partagée correspondante, pour finalement revenir au domaine normal.

1.3 TEE basé sur TrustZone

Sur la base des caractéristiques techniques de TrustZone, l'environnement d'exécution de confiance peut fonctionner dans le domaine de sécurité du processeur ARM en tant qu'environnement d'exécution indépendant et fournir des services de sécurité flexibles pour l'ensemble du système. L'architecture système de la norme TEE est présentée dans la figure ci-dessous.

L'environnement d'exécution de confiance se compose d'un système d'exploitation de confiance (Trusted OS, TOS) et d'une application de confiance (Trusted Application, TA). TOS est chargé de gérer les ressources logicielles et matérielles au sein du TEE et de fournir à TA les ressources et interfaces nécessaires à son fonctionnement. TA est chargé de fournir des services de sécurité spécifiques pour les programmes au sein de REE. Au sein du TEE, les TA sont également indépendants les uns des autres : ils ne peuvent pas accéder directement aux ressources des autres TA, sauf via des interfaces API spéciales.

2. À propos des systèmes d'exploitation doubles

Afin de garantir à la fois la fonctionnalité et les exigences en temps réel du système, une architecture de système d'exploitation double peut être formée en intégrant des systèmes en temps réel et des systèmes en temps différé sur la même plate-forme matérielle. Dans cette architecture, le système temps réel est responsable du traitement des tâches en temps réel et de certaines tâches liées à la sécurité, et le système non temps réel est responsable du traitement des tâches non critiques avec des fonctions relativement complexes mais de faibles exigences en temps réel. . Les performances d'une architecture à double système d'exploitation dépendent de plusieurs indicateurs tels que la complexité, l'indépendance et le temps de réponse en temps réel. Ces indicateurs sont souvent contradictoires et difficiles à atteindre la perfection.

Il existe également deux formes de mise en œuvre d'un système d'exploitation double, l'une est un système d'exploitation double cœur et l'autre est basée sur la technologie de virtualisation.

2.1 Système double cœur

Un système double cœur place un petit noyau de système d'exploitation en temps réel (RTOS) sous un système d'exploitation à usage général (GPOS) et exécute GPOS en tant que tâche en temps réel au sein du système.

Le système dual-core a une faible charge de fonctionnement et ne nécessite aucun support matériel supplémentaire, mais cette architecture nécessite des modifications significatives du code du noyau GPOS, ce qui réduit considérablement la flexibilité du système. De plus, l'indépendance entre RTOS et GPOS dans un système à double noyau est faible. Lorsque GPOS est attaqué de manière malveillante ou que ses propres erreurs de fonctionnement se produisent, les tâches hautement critiques dans RTOS ne pourront pas s'exécuter normalement.

2.2 Systèmes doubles virtualisés

La technologie de virtualisation utilise RTOS et GPOS pour s'exécuter simultanément sur la même plate-forme matérielle que deux machines virtuelles, et les deux machines virtuelles sont gérées par un gestionnaire de machines virtuelles (hyperviseur).

La virtualisation permet une meilleure indépendance entre les systèmes d'exploitation, et le nombre de systèmes d'exploitation n'est pas limité aux GPOS et RTOS. Dans le même temps, tous les systèmes d'exploitation des couches supérieures n'ont pas besoin d'être modifiés d'aucune façon et ont une bonne flexibilité. Cependant, cette technologie entraînera une surcharge supplémentaire importante pour l'ensemble du système, réduisant les performances du RTOS et du GPOS. Dans le même temps, le gestionnaire de machines virtuelles doit être repensé pour répondre aux exigences en temps réel du système.

3. Les deux systèmes d'exploitation prennent en charge TrustZone

Grâce à la technologie TrustZone, le système d'exploitation en temps réel intégré peut être exécuté dans le domaine de la sécurité, responsable du traitement des tâches en temps réel hautement critiques, et le noyau Linux peut être exécuté dans le domaine commun, responsable du traitement des tâches générales peu critiques. . Si les tâches pertinentes dans le domaine ordinaire n'ont pas besoin de communiquer avec le domaine de sécurité, le noyau Linux n'a besoin que d'apporter des modifications minimes et ne sera pas conscient de l'existence du domaine de sécurité pendant le fonctionnement, et ses programmes internes ne seront pas informés. capable d'accéder à toutes les ressources du domaine de sécurité. , garantissant l'indépendance du domaine de sécurité. S'il existe des programmes dans le domaine ordinaire qui doivent utiliser les services système fournis dans le domaine de sécurité, vous pouvez ajouter le pilote TrustZone au noyau Linux. Le pilote sera responsable de la transmission des données entre le moniteur de sécurité et le domaine de sécurité. La couche du domaine ordinaire doit généralement également ajouter une bibliothèque liée à TrustZone utilisée pour fournir des interfaces API liées à TrustZone pour les programmes utilisateur.

Parmi eux, le moniteur de sécurité est principalement responsable de l'exécution de la commutation entre les zones du système, notamment :

(1) Répondre aux instructions de deux zones d’exécution.

(2) Responsable de répondre aux interruptions de sécurité pendant le fonctionnement du système d'exploitation général et de transmettre les interruptions au gestionnaire d'interruptions du système d'exploitation en temps réel dans le domaine de sécurité pour traitement.

(3) Lors du basculement entre les zones d'exécution, il est responsable de la sauvegarde et de la restauration du contexte pertinent et d'autres travaux de commutation spécifiques.

3.1 Mécanisme de gestion des interruptions

Le système divise toutes les interruptions en interruptions sûres et interruptions non sécurisées. Les interruptions non sécurisées sont gérées par Linux dans le domaine ordinaire et les interruptions sécurisées sont gérées par le RTOS dans TrustZone.

Si une interruption non liée à la sécurité se produit dans le domaine de sécurité, afin de garantir que les tâches clés exécutées dans le domaine de sécurité actuel peuvent être exécutées correctement, le système ignorera temporairement l'interruption. C'est-à-dire que lorsque le RTOS est en cours d'exécution, le L'interruption IRQ sera toujours masquée jusqu'à ce que les tâches clés soient terminées. , l'interruption ne sera gérée par Linux qu'après que le système soit passé au domaine normal. Si une interruption de sécurité se produit dans le domaine ordinaire, afin de garantir la capacité de réponse en temps réel des tâches clés dans le domaine de sécurité, le système basculera immédiatement vers le domaine de sécurité via le moniteur de sécurité pour gérer l'interruption.

3.2 Stratégie de planification

Les algorithmes de planification dans les systèmes d'exploitation doubles nécessitent l'établissement de modèles de tâches appropriés. Afin de juger de la programmabilité de la tâche correspondante définie dans le système, il est généralement nécessaire de calculer le pire temps de réponse de toutes les tâches. Après avoir déterminé la méthode d’analyse du temps de réponse des tâches, un algorithme est nécessaire pour attribuer des priorités respectives à toutes les tâches du système. Une fois la priorisation terminée, les tâches de l'ensemble de tâches sont planifiées pour s'exécuter en fonction de cette séquence de priorité.

Généralement, une stratégie de planification à deux niveaux peut être adoptée. Le premier niveau est la planification entre deux systèmes d'exploitation, qui est responsable du RTOS. Il adopte une stratégie de planification qui combine priorité fixe et rotation des tranches de temps. Pour que le planificateur de RTOS puisse planifier l'exécution de Linux, il existe toujours deux tâches de changement de région dans RTOS. Lorsque le RTOS planifie une tâche de changement de région, il sera commuté pour s'exécuter sous Linux via l'interface correspondante. Parmi elles, une tâche s'exécute comme une tâche inactive du RTOS ; l'autre tâche est utilisée pour réduire le temps de réponse du noyau Linux, améliorer l'expérience utilisateur et réduire l'impact sur ses performances.

4. Résumé

Si TEE est mis en œuvre via la technologie TrustZone pour prendre en charge l'informatique privée, alors les systèmes d'exploitation doubles peuvent être une solution potentielle. Ils doivent également gérer des problèmes tels que les interruptions et la planification. Peut-être peuvent-ils être considérés comme un cas particulier de systèmes d'exploitation distribués.

[Lecture connexe]