Services pour le partage des ressources

tˆaches n’utilisent un m´ecanisme commun que lorsque c’est n´ecessaire, et ce m´ecanisme commun est de taille minimale. Nous r´ealisons la synth`ese de la minimisation des m´ecanismes communs des micronoyaux et de celle des exonoyaux.

Cette structure permet ´egalement de garantir la limitation de la port´ee des extensions (§ 2.4.1.2). La modification d’une libOS a une port´ee garantie d’ˆetre limit´ee `a une application, tandis que la modification d’un service partag´e `a une port´ee limit´ee aux tˆaches qui en d´ependent. La limitation de la port´ee est ainsi garantie de mani`ere simple, par la structure mˆeme du syst`eme. L’ajout d’extensions est simple, et le syst`eme facilement extensible.

Un autre int´erˆet est que cette structure minimise le besoin pour les diff´erents ser- vices syst`emes de communiquer entre eux. Dans un OS monolithique ou micronoyau traditionel, il y a beaucoup de communication interservice (e.g. le service terminal communique avec le service ´ecran et le service clavier). En minimisant les services et en liant les applications `a une libOS, la majorit´e de ces communications peut ˆetre faite par l’interm´ediaire de l’application (e.g. Anaxagoros peut ne pas avoir de service partag´e de terminal). Cette minimisation des communications inter-services est int´eressante car c’est ce qui rend l’´ecriture de syst`emes `a base de micronoyau difficile (les services sont fortement coupl´es), et contribue `a l’impr´evisibilit´e dans l’ex´ecution du syst`eme (e.g. lorsqu’il y a des notifications en cascade).

Enfin, on peut profiter de tous les avantages qu’offre une structuration en exonoyau en termes de performances [KEG+

97, Ros95]. L’interface de bas niveau d’abstraction, avec le nommage physique des ressources, peut aider `a impl´ementer un OS (para)virtualis´e en tant que service partag´e, pour ex´ecuter le code pr´e-existant. Elle va ´egalement faciliter l’impl´ementation du transfert explicite des ressources (§ 2.3.2.4), plus s´ecuris´e.

Comparaison La diff´erence avec les exonoyaux sont la s´eparation des services de base en diff´erents domaines de protection ; celle avec les micronoyaux sont que les services partag´es sont minimaux et que l’abstraction est faite par une librairie.

Cette structuration ressemble `a celle conseill´ee par Rushby pour atteindre les plus hauts niveaux d’assurance de s´ecurit´e pour les embedded systems [Rus84], mais ce syst`eme est statique. Elle ressemble ´egalement `a celle qu’il conseille pour la r´ealisation d’un syst`eme MILS [BDRS08] ; mais dans cette derni`ere les applications sont toutes ex´ecut´ees dans des partitions virtualis´ees, et il n’y a donc pas d’assurance de protection entre applications de la mˆeme partition.

Enfin, la diff´erence principale vient de la structuration de la gestion des ressources, pr´esent´ee dans la prochaine section.

3.2.2 Services pour le partage des ressources

3.2.2.1 Services de politique et de m´ecanisme

On a vu que l’OS assurait trois rˆoles : abstraction, partage des ressources, et s´ecurit´e. Nous avons vu que l’abstraction pouvait ˆetre plac´ee dans des librairies, ce qui laisse aux services partag´es la s´ecurit´e et le partage des ressources.

S´eparation politique-m´ecanisme Nous impl´ementons le principe de s´eparation du m´ecanisme et de la politique (§ 2.4.3.1) en pla¸cant pour chaque ressource l’un dans un service de m´ecanisme, l’autre dans un ou plusieurs services de politique (d’allocation). Un service de m´ecanisme assure toutes les propri´et´es de s´ecurit´e « n´egatives » sur un type de ressource (par exemple, garantit qu’une application ne peut pas utiliser les ressources qui ne lui sont pas allou´ees, ou utilise les ressources correctement), et fournit de quoi permettre aux services de politiques de d´efinir l’allocation des ressources. Il y a donc communication entre ces services.

