Flexibilit´e et extensibilit´e s´ecuris´ee

programme qui peut commettre l’erreur), ce qui rend la gestion d’erreurs plus modulaire.

Cette approche est la pr´ef´erable pour les tˆaches critiques, qui ne sont pas cens´ees commettre d’erreur.

Mˆeme si la derni`ere option est pr´ef´erable pour des tˆaches critiques, de nombreux programmes sont con¸cus pour g´erer eux-mˆemes leurs erreurs, ou que leurs erreurs soient corrig´ees par l’OS. Nous proposons pour cela que la gestion des erreurs soit param´etrable, i.e. qu’on puisse configurer pour chaque « type » d’erreur la tˆache qui en soit avertie. Par exemple, pour chaque exception (d´efaut de page, division par z´ero, instruction ill´egale ...), un pseudo appel de service est ex´ecut´e qui renvoie le thread dans le gestionnaire correspondant. Ce m´ecanisme est similaire aux « domaine keeper keys » dans Keykos [Har85]. Les « pagers » de Mach [ABG+

86] suivent une approche similaire, mais limit´ee `a la seule exception « d´efaut de page ».

Comme nous l’avons vu pr´ec´edemment, si un appel de service renvoie une erreur c’est parce que la tˆache n’utilise pas le service de mani`ere correcte. Des exemples de telles erreurs sont EBADARG (argument invalide) ou ECONCURRENCY (d´etection de concurrence interdite). Il faudrait pouvoir rajouter optionellement un appel `a un gestionnaire d’erreur lorsqu’une telle erreur est d´etect´ee (nous ne l’avons pas impl´ement´e, bien que cela soit simple `a effectuer).

Notons qu’il peut parfois ˆetre plus efficace (en temps CPU) de corriger l’erreur de mani`ere silencieuse plutˆot que de la d´etecter. Ainsi, la v´erification qu’une valeur x appartient `a un intervalle peut parfois ˆetre remplac´ee par la transformation de x `a l’aide d’un masque. Dans la mesure du possible, il faut ´eviter de recourir `a cette technique ; ces micro-optimisations peuvent ´eventuellement ˆetre faites de mani`ere conditionnelles.

3.1.4 Flexibilit´e et extensibilit´e s´ecuris´ee

Les principes suivants sont importants pour pouvoir adapter le syst`eme aux besoins, et l’´etendre sans compromettre l’existant.

3.1.4.1 Principe : Ind´ependance des politiques de s´ecurit´e

Tout comme le syst`eme est ind´ependant des politiques d’allocation, il devrait ´egalement ˆetre ind´ependant des politiques de s´ecurit´e. Rushby a montr´e qu’on pouvait exprimer des politiques de s´ecurit´e selon une formulation bas´ee sur la « non-interf´erence » dans laquelle la relation d’interf´erence (e.g. possibilit´e de com- muniquer) pouvait ˆetre non-transitive [Rus92]. En pratique, cela peut ˆetre r´ealis´e par le contrˆole des canaux de communications (channel control) et l’utilisation de tˆaches de confiances qui agissent comme des filtres interm´ediaires. Si on suppose que toute politique peut ˆetre exprim´ee `a l’aide de cette formulation, il suffit au noyau d’assurer la s´eparation des tˆaches et de fournir un moyen `a l’espace utilisateur de contrˆoler les communications.

Les politiques de s´ecurit´e peuvent ˆetre construites statiquement en ins´erant des programmes de confiances qui jouent le rˆole de m´ediateur [Rus81, AFHOT06,

BDRS08], ou en cr´eant dynamiquement des nouveaux canaux et domaines d’isolation [WCC+

74, MS03].

3.1.4.2 Principe : Garantie de limitation de la port´ee des extensions Il faut fournir l’assurance que l’ajout d’une extension a une port´ee limit´ee : i.e. o`u on puisse pr´edire quelles sont les tˆaches affect´ees par l’extension, et lesquelles ne le sont pas. En particulier, il doit ˆetre possible d’assurer que l’ajout d’une extension ne modifie pas le comportement des tˆaches pr´e-existantes `a cet ajout.

Ce principe est important, car il permet de fournir des garanties sur l’ex´ecution des programmes de mani`ere compositionelle : lorsqu’une extension est ainsi ajout´ee, la re-certification ou re-qualification ne concerne que les tˆaches qui sont affect´ees par cette extension. Les autres tˆaches sont garanties de conserver le mˆeme comportement.

Des approches qui suivent ce principe sont l’extensibilit´e par les libOS dans les exonoyaux (port´ee limit´ee `a l’application), par la modification de serveurs dans les micronoyaux ou de domaines de protections dans MILS (port´ee limit´ee aux tˆaches qui en d´ependent [HPHS04, BDRS08]), ou la modification d’un noeud dans les structures hi´erarchiques (§2.4.3.2) (port´ee limit´ee aux descendants de ce noeud). Notons cependant qu’`a part pour MILS, ces extensions peuvent induire des modifications dans l’allocation des ressources (e.g. pr´esence de s´emaphores possibles), et donc modifient le comportement de l’existant.

Des contres exemples sont l’ajout de modules au noyau dans Linux ou Windows1

. Il est potentiellement possible de construire des extensions dont la port´ee est limit´ee avec des approches qui chargent du code dans le noyau de mani`ere contrˆol´ee (e.g. SPIN [BSP+

95]) ; mais il est certainement tr`es difficile d’arriver `a l’assurer.

