Principes pour la flexibilit´e

API de haut niveau (comme POSIX) syst`eme grˆace `a l’usage de librairies ou de tˆaches syst`emes d´edi´ees (e.g. [KEG+

97, ABG+

86, BFF+

92]).

2.4.3 Principes pour la flexibilit´e

Nous pr´esentons maintenant deux principes qui nous semblent fondamentaux pour la flexibilit´e du syst`eme. Cette liste n’est pas exhaustive ; en particulier nous en avons exclu toutes les techniques qui demandent une modification dynamique du code d’un domaine de protection. Ces techniques posent un probl`eme de s´ecurit´e : la moindre faute dans le code qui installe la modification du code peut avoir des cons´equences impr´evisibles. Cela les rend difficile `a certifier.

2.4.3.1 Separation de la politique et du m´ecanisme

Pr´esentation Le principe de s´eparation de la politique du m´ecanisme a ´et´e ´enonc´e par Levin et al. pour le syst`eme Hydra [LCC+

75]. Mais cette id´ee remonte au moins `

a Brich Hansen [Han70].

Le syst`eme d’exploitation d´efinit des r`egles qui s’appliquent `a toutes les tˆaches du syst`eme. Ce principe demande la s´eparation entre les politiques « sp´ecifiques », qui peuvent changer selon l’utilisation qu’on a du syst`eme, et les m´ecanismes « g´en´eriques » qui s’appliquent `a toute utilisation et servent de support `a l’impl´emen-

tation des politiques.

Application `a la s´ecurit´e Une application de ce principe `a la s´ecurit´e est la s´eparation de la protection et du m´ecanisme [WCC+

74]. Nous avons vu (§ 2.2.2) que la s´ecurit´e reposait sur des principes communs, comme la s´eparation en domaines, le contrˆole d’acc`es... Tout syst`eme d’exploitation pour la s´ecurit´e doit donc impl´ementer ces m´ecanismes. Au contraire, le contrˆole sur les communications entre les tˆaches d´epend des utilisations.

Ainsi, on peut s´eparer le syst`eme en une partie « m´ecanismes protection » (qui impl´emente les domaines de protection, le contrˆole d’acc`es et les liens de communication) et une partie « politique de s´ecurit´e » (qui peut ˆetre de la politique multiniveau militaire, ou tout autre politique). L’approche « distribu´ee » de Rushby [Rus81] et les syst`emes `a capacit´es [MS03] impl´ementent cette s´eparation, au contraire des « security kernels ».

Application `a l’allocation des ressources Pour l’allocation des ressources, cela consiste `a ce que les applications utilisateur puissent red´efinir la politique d’allocation pour une ressource, en ne gardant dans le noyau que les m´ecanismes permettant d’impl´ementer ces politiques.

Mais cette s´eparation est souvent incompl`ete. Ainsi, dans Hydra, certains m´ecanismes ne sont que des politiques param´etrables. Pire, chaque programme “d´efinit” sa politique, donc le noyau contient toujours une politique pour garantir l’´equit´e de l’allocation entre applications. Nous ´enon¸cons que la d´efinition de sa propre politique est impossible, et ne peut ˆetre r´eellement qu’un moyen ´evolu´e de faire des demandes d’allocation.

Nous estimons que pour que la s´eparation politique et m´ecanisme soit compl`ete, il est n´ecessaire que les politiques soient impl´ement´ees dans des domaines de protection privil´egi´es. La structuration hi´erarchique que nous voyons dans la section suivante, est un moyen pour cette r´ealisation.

Suppression des abstractions Les exonoyaux [EKJO95, KEG+

97, Ros95] et les VMMs [BDF+_{03] repr´esentent une avanc´ee dans la s´eparation de la politique}

et du m´ecanisme. L’id´ee est qu’une interface proche du hardware permet la plus grande flexibilit´e dans la d´efinition de politique d’allocation des ressources [EKJO95, §8]. De plus, cela contribue `a amoindrir la taille du noyau, ce qui tend `a diminuer le nombre de politiques en g´en´eral que le noyau impose aux applications.

Mais mˆeme ainsi, il reste toujours en pratique des politiques dans le noyau. Ainsi, la ”politique racine” de chaque ressource reste g´er´ee par le noyau [EKJO95, §3.1]. De plus, comme pour les syst`emes traditionnels (§ 2.1.2.1), les idiomes de programmation usuels rendent le code et l’allocation de ressources tr`es interd´ependents (e.g. usage de FCFS, malloc et s´emaphores dans le noyau, etc.).

2.4.3.2 Structuration hi´erarchique

Pr´esentation Dans un exonoyau, on peut changer une d´ecision de conception relative `a une tˆache en changeant sa ”libOS”, et changer une d´ecision de conception (i.e. politique) relative `a toutes les tˆaches en changeant le noyau. On se demande maintenant comment changer une politique relative `a un sous-ensemble de toutes les tˆaches.

La structuration hi´erarchique (voir Figure 2.3) apporte une r´eponse `a cette question. L’id´ee g´en´erale est de structurer les tˆaches ou domaines de protection du syst`eme selon un arbre. Chaque noeud de l’arbre peut d´eterminer une politique, qui s’applique `a tous les descendants de ce noeud (inversement, chaque noeud a sa politique d´efinie par l’ensemble de ses ancˆetres).

L’int´erˆet de la technique est de pouvoir faire coexister des politiques diff´erentes sur des groupes de tˆaches diff´erentes. Ces politiques sont elles-mˆeme coordonn´ees par le noeud qui est l’ancˆetre commun `a ces deux politiques. De plus, un noeud ne d´epend que de ses ascendants directs, et pas de ses fr`eres, oncles, grand-oncles... Cela permet de limiter, pour chaque tˆache, l’ensemble des tˆaches auxquelles il faut faire confiance pour fonctionner correctement.

Mono et multi-hi´erarchie La mani`ere classique de proc´eder est de cr´eer une hi´erarchie de tˆaches : c’est ce que nous appellons le syst`eme mono-hi´erarchique. Dans ce syst`eme, chaque tˆache a un seul parent, qui peut changer `a volont´e les politiques de tous ses enfants. Les travaux de Brich Hansen [Han70], CAP [NW77], Fluke [FHL+_{96] ou Genode/Bastei [FH06] sont des syst`emes structur´es de cette mani`ere.}

Les resource containers [BDM99] sont aussi structur´es mono-hi´erarchiquement, mais les noeuds de la hi´erarchies ne sont pas des tˆaches.

Le probl`eme de cette structure est que cela force des politiques ind´ependantes `a co¨ıncider : la relation hi´erarchique doit ˆetre la mˆeme pour les domaines de protection, l’allocation m´emoire, ou l’ordonnancement CPU. Cela limite la flexibilit´e du syst`eme

2.4.3. Principes pour la flexibilit´e Politique racine M´ecanisme Politique Partition 2 Politique Partition 1

Tˆache 1 Tˆache 2 Tˆache 3 Tˆache 4 Tˆache 5

Partition 1 Partition 2

Fig. 2.3 – Structuration hi´erarchique. La partie rouge est l’ensemble du code auquel le client 4 fait confiance pour correctement impl´ementer sa politique. En particulier, le code impl´ementant la politique de la partition 1 n’en fait pas partie.

[WCC+

74, p. 338]. On obtiendrait donc une plus grande flexibilit´e en ayant des hi´erarchies ind´ependantes pour chaque politique, ce que nous appellons multi- hi´erarchie. Nous ne connaissons pas de syst`eme structur´e de cette mani`ere.

Cas de l’allocation des ressources La structuration hi´erarchique est beaucoup utilis´ee pour la d´efinission des politiques d’allocation de ressources. Par exemple, il est commun de r´eserver diff´erents « pools » de ressources (e.g. m´emoire), et d’allouer les ressources dans ces pools de mani`ere diff´erente. L’int´erˆet de cette technique est que l’allocation dans chaque pool se fait de mani`ere ind´ependante les unes des autres, ce qui apporte s´ecurit´e et flexibilit´e dans l’allocation de ces pools. Mais la s´eparation en plusieurs pools peut ´egalement causer des probl`emes de fragmentation, et donc une perte d’efficacit´e. Cela d´epend de la coop´eration des politiques entre diff´erents niveaux. Il peut donc y avoir compromis entre performance et s´ecurit´e/flexibilit´e.

Ordonnancement hi´erarchique Les types de conditions sur les temps d’ex´ecu- tions peuvent beaucoup varier d’une tˆache `a une autre, comme en t´emoigne l’ensemble des solutions d’ordonnancement vues en section 2.1.3. C’est pourquoi la structuration hi´erarchique s’applique souvent `a l’ordonnancement.

La plupart des syst`emes ne permettent cependant de composer que deux niveaux d’ordonnanceurs de type fix´e. Dans l’avionique, on utilise en allocation racine un ordonnancement statique, et un ordonnancement par priorit´e fixe dans les partitions [Rus98, Aer, KW07]. Les VMMs permettent n’importe quel ordonnanceur en deuxi`eme niveau, et fournissent une allocation ´equitable pour le niveau principal

[BDF+

03]27

. Certains VMMs utilisent la priorit´e fixe (approche priorit´e du critique sur le non critique) comme premier niveau. SPIN permet ´egalement une allocation `a deux niveaux [BSP+

95, §4.2]

Les syst`emes permettant de composer plus de niveaux d’ordonnanceurs sont plus rares. Nous analysons comme un des principaux probl`emes la n´ecessit´e de notifier toute une branche d’ordonnanceur lorsqu’un thread redevient prˆet (ce qui est fait dans [GGV96, §4] et [FS96, §3.2]). De plus ces syst`emes ne permettent souvent pas de choisir le type d’ordonnancement pour tous les niveaux. L’ordonnanceur par bande passante CPU de Goyal et al. [GGV96] impose ainsi d’ordonnancer par d´ecoupage de bande passante sur les premiers niveaux.

Les travaux de Ford et Susarla [FS96] permettent une vraie composition d’ordon- nanceurs arbitraires. Ils ont eu l’id´ee de rendre n’importe quel thread ordonnanceur en lui permettant de donner de son temps `a un autre thread, et des techniques comme le CPU inheritance protocol. Cependant, beaucoup de temps n’est pas compt´e dans leur syst`eme (e.g. le temps de demande de temps CPU), ce qui ne convient pas pour du temps r´eel dur).

2.4.3.3 Conclusion sur la flexibilit´e

Cette section a vu diff´erentes approches qui permettent `a un syst`eme d’exploitation d’ˆetre flexible et extensible de mani`ere s´ecuris´ee, i.e. facilement adaptable `a des besoins diff´erents.

Entre autres techniques, on a vu que les micronoyaux permettaient de rajouter des extensions de mani`ere s´ecuris´ee ; que la suppression des abstraction facilitait l’extensibilit´e de chaque application et supprimait une majorit´e de politiques de l’OS ; que la s´eparation de la politique et du m´ecanisme permettait de conserver un mˆeme m´ecanisme pour diff´erentes politiques ; et que la structuration hi´erarchique permettait d’avoir simultan´ement plusieurs politiques, en les faisant se coordonner. Toutes ces techniques ont ´et´e utilis´ees dans la conception de notre prototype.

Dans cette retrospective, nous nous sommes int´eress´e seulement `a la possibilit´e de cr´eer des extensions, et pas `a la probl`ematique de g´enie logiciel concernant l’interfa¸cage entre ces extensions. Roscoe [Ros95] et Rippert [Rip03] traitent de ce sujet en plus amples d´etails.