3.4.3 Prˆet de capacit´es
Motivation Nous voyons maintenant comment prˆeter les autres ressources (parta- g´ees spatialement). L’acc`es `a ces ressources se faisant par capacit´es, il suffit de prˆeter des capacit´es pour prˆeter une ressource. Le prˆet de capacit´es consiste `a donner au service la possibilit´e d’invoquer la capacit´e pendant la dur´ee du prˆet.
Le prˆet de capacit´es a d’autres utilit´es que le prˆet de ressource. Il permet par exemple de donner au service la possibilit´e de communiquer avec une troisi`eme entit´e (on utilise par exemple cela pour permettre au service de notifier l’ordonnanceur du client). On fournit ´egalement au service une capacit´e de retour, pour que le thread puisse retourner au client. On peut ´egalement penser utiliser les capacit´es comme jeton d’authentification. La transmission de capacit´e est quelque chose de tr`es naturel dans les syst`emes `a capacit´es, et tous les syst`emes le permettent. Allocation d’entr´ees dans la C-list du service La solution naturelle pour prˆeter une capacit´e est de la copier dans la C-list du domaine du service depuis la C-list du domaine du client, et de la supprimer une fois le prˆet termin´e. Mais proc´eder ainsi pose diff´erents probl`emes :
• de stockage : les capacit´es prˆet´ees remplissent la C-list du service, qui est de taille finie. Les allouer au fur et `a mesure serait un exemple typique d’utilisation de FCFS, et donc de vuln´erabilit´e aux d´enis de ressource. Il faut donc une politique d’allocation sur les entr´ees de la C-list, qui est p´enible `a ´ecrire ; • de gestion : si on met en place une politique des entr´ees dans la C-list, cette
politique est impl´ement´ee par le service. Or, c’est le noyau qui place les capacit´es dans la C-list, et ce au moment de l’invocation, i.e. sans que le service ne sache encore « qui est le client ». Pour g´erer convenablement les entr´ees dans la C-list, il faudrait mettre en place un protocole d’´echange entre le noyau et le service, qui risque d’ˆetre complexe et peu efficace ;
• de s´ecurit´e : rien n’empˆeche un service en train d’ex´ecuter la requˆete d’un client C1 d’utiliser la capacit´e donn´ee par un client C2, ce qui contredit le
principe du moindre privil`ege (§ 2.2.2.4).
C-list dans les threads Le meilleur moyen de r´esoudre ce probl`eme est de prˆeter des places de C-list. C’est la raison pour laquelle le thread contient ´egalement une C-list dans notre syst`eme.
Le prˆet de ressources se d´eroule ainsi (voir Figure 3.10) : le client copie tout d’abord ses capacit´es depuis son domaine vers le thread courant. Puis il transmet son thread au service, ce qui signifie que le service peut utiliser les capacit´es pr´esentes dans le thread (en plus du temps CPU et des mappings m´emoires du thread d´ej`a mentionn´es). Enfin, le service rend le thread au client, en invoquant la capacit´e de retour [SFS96] ins´er´ee par le noyau lors du prˆet du thread (dans la C-list du thread, et non celle du domaine du service). Toute capacit´e transmise du service au client peut ´egalement ˆetre transf´er´ee par l’interm´ediaire de la C-list du thread. Cette
Domaine du client A Thread A C-list C-list Domaine du service C-list
(a) Le client copie les capacit´es `a prˆeter de la C-list de son domaine vers celle de son thread
Domaine du client A C-list Domaine du service C-list Thread A C-list Thread B C-list
(b) Le client prˆete son thread au service. Une capacit´e de retour est ins´er´ee par le noyau dans la C-list du thread prˆet´e. Si le thread est preempt´e, l’ex´ecution recommence dans le service. D’autres clients peuvent simultan´ement prˆeter leur thread au service.
Domaine du client A C-list Thread A C-list Domaine du service C-list Thread B C-list
(c) Le service invoque la capacit´e de retour, et le thread retourne au client. Le service peut ´eventuellement avoir copi´e des capacit´es dans le thread avant de ce faire.
3.4.3. Prˆet de capacit´es
solution r´esout tous les probl`emes mentionn´es ci-dessus pour les prˆets de capacit´es transitoires.
Mais on ne peut pas prˆeter un thread entre plusieurs appels de service par nature, donc cette solution ne se prolonge pas pour les prˆets semi-permanents. Pour ces derniers il est toujours n´ecessaire d’´ecrire une politique d’allocation des places dans la C-list du domaine. Cependant, cette politique est maintenant beaucoup plus simple `a ´ecrire : comme le service a la connaissance du client, il lui suffit de demander au noyau de copier les capacit´es de la C-list du thread vers celle de son domaine lorsque c’est n´ecessaire. Notre m´ecanisme r´esout donc aussi le probl`eme de gestion pour les prˆets semi-permanents.
Un probl`eme dont nous n’avons pas parl´e est la r´evocation des capacit´es prˆet´ees au service. En effet `a la fin de l’appel, une capacit´e prˆet´ee de mani`ere transitoire `a un service ne doit plus ˆetre utilis´ee par le service ; suivant le principe du moindre privil`ege (§ 2.2.2.4), le service ne devrait mˆeme plus invoquer cette capacit´e. Ce droit est retir´e automatiquement par le prˆet de thread ; faire de mˆeme par copie de capacit´e entre domaines requiert l’utilisation de sch´emas plus complexes comme le « caretaker pattern » de Redell [Red74, p. 40].
Analogie avec le mod`ele objet Le mod`ele par prˆet de thread est analogue `a l’impl´ementation de l’appel de m´ethode passif du mod`ele objet, par exemple dans des langages comme C++. Dans celui-ci, la pile contient des donn´ees locales au calcul courant, et l’objet encapsule des donn´ees partag´ees entre plusieurs calculs. L’appel de m´ethode utilise la pile pour passer des arguments entre les objets. Dans notre mod`ele par passage de thread, les capacit´es sont analogues aux donn´ees, le thread `a la pile, les domaines aux objets, et l’appel de service `a l’appel de m´ethode. Dans les langages sˆurs, l’analogie va encore plus loin : un objet doit disposer d’une r´ef´erence pour pouvoir appeler un autre objet, tout comme une capacit´e vers un service est n´ecessaire pour pouvoir l’appeler.
Le mod`ele de programmation objet est bien connu des programmeurs, ce qui permet au mod`ele de s´ecurit´e par prˆet de thread de suivre le principe d’acceptation psychologique (§ 2.2.2.7). Il leur est plus naturel qu’un appel par communication synchrone, qui serait l’´equivalent dans le mod`ele objet d’un appel actif d’une m´ethode prot´eg´ee par un « monitor ».
Notre mod`ele d’invocation est donc extrˆemement naturel pour des syst`emes `a capacit´es, qui sont ´etroitement li´es `a la conception orient´ee objet (voir par exemple [Lin76, Lev84, MYS03]).
Analogie avec le prˆet de m´emoire Le prˆet de m´emoire transitoire que nous avons d´ecrit pr´ec´edemment est ´egalement proche du prˆet de capacit´es. Une entr´ee dans une table des pages peut en effet ˆetre consid´er´ee comme un droit d’acc`es `a la m´emoire, et la table des pages est ainsi une sorte de C-list. Les diff´erences sont qu’il y a des garanties suppl´ementaires `a fournir pour la m´emoire (le fait qu’un mapping n’est pas partag´e), et le fait que les mappings m´emoire sont interpr´et´es directement par le mat´eriel, au contraire des capacit´es.
3.4.4 Prˆet de m´emoire semi-permanent
Pr´esentation et applications Nous abordons maintenant un dernier type de prˆet de ressource, le prˆet de m´emoire semi-permanent. Ce type de prˆet est utile lorsqu’un service a besoin d’un buffer de donn´ees pour servir un client ; en ce cas le client fournit toute la m´emoire n´ecessaire pour ce buffer. Un exemple de tel prˆet de m´emoire peut ˆetre vu dans l’impl´ementation de la pile r´eseau dans EROS de Sinha, Sarat et Shapiro [SSS04]. D’autres utilisations peuvent ˆetre l’´etablissement de communication par m´emoire partag´ee entre deux tˆaches.
Cas particulier du noyau Un cas particulier de prˆet de m´emoire semi-permanent est le prˆet de m´emoire au noyau, qui permet de r´esoudre le probl`eme de l’allocation de m´emoire noyau (§ 2.1.2.2). Notre solution pour ce probl`eme consiste tout simplement `a demander au noyau de convertir certaines pages en d’autres (table des pages, domaines, threads). Cette op´eration est simplifi´ee par le fait que tous les objets syst`emes sont de taille une page (§ 3.2.3.2). Cette conception est similaire `a celle Xen [BDF+
03] ou encore de seL4 [EDE08]. L’annexe C en d´etaille l’impl´ementation. Trusted mapping object La m´emoire prˆet´ee se fait en utilisant un « trusted mapping object » (TMO), qui fait office d’interm´ediaire de confiance entre le client et le service. Le service ne peut accorder aucune confiance au client ni aux capacit´es qu’il envoie. On pourrait demander au client de faire confiance au service, mais le service de politique m´emoire qui fournit la m´emoire au client ne peut pas faire confiance au service pour qu’il lui rende de la m´emoire si n´ecessaire. Il doit donc y avoir un moyen de forcer la r´ecup´eration de la m´emoire. `A partir de cela, il est aussi simple de permettre au client lui-mˆeme de r´ecup´erer la m´emoire. Le TMO permet ainsi au service d’utiliser la m´emoire prˆet´ee en toute confiance, et fournit au client (ou son fournisseur de m´emoire) l’assurance de pouvoir r´ecup´erer la m´emoire `a tout moment.
Le fonctionnement g´en´eral est le suivant. Le client s´electionne un certain nombre de pages, et demande au service de m´ecanisme m´emoire de les « transformer » en TMO. Il re¸coit en ´echange une capacit´e. Il transmet cette capacit´e au service (en retirant quelques droits). Le service invoque alors cette capacit´e23 pour installer
les pages prˆet´ees par le client ; une fois install´e, le mapping n’est plus modifiable. Le service v´erifie que les droits d’acc`es sur les mappings sont param´etr´es comme il le souhaite, puis peut commencer `a les utiliser. Si le client veut r´ecup´erer la m´emoire prˆet´ee, il invoque sa capacit´e (non amoindrie) pour supprimer le TMO, ce qui supprime ´egalement le mapping du service, et invalide toutes les capacit´es vers le TMO.
3.4.4.1 Conception
Le trusted mapping object est seulement une table des pages de deuxi`eme niveau particuli`ere, qui permet seulement de fournir des assurances sur le nombre de mappings install´es.