Contrôleur Mémoire Mémoire principale Cœur Logiciel de contrôle
Cœur Cœur Cœur
Logiciel de contrôle Logiciel de contrôle Logiciel de contrôle Logiciel utile Logiciel utile Logiciel utile Logiciel utile Périphériques Contrôleurs de périphériques
Figure 6.3 – Déploiement du logiciel de contrôle
contrôle. Nous abordons ensuite la question de l’adaptation du théorème de virtualisation de Popek et Goldberg à notre cadre.
6.2
Cadre analogue pour le logiciel de contrôle
Nous reprenons dans cette section certaines notions développées dans la section pré- cédente, en les adaptant aux spécificités de notre logiciel de contrôle. Dans un premier temps, nous raffinons la définition d’évènement sensible –analogue des instructions sen- sibles chez Popek et Goldberg– ainsi que les propriétés attendues de notre logiciel de contrôle. Nous abordons ensuite la question de la validité du théorème de virtualisation dans notre contexte.
6.2.1
Définition du logiciel de contrôle
Comme décrit dans notre approche (cf chapitre 5), nous mettons en œuvre un logiciel qui contrôle les accès des cœurs aux ressources communes sur un processeur multi-cœurs. Conformément à la stratégie d’utilisation, les cœurs disposent de fenêtres temporelles dans lesquelles ils ont le droit d’accéder aux ressources. Le logiciel de contrôle doit forcer le logiciel utile à respecter ces fenêtres.
L’hyperviseur de Popek et Goldberg porte sur le contrôle d’instructions sensibles, qui peuvent amener le logiciel invité à s’octroyer le niveau de privilège superviseur et/ou à s’allouer certaines ressources matérielles. Notre logiciel vise à contrôler les dates d’accès
Chapitre 6. Stratégie de contrôle du processeur Évènements Évènements Sensibles aux instructions Évènements Sensibles à la Configuration Évènements Sensibles en permanence Évènements Sensibles
Figure 6.4 – Classification des évènements sensibles Table 6.1 – Terminologies analogues
Cadre de Popek et Goldberg [69] Logiciel de contrôle
Hyperviseur, ou Gestionnaire de Machines
Virtuelles Logiciel de contrôle
Logiciel invité Logiciel utile
Instructions sensibles Évènements sensibles
Instructions neutres Évènements neutres
du logiciel utile à ces ressources. Certains accès ont lieu lors de l’exécution de certaines instructions. D’autres accès peuvent avoir lieu sur des évènements matériels autres que l’exécution d’instructions, par exemple les chargements (fetch) d’instructions effectués par le cœur. Dans les deux cas, nous parlons d’évènements sensibles, comme étant l’analogue des instructions sensibles de Popek et Goldberg.
Définition 6.2 (Évènement sensible). Un évènement matériel est sensible s’il est suivi
de l’émission d’un ou plusieursaccès aux ressources communes.
Parmi les évènements sensibles que l’on peut rencontrer sur un processeur, nous retenons les cas particuliers suivants, illustrés sur la figure 6.4 :
Sensibilité à une instruction. Un évènement est sensible à une instruction si et seule- ment s’il correspond à l’exécution d’une instruction, au sens électronique, c’est- à-dire lors de son passage dans l’étage correspondant du pipeline. Lorsqu’un évè- nement est sensible à une instruction, on parle également d’instruction sensible. Sensibilité à la configuration. Un évènement est sensible à la configuration si et seule-
6.2. Cadre analogue pour le logiciel de contrôle état dans lequel cet évènement est neutre. Le chargement d’une donnée stockée dans une mémoire est un exemple d’évènement sensible à la configuration, selon la présence –ou non– de cette donnée dans un cache local.
Sensibilité permanente. Un évènement est sensible en permanence s’il n’appartient à aucune des deux catégories précédentes.
Les propriétés de contrôle des ressources et d’équivalence que nous attendons du logiciel de contrôle sont les mêmes que celles définies dans le cadre de virtualisation de Popek et Goldberg. Ainsi le logiciel utile ne doit avoir aucun moyen d’accéder aux ressources communes sans passer par le logiciel de contrôle, et l’effet du logiciel de contrôle doit être invisible pour le logiciel utile, à l’exception d’une altération de son temps d’exécution. La propriété d’équivalence assure entre autre la rétrocompatibilité vis-à-vis du logiciel existant, ce qui était un de nos objectifs.
Comme expliqué dans la section précédente, nous retenons la définition de la propriété d’efficacité selon Smith et Nair [90], moins restrictive que celle de Popek et Goldberg. Dans notre cas, elle signifie que le logiciel de contrôle intervient le moins possible dans les cas où le logiciel utile n’aurait pas accédé aux ressources communes. Cette propriété fait l’objet d’un développement spécifique dans le chapitre 8.
Définition 6.3 (Évènement contrôlable). Un évènement est dit contrôlable lorsque son
occurrence peut être systématiquement évitée grâce à la levée d’une exception dirigée vers le logiciel de contrôle.
Définition 6.4 (Évènement partiellement contrôlable). Un évènement est dit partiel-
lement contrôlable lorsqu’il existe un état du cœur où cet évènement déclenche une exception dirigée vers le logiciel de contrôle, et un état du cœur où aucune exception n’est levée.
Lorsqu’un évènement sensible est contrôlable, au sens de la définition ci-dessus, l’ex- ception levée par le cœur donne la possibilité au logiciel de contrôle de reproduire l’effet de cet évènement conformément à la propriété de contrôle des ressources. Pour cela, il embarque des séquences de contrôle, telles que définies ci-après.
Définition 6.5 (Séquence de contrôle). Une séquence de contrôle est une suite d’ins-
tructions neutres exécutées par le logiciel de contrôle qui a pour but de reproduire l’effet d’un évènement intercepté par le logiciel de contrôle. Nous distinguons deux types de séquences de contrôle :
Émulation Une séquence de contrôle par émulation s’applique à un évènement sensible à une instruction. Elle cherchera à reproduire les effets d’une instruction sensible sans que celle-ci soit réellement exécutée. L’exécution du logiciel utile reprend après l’instruction émulée. On retrouve ce type de séquence de contrôle chez Popek et Goldberg.
Neutralisation Une séquence de contrôle par neutralisation s’applique sur un évènement sensible à la configuration. Elle visera à placer le processeur dans un état où cet évènement n’est plus sensible, pour ensuite le faire rejouer par le logiciel utile.
Chapitre 6. Stratégie de contrôle du processeur
Pour un évènement sensible donné, on parlera de stratégie de contrôle par émulation ou par neutralisation selon le type de séquence de contrôle utilisé. De la même manière, on dira qu’un évènement est contrôlable par émulation et/ou par neutralisation selon le type de séquence de contrôle disponible.
Pour respecter la propriété de contrôle des ressources, une séquence de contrôle devra notamment garantir que les accès pour le compte du logiciel utile seront émis dans des fenêtres temporelles maîtrisées. Cela suppose que chaque cœur ait un moyen de mesurer une date de référence, sans pour autant accéder aux ressources communes. Nous introduisons à cet effet la propriété de synchronisabilité.
Définition 6.6 ( Synchronisabilité). Un cœur est synchronisable s’il existe une séquence
d’instructions neutres qui retourne la valeur d’une horloge de référence, commune entre tous les cœurs.
La nature du contrôle d’accès apporte également certaines contraintes au niveau du déploiement de ce logiciel, qui sont spécifiques à notre cadre, et n’ont donc pas été abordées par Popek et Goldberg. Comme illustré sur la figure 6.3, le contrôle est effectué au niveau des cœurs par un logiciel stocké dans une mémoire locale, par exemple un cache. Les données nécessaires à la configuration du logiciel de contrôle sont répliquées. Ainsi, l’instance locale du logiciel de contrôle sur chaque cœur est autonome pour contrôler l’activité de ce cœur. Autrement dit, le logiciel de contrôle n’émet pas d’accès autres que ceux, contrôlés, qu’il effectue à la place du logiciel utile à destination des ressources communes. Cette particularité de notre logiciel de contrôle a des conséquences sur la validité du théorème de virtualisation, que nous développons dans la section suivante.
6.2.2
Théorème de contrôlabilité
Le théorème de virtualisation de Popek et Goldberg donne une condition suffisante pour l’existence d’un hyperviseur vérifiant les propriétés d’efficacité, de contrôle des res- sources et d’équivalence. Cette condition consiste à vérifier que toute tentative du logiciel invité d’exécuter une instruction sensible, qui pourrait lui permettre de s’allouer des res- sources, génère une exception dirigée vers l’hyperviseur.
On peut définir la propriété analogue, à savoir que toute tentative du logiciel utile d’effectuer une opération impliquant un évènement sensible sur le cœur déclenche une exception dirigée vers le logiciel de contrôle. On pourrait conjecturer que cette condition est suffisante pour assurer l’existence d’un logiciel de contrôle. Ce n’est pas le cas, à cause d’une différence entre le cadre de Popek et Goldberg et le nôtre sur la notion d’évènement (resp. d’instruction) sensible.
De plus, dans le cadre de Popek et Goldberg, une instruction sensible n’a de sens que lorsqu’elle est exécutée au niveau de privilège utilisateur, car elle peut altérer le niveau de privilège ou allouer des ressources au logiciel invité. Dans notre cas, un évènement est sensible lorsqu’il génère un accès, indépendamment du niveau de privilège du cœur. Ainsi, le logiciel de contrôle pourrait au cours de son exécution générer des accès non
6.2. Cadre analogue pour le logiciel de contrôle maîtrisés à destination des ressources communes. Nous devons faire en sorte que, par construction, cette situation n’arrive jamais.
Nous proposons à travers le théorème de contrôlabilité, présenté ci-après, une adap- tation du théorème de virtualisation de Popek et Goldberg, dans laquelle les conditions d’application ont été généralisées :
Théorème 6.2(Contrôlabilité). Un logiciel de contrôle vérifiant les propriétés de contrôle
des ressources et d’équivalence peut être construit sur le cœur d’un processeur donné si ce dernier vérifie les propriétés suivantes :
(i) Tout évènement sensible (cf. définition 6.2) est soit contrôlable (cf. définition 6.3), soit rendu impossible.
(ii) Tout évènement contrôlable dont l’occurrence est possible peut être reproduit par une ou plusieurs séquences de contrôle.
On pourra noter que l’hypothèse (i) reprend la condition d’application du théorème de virtualisation de Popek et Goldberg.
En comparaison avec le théorème de virtualisation de Popek et Goldberg, la preuve de ce théorème est plus concise. Pour cause, l’hypothèse 6.1, portant sur la possibilité d’émuler un jeu d’instruction, n’est plus admise. Elle fait désormais parti des conditions d’application du théorème (hypothèse (ii)). Toutefois, le schéma de notre preuve reste le même que pour le théorème de virtualisation.
La propriété de contrôle des ressources se déduit de l’hypothèse (ii). Si on considère un évènement sensible, l’application de la séquence de contrôle correspondant à cet évè- nement assure que le logiciel de contrôle maîtrise les dates des accès qu’il effectue à destination des ressources communes, et qu’il n’en effectue pas pour sa propre exécu- tion. Il suffit alors que le logiciel de contrôle fasse coïncider ces dates avec des fenêtres temporelles où les accès en question sont autorisés.
La propriété d’équivalence se montre par récurrence, en suivant un schéma analogue à celui de Popek et Goldberg, que nous avons détaillé précédemment.
Nous disposons à travers ce cadre d’une définition du logiciel de contrôle qui lui confère de bonnes propriétés :
• La propriété de contrôle des ressources apporte l’assurance que le logiciel de contrôle interviendra pour empêcher le logiciel utile d’accéder directement aux ressources communes. Le logiciel de contrôle effectuera lui-même ses accès à des dates maîtrisées, en accord avec la stratégie d’utilisation.
• Grâce à la propriété d’équivalence, le logiciel utile n’est pas conscient de l’inter- vention du logiciel de contrôle, hormis une altération de son temps d’exécution. Cette propriété nous assure la rétro-compatibilité vis-à-vis du logiciel existant. Nous disposons d’un théorème qui s’il est applicable garantit l’existence de notre logiciel de contrôle sur un processeur donné. Les conditions d’application de ce théorème
Chapitre 6. Stratégie de contrôle du processeur
se traduisent en propriétés à vérifier sur le processeur. Nous nous intéressons dans la section suivante à la manière d’appliquer ce théorème sur des processeurs COTS.