Protection m´emoire, temporelle, et des ressources

par le service de politique pour cette ressource. Il lui suffit de changer les capacit´es des tˆaches vers les ressources.

Par contre, les ordonnancements d’acc`es `a des p´eriph´eriques (CPU, r´eseau, disque), ne peuvent se faire ainsi. Pour le temps CPU, nous avons un prototype pr´eliminaire de protocole d’ordonnancement hi´erarchique similaire `a celui de Ford et al [FS96], d´ecrite plus en d´etail en section 3.2.4.2 ; la version non-hi´erarchique consiste seulement `a ce que le service d’ordonnancement CPU puisse programmer des timers pour ˆetre r´eveill´e `a certains instants.

Nous n’avons pas encore d’ordonnancement disque et l’ordonnancement r´eseau est encore tr`es pr´eliminaire ; nous n’avons donc pas encore ´etudi´e comment ces politiques d’ordonnancement pouvaient ˆetre s´epar´ees du m´ecanisme.

3.2.3 Protection m´emoire, temporelle, et des ressources

3.2.3.1 Unit´es de protection et d’allocation

Domaine, threads et espace d’adressage Nous d´ecouplons la protection et l’allocation des ressources en d´ecouplant les objets syst`emes (le thread, le domaine, et l’espace d’adressage) en entit´es ind´ependantes (Figure 3.3).

(a) (b) (c)

(d)

Fig. 3.3 – D´ecouplage des threads, domaines, et espace d’adressages. Diff´erents cas de figures sont repr´esent´es (a) Processus UNIX. (b) Processus UNIX multithread. (c) Domaine changeant d’espace d’adressage ; un espace d’adressage devient inutilis´e, l’autre devient partag´e. (d) Thread se d´epla¸cant entre domaines (similairement aux chemins de Escort [MP96]).

Le domaine (de protection) est l’unit´e principale de protection du syst`eme, et un domaine

principal, i.e. une entit´e d´etentrice de droit, ou encore le sujet du contrˆole d’acc`es. principal

Comme nous impl´ementons un syst`eme `a capacit´e, les capacit´es sont donc attribu´ees `a un domaine. Comme l’acc`es aux ressources spatiales se fait par des capacit´es, le domaine est ´egalement le principal pour le droit d’utilisation de ces ressources.

d’allocation et de protection temporelle). C’est ´egalement un principal, mais est utilis´e ainsi seulement pour la transmission de droits entre domaines ; cet aspect est d´evelopp´e en section 3.4.3. Threads et domaines sont d´ecoupl´es : un thread peut changer de domaine, et un domaine peut ex´ecuter plusieurs threads. Les seules contraintes sont qu’un thread ne peut ˆetre au plus que dans un domaine, il qu’il soit dans un domaine quand il est ex´ecut´e.

Le domaine est ´egalement d´ecoupl´e de la notion d’espace d’adressage. L’espace

espace

d’adressage _{d’adressage est l’entit´e qui contrˆole la translation adresse physique/adresse virtuelle}

et les droits d’acc`es direct `a la m´emoire : c’est donc le principal pour les droits d’acc`es m´emoire (et l’unit´e de protection m´emoire). Ce d´ecouplage est surtout assur´e pour des raisons pratiques : l’impl´ementation de l’espace d’adressage d´epend en effet fortement du hardware. Un domaine est toujours dans un espace d’adressage, mais l’espace d’adressage auquel un domaine est rattach´e peut changer. De plus, il peut y avoir plusieurs domaines pour le mˆeme espace d’adressage.

Le d´ecouplage est r´ealis´e grˆace `a l’utilisation de pointeurs universels (§ 3.3.3.1) entre les diff´erents objets. Ce d´ecouplage est difficile `a r´ealiser dans beaucoup de syst`emes, mais ne pas l’avoir pose des difficult´es (voir par exemple Cache [CD94, § 4.2]).

Int´erˆets du d´ecouplage Cette organisation permet un maximum de flexibilit´e. Il est ainsi possible d’´emuler les processus UNIX classiques (en fixant l’espace d’adressage, le domaine, et le ou les threads), les chemins de Scout (en permettant aux threads de changer de domaine et d’espace d’adressage), ou de faire de la paravirtualisation (les appels syst`emes peuvent ˆetre ´emul´es par un changement de domaine et d’espace d’adressage).