S´ecurit´e des services de partage des ressources Les prochains chapitres de la th`ese traitent de la r´ealisation des services et principalement des services de m´ecanismes. En effet ceux-ci sont acc´ed´es par des applications qui ne se font pas confiances, `a la fois critiques et non critiques : la s´ecurit´e dans la r´ealisation des services de m´ecanisme est essentielle, car ce sont les seuls points d’attaques du syst`eme par une tˆache malicieuse.

La s´ecurit´e des services de politique peut ˆetre obtenue par des propri´et´es de l’impl´ementation, mais ´egalement de mani`ere structurelle. En particulier, l’alloca- tion hi´erarchique (§ 3.2.4.1) permet d’isoler les politiques d’allocations. De plus, l’allocation statique n’a pas besoin de module « actif » g´erant une politique, et donc n’a pas besoin de service de politique. Nous nous sommes donc davantage attach´es `

a la r´ealisation des services de m´ecanismes qu’aux services de politiques.

Il y a deux types d’attaques contre lesquelles un service partag´e doit se prot´eger. Le premier type concerne la confidentialit´e : en temps normal des tˆaches ind´ependantes ne doivent pas communiquer par l’usage d’un service partag´e (notons que cela rend l’utilisation de ces services ind´ependante de la politique de s´ecurit´e (principe 3.1.4.1)). Une br`eche dans la confidentialit´e indique que les tˆaches peuvent communiquer par l’interm´ediaire d’un service, et donc qu’elles peuvent interf´erer l’une sur l’autre ; cela peut indiquer qu’une tˆache peut provoquer la d´efaillance d’une autre tˆache [Rus98]. Le deuxi`eme type concerne la disponibilit´e : i.e. il y a un d´eni de service (ou un ralentissement de service) sur le service partag´e, ce qui empˆeche une tˆache d’utiliser le service.

La pr´evention de ces attaques est assur´ee en partie par notre m´ecanisme de communication et le prˆet de ressource (§ 3.4), et en partie par des principes de structuration des services (section 3.5 et chapitre 5).

3.2.2.2 Gestion de l’allocation des ressources

Tableau des ressources Une majorit´e de types de ressources peuvent se partager spatialement (§ 2.1.1) : i.e. la ressource est d´ecomposable de mani`ere `a ce qu’on puisse en donner une partie `a une tˆache de mani`ere « permanente » (jusqu’`a la prochaine d´ecision de modification de l’allocation). Les seules ressources qui ne se partagent pas spatialement sont le CPU ou tout autre unit´e capable d’un traitement parall`ele au CPU (e.g. DMA, r´eseau, disque dur ; mais pas ligne s´erie puisque celle-ci ne peut pas fonctionner sans ˆetre directement pilot´ee par le CPU).

En g´en´eral ces ressources spatiales peuvent ˆetre ´enum´er´ees de 0 `a N − 1, N ´etant leur nombre. Les ´el´ements peuvent ˆetre indiff´erenci´es (e.g. pages m´emoires) ou non

3.2.2. Services pour le partage des ressources

(e.g. port TCP/IP). Les applications utilisent les ressources en faisant un appel au service de m´ecanisme de cette ressource. Le num´ero de la ressource est transmis en param`etre de l’appel, et le service de m´ecanisme ex´ecute la requˆete sur la ressource au num´ero correspondant.

Le service de m´ecanisme doit g´erer des donn´ees relatives `a chaque ressource. On

utiliser pour cela une structure appel´ee tableau des ressources, qui est un simple tableau des ressources

tableau index´e par le num´ero de ressource. Il pourrait se pr´esenter sous une forme diff´erente que celle d’un tableau ; mais cette forme est la plus simple et efficace. Ce choix est justifi´e section 3.5.2.1.

