Comparaison et conclusion sur le contrˆole d’acc`es

Ces deux derni`eres m´ethodes permettent de garantir l’absence de propagation des droits entre partitions sans avoir `a faire confiance au code des services partag´es.

3.3.5 Comparaison et conclusion sur le contrˆole d’acc`es

Levy fournit une retrospective des difficult´es dans l’impl´ementation des syst`emes `a capacit´e [Lev84, chapter 10], que nous cat´egorisons en deux parties : la recherche d’un objet et sa destruction.

Recherche d’un objet Une capacit´e doit contenir un identifiant pour un objet, autrement dit l’adresse, d’un objet. Les premiers syst`emes `a capacit´es n’´etaient pas orient´es objets, et les capacit´es contenaient alors des descripteurs de segments. Mais cela pose des probl`emes lorsqu’un objet doit ˆetre d´eplac´e en m´emoire.

Les syst`emes plus r´ecents utilisent une table centralis´ee interm´ediaire, utilis´ee pour stocker diff´erentes informations [Lev84, § 10.4]. En particulier, ces tables sont utilis´ees pour retrouver le type de l’objet, qu’il faut connaˆıtre pour impl´ementer l’op´eration typecall. Ces tables fournissent ´egalement un degr´e d’indirection, permettant de faire du swapping des objets de mani`ere transparente. Mais le probl`eme principal de ces tables est qu’elles sont de taille fixe : ainsi l’allocation d’entr´ee dans cette table doit ˆetre r´egie par une politique d’allocation. CAL/TSS utilisait FCFS [LS76, § 6.3] ; d’autres consid`erent les entr´ees dans cette table comme un cache (e.g. EROS [Sha99], CAl/TSS [LS76]).

Notre m´ecanisme peut ˆetre vu comme l’impl´ementation d’une table distribu´ee sur chaque service, en stockant le service de destination dans la capacit´e. Chaque service impl´emente le format de table qu’il d´esire, ou aucune table s’il le souhaite : les tables ne sont pas interpr´et´ees par le noyau. L’adresse d’un objet est repr´esent´ee par le couple (service, num´ero d’objet)17

. Ainsi le noyau se contente-t-il de transmettre les requˆetes au type indiqu´e par la capacit´e, toute autre op´eration ´etant d´el´egu´ee `a ce type. Cela suit le principe de minimisation des m´ecanismes communs (§ 2.2.2.6), simplifiant le noyau et rendant le m´ecanisme de capacit´es plus flexible. Notons que ce syst`eme ne demande pas `a ce que les capacit´es aient une taille importante : nos capacit´es font chacune 16 octets. `A titre de comparaison sur mˆeme mat´eriel, les capacit´es d’EROS font 32 octets [SSF99, § 4.1] et celles de seL4 font ´egalement 16 octets [EDE08, § 3.2.2].

Le d´esavantage est que le service est d´esign´e par son adresse physique, ce qui empˆeche son d´eplacement en m´emoire ou swapping du domaine. Cela ne pose pas de probl`eme sur les applications que l’on vise : soit le syst`eme est tr`es contraint en m´emoire (e.g. automobile), et en g´en´eral statique et tient enti`erement en RAM ou ROM ; soit il est destin´e au hardware moderne, qui disposent de plus d’1Go de m´emoire et o`u la perte de quelques kilo-octets n’est pas un probl`eme.

Notons que le contenu du service peut ˆetre swapp´e. Par exemple, toutes nos capacit´es sur des objets syst`emes (threads, espaces d’adressages, etc.) pointent directement sur des adresses physiques. Il semble faisable d’impl´ementer un service en espace utilisateur de « proxy noyau », qui constituerait un cache m´emoire de

17

certains objets en pla¸cant les autres sur le disque, et agirait comme un proxy transparent sur les requˆetes des applications.

Notons ´egalement notre m´ecanisme de multicall, qui permet d’appeler plusieurs m´ethodes successivement sans avoir `a r´e-ex´ecuter tout le m´ecanisme de recherche d’objet. Ce m´ecanisme permettra au service d’impl´ementer des m´ethodes plus simples (§ 5.4.3).

Destruction d’un objet Une deuxi`eme difficult´e est la destruction d’un objet. Lorsqu’un objet o1 est d´etruit, les ressources (m´emoires, place dans une table des

objets) sont r´eutilis´ees pour un autre objet o2. Il ne faut pas que les capacit´es pour

o1 puissent ˆetre utilis´ees pour acc´eder `a o2.

Il y a diff´erentes m´ethodes pour ´eviter cela [Lev84, § 10.4]. Certains syst`emes interdisent la destruction d’un objet tant qu’il reste des capacit´es pointant sur cet objet (i.e. avec des compteurs de r´ef´erences) ; mais cela permet `a des programmes malicieux d’empˆecher la r´eutilisation de ressources. D’autres d´etruisent toutes les capacit´es qui pointent vers un objet pour le d´etruire (backpointers), mais cette op´eration prend un temps non born´e (e.g. seL4 [EDE08, § 3.2.2]). Ces deux m´ethodes ne permettent pas d’obtenir une destruction des ressources en temps pr´evisible (§ 3.1.2.2).

Certains syst`emes (e.g. Hydra et Systeme 38 [Lev84, p. 194], CAL/TSS [LS76, § 3.5]) utilisent un identifiant unique pour chaque objet : ainsi quand un objet est d´etruit, les capacit´es existantes ont un identifiant qui ne sera jamais r´eutilis´e. Le probl`eme est que le nombre de ces identifiants est large par rapport aux nombres d’objets pr´esents dans le syst`eme, d’o`u l’utilisation de tables de hachages, qui rajoutent un surcoˆut pour l’utilisation de capacit´es.

Notre m´ecanisme suit cette m´ethode d’identifiant unique pour chaque objet ; la diff´erence est que cet identifiant n’est pas un seul nombre, mais un triplet (service, num´ero d’objet, date). En d’autres termes, l’identifiant unique se fait tout simplement en rajoutant une date aux capacit´es et aux objets. Nous avons g´en´eralis´e ce m´ecanisme par la notion de pointeur estampill´e (§ 3.3.3.1). Enfin, notre m´ecanisme utilise la mˆeme date pour le contrˆole de l’acc`es au service par le noyau, et le contrˆole de l’acc`es `a l’objet par le service, r´eduisant ainsi la place n´ecessaire pour les capacit´es.

Cette id´ee de rajout d’une date pour identifier uniquement un objet peut ˆetre rapproch´ee des « allocation counts » d’EROS [Sha99, p. 102]. Les diff´erences sont que dans EROS ces dates sont stock´ees dans une table centrale ; les entr´ees sont allou´ees par caching contrˆol´e par le noyau, donc l’allocation count peut ne faire que 32 bits ; et il y a toujours besoin de « backpointers » lorsqu’un objet est sorti du cache [Sha99, p. 103], l’allocation count servant seulement `a ´eviter de modifier les capacit´es situ´ees sur le disque dur.

Conclusion sur le contrˆole d’acc`es Nous avons termin´e l’explication de la conception de notre m´ecanisme de capacit´es, utilis´e pour tout le contrˆole d’acc`es dans le syst`eme. Il a comme caract´eristiques d’ˆetre simple et flexible, de ne pas n´ecessiter de table centrale, et de permettre la r´evocation d’objet (et invalidation de toutes les capacit´es qui s’y rapportent) en temps constant, ce qui suit les principes ´enonc´es pour cette th`ese.