On peut ´egalement comptabiliser les ressources `a une ´echelle « inf´erieure au processus » en cr´eant de nouveaux domaines qui partagent le mˆeme espace d’adres- sage. Il reste cependant `a voir comment attribuer les ressources entre ces diff´erents domaines, et comment comptabiliser les ressources `a une ´echelle sup´erieure `a celle du processus, pour avoir r´esolu le probl`eme de l’inad´equation entre unit´es de protection et d’allocation (§ 2.3.1). Ce sera l’objet de la prochaine section.

Le d´ecouplage entre capacit´e et espace d’adressage est particuli`erement int´eressant. Il permet au syst`eme d’ˆetre ind´ependant du m´ecanisme de protection m´emoire utilis´e (et donc plus facilement portable), et de pouvoir manipuler ce m´ecanisme de pro- tection m´emoire sans imposer d’abstraction. Beaucoup de syst`emes ont combin´e capacit´e et adressage m´emoire ; selon Shapiro c’est souvent source de probl`eme de performance [SSF99, § 1.4.1]. EROS [SSF99] et seL4 [EDE08] ne sont pas lent, mais imposent des abstractions sur l’espace d’adressage (utilisation de cache pour l’un, organisation hi´erarchique par puissance de 2 pour l’autre).

3.2.3.2 Impl´ementation

Nous avons su r´ealiser une impl´ementation tr`es simple de ces m´ecanismes sur l’architecture x86. La protection m´emoire sur cette architecture est bas´ee sur la pagination, avec des pages de 4ko. Le format des tables des pages est d´efini par le hardware, qui se charge d’aller r´ecup´erer les entr´ees dans le TLB. Les tables de pages

3.2.3. Protection m´emoire, temporelle, et des ressources

sont d´efinies sur deux niveaux. Nous appelons table des pages de premier niveau table des pages de premier niveau

la table racine, et tables des pages de deuxi`eme (ou dernier) niveau les autres. Les tables des pages de premier et deuxi`eme niveau font ´egalement 4ko.

Taille unique d’objets syst`emes Tout comme les pages de donn´ees et les tables des pages des diff´erents niveaux, nous avons d´efini que tous les objets syst`emes ´etaient de taille une page. Ce choix de conception a permis de simplifier drastiquement l’impl´ementation du syst`eme de m´emoire virtuelle ; il suit ´egalement notre principe de ressources n´ecessaires pr´evisibles (principe 3.1.2.2).

Ce que nous appelons de mani`ere g´en´erale espace d’adressage est sur x86 une table des pages de premier niveau (donc de taille une page).

Un domaine est repr´esent´e dans le noyau par une structure (appel´ee KDCB, kernel domain control block), de taille une page. Cette structure contient l’adresse physique estampill´ee4

de l’espace d’adressage courant, ainsi que le program counter d’entr´ee lors d’un appel de service ; tout le reste est utilis´e comme C-list, i.e. contient C-list

les capacit´es du domaine.

Le thread est repr´esent´e par deux structures qui font chacune une page : une est appel´ee KTCB (kernel thread control block), n’est accessible que par le noyau. Elle contient des donn´ees pour l’ordonnancement, quelques donn´ees relatives `a l’appel de service en cours, dont l’adresse physique estampill´ee du domaine courant, et des capacit´es (le thread est ´egalement une C-list). L’autre est appel´ee UTCB (user UTCB

thread control block), et est accessible en ´ecriture par le thread courant. Elle est utilis´ee pour passer des arguments en param`etres lors de l’appel de service (§ 3.3.3.2), comme pile, ou pour contenir les registres sauvegard´es lors de la derni`ere pr´eemption (§ 4.2.3)).

Services du noyau Le noyau contient les services de m´ecanisme pour la manip- ulation de la m´emoire, des domaines et des threads. Il fonctionne en attribuant `a chaque page physique un des types suivants : KDCB, KTCB, UTCB, page de table de premier niveau, page de table de deuxi`eme niveau, page de donn´ees, page blanche.

Il assure certaines propri´et´es sur les pages (e.g. il est impossible d’´ecrire directe- ment dans le KDCB, KTCB, ou une table des pages ; il est impossible d’utiliser une page de donn´ees en tant que table des pages, etc.), dont le respect de la politique d’allocation. Ces propri´et´es assurent l’int´egrit´e (et la confidentialit´e) des tˆaches du syst`eme (´etant donn´e une allocation des ressources appropri´ee).

L’impl´ementation de ce m´ecanisme, que nous avons su rendre extrˆemement scalable en multiprocesseur, est d´ecrite en annexe C.

Autres architectures Cette impl´ementation est facilement adaptable sur d’autres architectures `a m´emoire pagin´ee, surtout si elle bas´ee sur des tables des pages multi- niveaux. Comme on d´ecouple la notion d’espace d’adressage de celle de domaine de protection, on peut facilement utiliser n’importe quelle m´ethode pour d´ecrire les espaces d’adressages ; il suffira de modifier le m´ecanisme en fonction.

Si la protection m´emoire est bas´ee sur la segmentation, le probl`eme est plus difficile, sauf dans le cas ou le syst`eme est statique (e.g. MPU pour un syst`eme contraint). Dans ce cas, domaine, KTCB etc. sont des donn´ees qui font partie du noyau ; comme elles ne sont pas contraintes `a ˆetre de taille une page, on ne perd plus de place due `a la fragmentation interne.