Protocole d’acc`es aux ressources L’allocation et l’utilisation des ressources se d´eroule de la mani`ere suivante. L’allocation d’une ressource `a une tˆache se fait par le service de politique, qui cr´ee une association tˆache/num´ero de ressource2

et la communique au service de m´ecanisme. Lorsque la tˆache veut utiliser la ressource, elle fait un appel au service de m´ecanisme pour cette ressource, en lui d´esignant le num´ero de la ressource. Le service v´erifie que la tˆache a bien le droit d’utiliser cette ressource en regardant si l’association tˆache/num´ero existe, avant d’ex´ecuter la requˆete pour cette ressource. La Figure 3.2 fournit un exemple.

M´ecanisme 0 1 2 3 4 5 6 Client 1 Client 2 Client 3 Politique 3 1 ₂ n Ressource n Capacit´e

Fig. 3.2 – S´eparation politique/m´ecanisme pour les ressources spatiales. Le protocole est le suivant : (1) la tˆache demande `a la politique une ressource ; (2) la politique cr´ee une capacit´e vers une ressource dans le service de m´ecanisme et la renvoie `a la tˆache (nota bene : cette fl`eche ne repr´esente pas une capacit´e), apr`es avoir r´evoqu´e les ´eventuels autres acc`es `a la ressource. (3) la tˆache communique directement avec le service de m´ecanisme par cette capacit´e.

Impl´ementation avec les capacit´es Pour suivre le principe d’´economie de m´ecanisme (§ 2.2.2.5) et d’unicit´e du m´ecanisme de protection, et le principe de m´ediation compl`ete (§ 2.2.2.2), il est important que l’installation et la v´erification de l’association tˆache/ressource soit faite en r´eutilisant le m´ecanisme de contrˆole d’acc`es. Notre m´ecanisme de capacit´e (pr´esent´e en d´etail § 3.3) est particuli`erement adapt´e pour impl´ementer efficacement ce protocole.

Une capacit´e correspond `a une ressource3

. Le noyau fournit une op´eration invoke qui prend en argument une capacit´e, qui permet de faire un appel vers le service de m´ecanisme de la ressource. Le noyau communique alors au service le num´ero de la ressource correspondant `a la capacit´e. On ne peut appeler le service de m´ecanisme avec le num´ero de ressource n que si on a une capacit´e vers cette ressource de num´ero n. Ainsi, le m´ecanisme de v´erification de droit d’acc`es `a une ressource est uniforme, s´ecuris´e et simple d’utilisation `a la fois pour le service et pour la tˆache cliente. La d´esignation d’une ressource se fait tout simplement en s´electionnant la capacit´e correspondante, ce qui permet de faire l’´economie d’un m´ecanisme de d´esignation.

Ce m´ecanisme de s´ecurit´e est flexible ; par exemple parfois une tˆache peut utiliser un grand nombre de ressources d’un mˆeme type (e.g. page m´emoire, ou secteurs de disque). Dans ce cas, une capacit´e peut d´esigner un ensemble de ressources, plutˆot qu’une seule. Le service m´emoire fonctionne de cette mani`ere.

La cr´eation et r´evocation de capacit´es vers un domaine d peut se faire depuis un domaine d′

diff´erent de d. Ainsi, lorsqu’une tˆache contacte un service de politique d′

pour faire une demande d’allocation de ressources, ce dernier peut cr´eer une capacit´e vers le service de m´ecanisme d sans qu’il fasse lui-mˆeme un appel de service `a d. Cela contribue `a l’efficacit´e de l’allocation.

Avantages et notes Ce m´ecanisme a surtout un avantage en terme de simplicit´e et de s´ecurit´e. En utilisant le m´ecanisme de contrˆole d’acc`es pour acc´eder au ressource, on dispose d’un moyen formel pour savoir qui peut acc´eder `a quelles ressources. Il est ainsi simple de s’assurer qu’il est impossible pour une tˆache d’acc´eder `a des ressources auquel il n’a pas le droit.

Le deuxi`eme avantage est l’efficacit´e. L’allocation se fait sans contacter le service de m´ecanisme, et l’utilisation se fait sans contacter le service de politique. Une fois l’allocation faite, l’acc`es aux ressources est tr`es rapide, la v´erification se faisant par le m´ecanisme de capacit´e optimis´e dans ce but. La s´eparation des services de politique et de m´ecanisme permet de sp´ecialiser et optimiser chaque service pour son op´eration.

Enfin, l’allocation des ressources est ´egalement rapide : il n’y a a priori qu’un seul appel de service `a r´ealiser.

3.2.2.3 Gestion de la r´epartition temporelle des ressources On diff´erencie deux notions dans la r´epartition temporelle des ressources.

Lorsqu’on parle simplement d’un changement de la possession des ressources (e.g. changement d’allocation m´emoire), cette r´epartition est librement impl´ementable