Assurance d’une ex´ecution correcte

possible d’utiliser une politique d’allocation des ressources statique, tout en permet- tant `a l’usage de ces ressources de varier dynamiquement.

Notons cependant qu’il est toujours possible de faire de l’allocation de mani`ere ind´eterministe : par exemple en ex´ecutant un syst`eme existant virtualis´e. Mais ce qui importe est la possibilit´e d’avoir des d´ecisions d’allocations qui soient d´eterministes, surtout pour celles concernant les tˆaches critiques.

Simplicit´e et lisibilit´e Le deuxi`eme int´erˆet est la simplicit´e et lisibilit´e des politiques. Comme toute la politique pour une ressource est d´efinie par le module de politique, cela permet de savoir simplement comment les ressources seront allou´ees : l’allocation des ressources devient une pr´eoccupation s´epar´ee. Par opposition, dans les syst`emes classiques, il faut connaˆıtre des informations sur l’ensemble du syst`eme (en particulier, les appels qui peuvent bloquer) pour pouvoir faire une pr´evision.

De plus, comme on ´evite beaucoup de sous-pools et sous-politiques, cela simplifie la gestion des ressources. Ainsi, on pourra dire qu’on a attribu´e 100 ko `a une application, plutˆot que de totaliser qu’une application utilise 50ko pour ses donn´ees, 12ko de table des pages, 8ko pour le domaine de protection, et 20ko de buffers r´eseaux.

Flexibilit´e Enfin, cette ind´ependance permet une grande flexibilit´e dans les poli- tiques d’allocation. Mˆeme s’il ´etait d´ej`a possible de d´efinir des politiques dans des modules externes (§ 2.4.3.1), on ´etait n´ecessairement limit´e dans l’´etendue des poli- tiques possibles par le fait que toute la politique n’´etait pas d´efinie par ce module ; l’ind´ependance des politiques r´esout ce probl`eme. On obtient ainsi une approche modulaire de l’allocation des ressources.

3.1.2 Assurance d’une ex´ecution correcte

Les principes que nous abordons maintenant permettent d’assurer `a une tˆache une ex´ecution correcte, une fois que la tˆache dispose d’assez de ressources et ne commet pas de fautes. En particulier, ces principes assurent que la pr´esence d’autres tˆaches (critiques ou non) ne peut pas faire d´efaillir cette tˆache.

3.1.2.1 Respect des principes fondamentaux de s´ecurit´e

Les principes de s´ecurit´e fondamentaux tels qu’´enonc´es par Saltzer et Schroeder (§ 2.2.2), doivent ˆetre scrupuleusement suivis pour atteindre une haute garantie d’ex´ecution. Nous accordons une importance particuli`ere aux principes de s´eparation des privil`eges, m´ediation compl`ete, d´efaillance sˆure par d´efaut, principe du moindre privil`ege, et minimisation des m´ecanismes communs, que nous prenons en compte dans la structure du syst`eme.

Nous prenons ´egalement en compte le principe de conception ouverte (cette pr´esente th`ese, ´etant publique, en est la preuve), et de s´ecurit´e pr´evue au d´epart. L’acceptation psychologique est moins importante puisque dans les syst`emes em- barqu´es, on n’a pas vraiment d’interface avec l’utilisateur ; cependant nous avons

fait en sorte que les concepts du syst`eme soient naturels et faciles `a appr´ehender pour un d´eveloppeur d’application.

3.1.2.2 Principe : Ressources n´ecessaires pr´evisible

Pour pouvoir pr´evoir `a l’avance que l’ex´ecution d’une tˆache va bien se d´erouler, le fait de pouvoir choisir l’allocation des ressources ne suffit pas : il faut ´egalement pouvoir pr´evoir de combien de ressources la tˆache a besoin pour s’ex´ecuter. Cette question concerne essentiellement les besoins des tˆaches ; mais il se pose ´egalement la question du nombre de ressources dont ont besoins les services partag´es utilis´es par ces tˆaches.

M´emoire Pour la m´emoire, il est n´ecessaire que la tˆache sache r´epondre `a des questions comme « combien de m´emoire est n´ecessaire pour cr´eer une nouvelle tˆache ? un nouveau thread ? un nouvel espace d’adressage ? un buffer r´eseau ? ». La m´emoire n´ecessaire peut ainsi ˆetre calcul´ee en fonction des besoins de la tˆache, ce qui ´evite de sur-r´eserver des ressources. Dans notre prototype Anaxagoros, quasiment tous les objets syst`emes sont de taille 1 page ; sauf les buffers prˆet´es aux services (pour le r´eseau, etc.) qui sont de taille arbitraire, choisie par l’application.

Temps CPU et protection contre les « ralentissements de service » Pour le CPU, il faudrait id´ealement qu’on puisse pr´evoir le temps CPU n´ecessaire pour ex´ecuter les diff´erents appels de services. Pr´evoir le temps CPU utilis´e est quelque chose de complexe, notamment `a cause de la pr´esence de caches sur les processeurs. Pour ne pas se soucier de ce probl`eme pendant l’impl´ementation de l’OS, nous dirons que le nombre d’instructions ex´ecut´ees doit ˆetre pr´evisible, et non le nombre de cycles. L’id´ee est que si on peut donner un majorant au nombre d’instructions ex´ecut´ees, c’est que l’on connait les diff´erents chemins d’ex´ecutions, et qu’une analyse pouss´ee permettrait de donner un majorant du nombre de cycles utilis´es.

