Robustesse de l’invariant vis-à-vis du logiciel utile

L’invariant va être mis en place par le logiciel de contrôle. Le logiciel utile va donc être activé dans une configuration où l’invariant sera vérifié. Le logiciel de contrôle peut être conçu de telle sorte à ne pas violer lui-même l’invariant. Il est cependant nécessaire de s’assurer que le logiciel utile, au cours de son exécution, ne l’invalidera pas non plus. Pour cela, nous raisonnons par récurrence. Le logiciel utile démarre son exécution dans une configuration où l’invariant est validé. C’est notre condition initiale. L’hypothèse de récurrence se ramène à montrer qu’en supposant l’invariant vérifié, toute instruction exécutée par le logiciel utile n’invalide pas l’invariant ou bien déclenche une exception dirigée vers le logiciel de contrôle. Nous supposons dans l’hypothèse de récurrence que le logiciel utile est exécuté dans les modes de privilège “utilisateur” ou “superviseur invité”. Le logiciel de contrôle est exécuté dans le mode “superviseur”. Nous supposons que le cœur e5500 n’offre aucun moyen au logiciel utile d’exécuter son code dans le mode de privilège superviseur, ce qui en soit constituerait une faille de sécurité sur le cœur.

Notre problème est donc ramené à une étude du jeu d’instructions, qui est la seconde de ce type, comme évoqué en début de chapitre. En nous référant à la table 7.1 page 100, nous avons écarté certaines classes d’instructions qui, de manière non ambigüe, ne sont pas susceptibles d’altérer le contenu de la MMU, des caches ou encore des registres de configuration (SPR), et n’invalideront donc pas l’invariant.

Chapitre 7. Cas d’étude sur un processeur COTS

Cette seconde analyse porte donc sur les classes d’instructions suivantes :

Opérations dans les registres de configuration (SPR). Les instructions mfspr et mtspr

effectuent les opérations dans les registres de configuration. Leur niveau de privi- lège dépend du registre choisi, ce qui demande d’évaluer la situation au cas par cas pour les différents registres. Nous développons ce point dans la propriété 7.2, ci-après.

Gestion de la MMU. Les instructions de gestion de la MMU effectuent des échanges

entre des registres SPR appelés MAS38. Les instructions disponibles visent l’écri- ture dans une entrée de la TLB (tlbwe), la lecture d’une entrée (tlbre), la recherche d’une entrée (tlbsx), l’invalidation locale (tlbilx) ou globale d’une entrée TLB (tl- bivax), et enfin la synchronisation d’un signal d’invalidation propagé entre tous les cœurs (tlbsync). Toutes ces instructions sont privilégiées.

Gestion des caches. Les instructions de gestion des caches ont été étudiées précédem- ment pour caractériser les émissions qu’elles peuvent générer.

•dcba, dcbal, dcbz, dcbzl, dcbt, dcbtst, icbt. Ces instructions ont été prises en compte dans la construction de l’invariant. Leur effet est couvert par ce dernier. Elles ne peuvent donc pas l’invalider.

•dcbtls, dcbtstls, dcblc, icbtls, icblc. Ces instructions gèrent le verrouillage dans le cache. Elles peuvent être rendues privilégiées en configurant les registres suivants : MSR[UCLE] = 0, MSRP[UCLE]39= 1. L’écriture dans ces registres est privilégiée.

•dcbi, icbi. Ces instructions sont privilégiées.

•dcbf, dcbst. L’usage de cet instruction est prohibé par la règle de conception 2, justifiée page 114.

Levée d’interruptions inter-cœurs. Les instructions correspondantes (msgsnd et msg- clr) sont privilégiées. Leur exécution lève une exception de privilège dirigée vers le logiciel de contrôle.

Lectures et écritures dans l’espace adressable. L’altération des caches, en particu- lier les niveaux L1D et L1I ont été prises en compte dans la définition de l’invariant. Elles ne peuvent donc pas l’invalider.

Propriété 7.2. Les registres de configuration (SPR) accessibles au logiciel utile dans le mode utilisateur et/ou “superviseur invité” ne peuvent pas invalider l’invariant.

Démonstration : Nous nous intéressons aux registres SPR pour lesquels une opéra-

tion d’écriture est susceptible d’altérer l’état du registre ou d’une ressource associée. Les registres en lecture seule ne sont donc pas considérés. Nous montrons que les registres en question sont soit privilégiés, soit neutres vis-à-vis de l’état des ressources impliquées dans l’invariant.

Nous évaluons les registres SPR impliqués dans les opérations suivantes :

38. MMU ASsist registers

7.5. Construction des séquences de contrôle

Programmation de la MMU. Le seul registre accessible en écriture est MMUCSR0,

qui initie les invalidations des TLB. Il est privilégié.

Les registres MAS0 à MAS8, qui programment les TLB, n’altèrent pas directement l’état de la MMU, dans la mesure où les instructions qui entraînent la mise à jour des TLB à partir de ces registres sont privilégiées.

Gestion des caches. Les registres SPR pouvant altérer l’état d’un cache sont les re- gistres L1CSR, L2CSR, et les registres de gestion et d’injection d’erreurs dans le cache. Tous ces registres sont privilégiés.