3.1.4.3 Principe : pas de contraintes de temps impos´ees par le syst`eme aux applications

Certains syst`emes imposent de faire certaines actions dans un temps limit´e. Certains syst`emes peuvent demander `a des tˆaches de faire des actions, et doivent limiter le temps pour faire cette action pour qu’il n’y ait pas accaparation de temps CPU. Par exemple, L4 permet de sp´ecifier des timeouts pour ses RPC [Sha03] ; Genode/Bastei demande aux services de lib´erer les ressources en temps limit´e [FH06, p. 8] ; certains syst`emes ont une notification de pr´eemption imminente, ou accordent un sursis d’ex´ecution limit´e (§ 4.1.2.1).

Le probl`eme est qu’il est tr`es difficile de pr´evoir si un traitement peut ˆetre fait en un temps donn´e. Si il faut le faire pour les tˆaches temps r´eel critiques, il est d´ej`a assez difficile de prendre en compte les contraintes de temps impos´ees par les sp´ecifications ; il vaut mieux ´eviter d’imposer ainsi des contraintes suppl´ementaires. De plus, ces temps d´ependent de diff´erents facteurs dont la vitesse d’ex´ecution du processeur ; ainsi le code n’est pas portable entre processeurs de vitesses diff´erentes. Ce type de contraintes est donc `a proscrire ; il faut trouver un moyen d’organiser la conception pour ne pas en avoir besoin.

3.2. STRUCTURE

Conclusion sur ces principes

Nous avons propos´e un certain nombre de principes `a respecter pour un OS qui puisse ex´ecuter de mani`ere performante et s´ecuris´ee des applications de criticit´e h´et´erog`enes. En particulier, les trois premiers groupes de principes vont :

1. Fournir l’assurance que les tˆaches critiques disposeront d’assez de ressources pour s’ex´ecuter, par l’allocation d´eterministe et la simplicit´e dans l’allocation ; 2. Fournir l’assurance d’une ex´ecution correcte aux applications qui disposent

d’assez de ressources ;

3. Pouvoir agir en cas d’erreur, en impl´ementant une proc´edure de recouvrement s´ecuris´ee.

Mis ensemble, ces principes permettent d’assurer pour une tˆache une ex´ecution correcte `a priori (une fois les ressources n´ecessaires pour la tˆache connues), et une surveillance du bon fonctionnement de la tˆache. Ce sont ces principes qui permettent au syst`eme de supporter des tˆaches critiques.

Les principes de flexibilit´e et d’extensibilit´e s´ecuris´ee facilitent la r´eutilisation et l’adaptation du syst`eme aux besoins. Ce sont eux qui permettent l’ex´ecution de tˆaches critiques et non critiques arbitraires. L’ind´ependance des politiques d’allocation permet ´egalement d’apporter performance et flexibilit´e, et aurait donc pu ˆetre rattach´e `a ce groupe de principes.

Une fois ces principes ´enonc´es, il reste `a trouver une conception qui permette de tous les combiner. Mˆeme si les principes r´eduisent les choix possibles, les conceptions qui les suivent peuvent ˆetre vari´ees, comme le donne l’exemple des syst`emes pour la s´ecurit´e. Dans le reste de ce chapitre (et de cette th`ese), nous pr´esentons une conception qui suit simultan´ement tous ces principes.

Notons que les deux rˆoles du syst`eme d’exploitation ´etant la s´ecurit´e et l’allocation des ressources, un syst`eme ´etant ind´ependant des politiques pour ces deux rˆoles est extrˆemement flexible. La seule contrainte que l’OS impose aux applications est l’interface `a utiliser pour utiliser les m´ecanismes (i.e. la mani`ere de sp´ecifier les droits d’acc`es `a une ressource).

3.2

Structure