Cela ne signifie pas pour autant qu’il faille compter le nombre d’instructions travers´ees par chaque appel syst`eme ; cela signifie qu’il doit ˆetre possible de donner un majorant `a ce nombre d’instructions si n´ecessaire.

En particulier, le temps d’ex´ecution d’une tˆache ne devrait pas d´ependre de l’ex´ecution des autres tˆaches (ou de mani`ere born´ee). C’est `a dire que les tˆaches doivent ˆetre non seulement prot´eg´ees contre le d´eni de service, mais ´egalement contre tout « ralentissement » de service. Cette condition est donc tr`es stricte. Un autre exemple de temps d’ex´ecution qui d´epend des autres tˆaches est l’usage d’un cache logiciel global. Les tˆaches temps r´eel ne devraient pas d´ependre de l’utilisation d’un tel cache (et devraient par exemple se constituer leur cache elle-mˆeme).

Notons que les majorants sur le nombre d’instructions travers´ees d´epend de la complexit´e th´eorique de l’appel syst`eme. Si l’appel syst`eme est en O(1), ce majorant sera une constante a. Si il est en O(n), il sera de la forme a ∗ n + b, si en quadratique de la forme a∗n2

+b∗n+c, etc. Dans Anaxagoros, le temps d’ex´ecution de quasiment tous les appels de service est en temps constant (O(1)), donc hautement pr´evisible ; y compris pour la r´ecup´eration de ressources ou terminaison d’autres tˆaches.

3.1.2. Assurance d’une ex´ecution correcte

Notons qu’il faut ´egalement pr´evoir le temps CPU n´ecessaire pour les « processus syst`emes » (par exemple, le filtre de paquets r´eseaux) ; tout comme il faut pr´evoir la m´emoire pour les services du syst`eme.

La question de la pr´evisibilit´e des caches est pour nous une pr´eoccupation s´epar´ee. Elle est de la responsabilit´e du logiciel par les politiques d’allocation CPU (e.g. quotas de temps assez longs), et m´emoire (e.g. page coloring [LHH97]), et du calcul de WCET.

R´evocation imm´ediate Une op´eration particuli`ere qui devrait se faire en temps pr´evisible est la suppression d’une tˆache, i.e. la r´ecup´eration de toutes ses ressources. C’est un cas particulier de la r´ecup´eration d’une partie des ressources accord´ee `a une tˆache. La r´ecup´eration d’une ressource d’une tˆache consiste `a r´evoquer `a la tˆache l’usage de cette ressource.

Dans Anaxagoros, nous avons choisi qu’autant que possible la r´evocation se fasse en temps constant court. Cette d´ecision offre plusieurs avantages : le red´emarrage d’une tˆache se fait en temps court, ce qui est important pour le recouvrement d’erreur [Den76] ; il est ´egalement important que la suppression de programmes qui tentent un d´eni sur les ressources se fasse en un temps court [SP99, § 1]. De plus, cette d´ecision simplifie et rend plus efficace l’allocation des ressources : par exemple, on peut donner beaucoup de m´emoire aux tˆaches non-critiques si on sait qu’on pourra reprendre cette m´emoire rapidement si une tˆache critique en a besoin.

Ce principe apporte cependant des difficult´es d’impl´ementation ; en particulier, lorsqu’on supprime une tˆache qui avait prˆet´e des ressources `a un service partag´e, le service partag´e doit ˆetre prˆet `a ce que ces ressources soient soudainement r´evoqu´ees. Nous appelons cela la « r´evocation forc´ee ». Cette d´ecision impacte fortement la conception des services (§ 3.5).

3.1.2.3 Principe : Erreurs pr´evisibles

Ce principe ´enonce tout simplement qu’une application devrait pouvoir pr´edire si un appel syst`eme va r´eussir. En particulier, cela ne devrait pas d´ependre des agissements des autres tˆaches. La seule exception, importante, est lorsqu’une demande d’allocation est refus´ee.

Regardons l’appel syst`eme mmap sous Linux : il peut ´echouer pour une quantit´e de raison, certaines pr´evisibles (file descriptor invalide, protection incorrecte), certaines non (nombre maximum de mappings du processus exc´ed´e, limite sur le nombre de fichiers ouverts dans le syst`eme exc´ed´ee).

Dans Anaxagoros, les seules demandes qui peuvent ´echouer sont les demandes d’allocation. On s´epare les appels de service pour les demandes d’allocation et d’utilisation des ressources. Ainsi, lorsqu’on a toutes les ressources n´ecessaires, tous les appels de service service r´eussissent, sauf en cas d’utilisation incorrecte (mauvais param`etres, appels dans le mauvais ordre, etc.). Cela permet de garantir `a une tˆache critique dont toutes les ressources ont ´et´e allou´ees qu’elle va toujours ex´ecuter son traitement correctement, mˆeme lorsque celui-ci demande de faire des appels de service.

Ce principe permet ´egalement d’ex´ecuter plusieurs appels syst`emes en lot plus facilement, puisqu’on sait que les appels vont r´eussir. Nous exploitons cette propri´et´e pour le m´ecanisme de multicall (§ 3.3.3.2).