Ces registres sont les seuls concernés par la gestion du cache et de la MMU. Nous pouvons donc conclure sur le fait que les opérations de lecture et d’écriture dans les SPR ne peuvent pas invalider l’invariant.

Nous vérifions ainsi notre hypothèse de récurrence portant sur la validité de l’invariant suite à l’exécution par le logiciel utile d’une instruction PowerPC. Nous avons donc montré par récurrence que l’invariant est robuste.

Au final, l’invariant que nous avons défini porte sur des éléments que l’on peut ma- nipuler avec du logiciel, à savoir le contenu des caches et de la MMU. Par construction, il élimine les évènements non contrôlables sur la base de la classification que nous avons effectuée précédemment. La première hypothèse d’application du théorème de contrôla- bilité, qui dit que tout évènement sensible est contrôlable ou éliminé par la configuration du cœur, est donc vérifiée.

Nous abordons dans la section suivante la troisième étape de notre méthode, qui consiste à construire les séquences de contrôle.

7.5

Construction des séquences de contrôle

La deuxième hypothèse d’application du théorème de contrôlabilité dit que pour tout évènement sensible qui est contrôlable, il existe une ou plusieurs séquences de contrôle qui reproduisent cet évènement. Nous avons défini dans le chapitre précédent les types de séquences de contrôle suivantes :

Contrôle par émulation. Une séquence de contrôle par émulation peut être définie

pour un évènement sensible à une instruction. Elle cherchera à reproduire les effets de l’instruction en question, sans que cette dernière ne soit exécutée. Le logiciel invité a l’illusion que l’instruction sensible a été exécutée.

Contrôle par neutralisation. Une séquence de contrôle par neutralisation s’applique à un évènement sensible à la configuration. Elle cherchera à placer le cœur dans un état où l’évènement n’est plus sensible pour ensuite relancer l’exécution du logiciel utile qui génèrera à nouveau l’évènement.

Comme expliqué dans le chapitre précédent, une séquence de contrôle doit satisfaire la propriété de contrôle des ressources. Pour cela, elle doit maîtriser les dates des accès

Chapitre 7. Cas d’étude sur un processeur COTS

qu’elle initie vers les ressources communes. À cet effet, nous avons introduit la propriété de synchronisabilité dans le chapitre précédent (cf. page 74). Cette dernière précise que chaque cœur doit disposer d’un moyen d’accéder par une séquence d’opérations non sensibles à une source d’horloge globale. Nous montrons ci-après cette propriété pour le P5040.

Dans la section 6.3.6 page 87, nous avons proposé une structure de séquence de contrôle en quatre phases, qui étaient illustrées sur la figure 6.12 page 86. Ces phases sont les suivantes :

Préparation. Cette phase plannifie les accès à effectuer et prépare les ressources en conséquence. Lors de cette phase il faut prendre en compte le respect de l’inva- riant.

Synchronisation. Cette phase aura pour objectif de placer le cœur en attente active d’une fenêtre temporelle où il pourra réaliser ses opérations sur les ressources communes. Comme expliqué dans le chapitre précédent, cette phase repose prin- cipalement sur la propriété de synchronisabilité (cf définition 6.6 page 74), que nous montrons ci-après pour le P5040. Elle doit également prendre en compte un certain nombre de paramètres, comme la précision de la mesure de la date de référence, la durée entre la fin de son exécution et le début de l’émission effective par la phase d’émission, et enfin le temps d’exécution de la phase d’émission, qui doit être terminée avant la fin de la fenêtre temporelle.

Émission. Cette phase réalise les opérations sur les ressources distantes. il est préférable qu’elle soit synchrone, i.e. que les opérations soient terminées à la fin de son exécution.

Terminaison. Cette phase prépare la reprise de l’exécution du logiciel utile. Elle rétablit l’invariant s’il a été invalidé.

Après avoir montré la propriété de synchronisabilité sur le P5040, nous développons un exemple de séquence de contrôle par neutralisation, sur le même modèle que dans le chapitre précédent. Nous nous concentrons sur les phases de pré-traitement et d’émission, qui sont les plus complexes. Nous abordons par la suite un exemple de séquence de contrôle par émulation.

Synchronisabilité du P5040

Propriété 7.3. Le P5040 est synchronisable au sens de la définition 6.6.

Démonstration : Chaque cœur dispose d’une paire de registres appelée “base de

temps” (time base, ou TB). Ces paires de registres sont incrémentées sur un signal d’horloge qui vient soit de l’extérieur, soit de l’horloge de l’interconnexion après passage par un diviseur d’horloge, d’un facteur 32 sur le P5040. La fréquence du signal d’horloge résultant est comprise entre 10MHz et 100MHz.

Le circuit d’horloge n’est pas documenté, mais Freescale assure que le déphasage entre chaque cœur est négligeable devant une période du signal, dans la mesure où le circuit est faiblement asymétrique.

7.5. Construction des séquences de contrôle Enfin, il est possible de faire démarrer de manière synchrone l’intégralité des bases de temps sur chaque cœur par une écriture dans un registre du processeur40_{, qui est} rattaché à l’espace des registres de configuration41. On a ainsi la certitude qu’à tout moment toutes les bases de temps contiennent la même valeur à une unité près.