# Le système plessey 250

Jean Ferrié, Didier Lanciaux

► To cite this version:

Jean Ferrié, Didier Lanciaux. Le système plessey 250. [Rapport de recherche] IRIA-RR-168, IRIA. 1976, pp.29. hal-04716339

HAL Id: hal-04716339

https://inria.hal.science/hal-04716339v1

Submitted on 1 Oct 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
02186 RR168

RIA
laboria

Institut de Recherche
d'Informatique
et d'Automatique

Domaine de Voluceau
Rocquencourt
B. P. 5 78150 - Le Chesnay
France
Tél.: 954 90 20

laboratoire de recherche
en informatique
et automatique

LE SYSTÈME
PLESSEY 250

Jean Didier
J. Ferrié, D. Lanciaux

Rapport de Recherche N° 168
Avril 1976
# LE SYSTEME PLESSEY 250

## J. Ferrié*, D. Lanciaux**

### Résumé :

Ce rapport est une étude critique du système Plessey 250. Il en présente les mécanismes d'adres-sage et de protection et leur utilisation dans la structuration du système.

Il est à la base d'une partie du cours de DEA de J. Ferrié sur la protection dans les systèmes à l'Institut de Programmation de l'Université de Paris VI.

### Abstract :

This paper is a critical presentation of Plessey 250 system. It deals with basic mechanisms and their use for the design of the system.

It is used as lecture notes for one part of the course on protection in operating systems given by J. Ferrié at Paris VI University.

<footnote>* actuellement à l'Université des Sciences et Techniques du Languedoc - Montpellier.</footnote>

<footnote>** IRIA/LABORIA.</footnote>
# PLAN

## I INTRODUCTION

## II LA MEMOIRE SEGMENTEE

2.1 Segment et descripteur de segment

2.2 Langage machine et accès au segment

## III DOMAINE D'EXECUTION D'UN PROCESSUS - ESPACE ADRESSABLE

3.1 Notion de domaine

3.2 Changement de domaine d'exécution

3.3 Retour de domaine - Pile de processus

3.4 Réentrance d'un domaine

## IV STRUCTURE D'UN OBJET CONSTRUIT

## V STRUCTURE DU PROCESSUS

## VI ORGANISATION DU SYSTEME

6.1 Gestion de la mémoire

6.11 Création de segment

6.12 Destruction de segment

6.13 Mémoire fictive

6.2 Gestion des processus

6.3 Gestion des entrées/sorties

6.4 Gestion des fichiers et des catalogues

## VII ASPECTS EXTERNES DU SYSTEME

7.1 Interpréteur de commande

7.2 Commandes d'assemblage

## VIII CRITIQUES

8.1 Points d'entrée de domaine et guichets

8.2 Manipulation des objets construits

8.3 Problèmes des domaines mutuellement méfiants

8.4 Réentrance et récursivité d'un domaine.
# LE SYSTEME PLESSEY 250

## I INTRODUCTION

Le système Plessey 250 est un système multi-processeur développé par la Compagnie Plessey pour des applications en temps réel (télécommunication). La structure de la machine est spécialement conçue pour résoudre les problèmes posés par le partage et la protection sélective de l'information.

L'espect le plus important dans cette voie est certainement l'utilisation intensive de la notion de descripteur ("capability"). La généralisation de l'usage des descripteurs comme chemin d'accès à l'information et la distinction, au niveau du câblé, entre deux sortes de segments programmables - les segments de données et les listes de descripteurs - constituent l'apport le plus original, dans le domaine de l'architecture des calculateurs.

Les autres caractéristiques originales de ce système sont :

- la manipulation explicite par le programme utilisateur, des descripteurs, et ceci sans prérogatives particulières,

- la matérialisation au niveau de l'adressage de la notion de domaine,

- l'absence de mode privilégié (mode maître), tout en ayant la possibilité grâce à la notion de domaine, de définir différents niveaux de protection,

- l'absence d'instruction d'entrée-sortie et l'adressage des périphériques de la même façon que la mémoire sous contrôle des descripteurs.

En outre, il est possible, avec certaines restrictions cependant, de résoudre les problèmes posés par la coopération de sous-systèmes mutuellement méfiants.

A la différence de CLICS, le système Plessey ne permet pas l'édition de lien dynamique.

## II LA MEMOIRE SEGMENTEE

### 2.1 Segment et descripteur de segment

La mémoire physique se compose d'une mémoire centrale et de disques rapides. Elle est allouée par zones à des segments, suites contiguës d'emplacements.

Un segment est représenté par un descripteur de segment qui occupe un emplacement. Ce descripteur ("capability") contient les informations suivantes :
- l'adresse en mémoire de la base du segment,

- la taille du segment (maximum 1600 mots),

- les droits d'accès au segment (définissant les instructions autorisées sur ce segment).

La donnée d'un couple (descripteur de segment, déplacement) permet à un processeur de calculer une adresse en mémoire physique par addition du déplacement à l'adresse de base du segment. Au cours de ce calcul d'adresse le processeur vérifie que le déplacement n'est pas supérieur à la taille du segment et que les droits d'accès sont compatibles avec l'opération tentée.

Un descripteur constitue une référence absolue au segment.

**Remarque 1.** En toute rigueur, l'adresse contenue dans le descripteur n'est pas une adresse absolue en mémoire, mais plutôt une adresse fictive. De cette façon, lorsque le segment est déplacé en mémoire principale, la ou les versions de son descripteur n'ont pas besoin d'être mises à jour (voir chapitre 6).

Il existe deux sortes de segments :

- les *segments de données*, dont les emplacements sont des mots (valeurs),

- les *segments de descripteurs* ("capability list") appelés aussi *D-listes*, dont les emplacements sont interprétés comme des descripteurs de segments (segment de données ou D-listes).

Dans cette optique, un processus ne peut accéder à un emplacement (mot ou descripteur) d'un segment, que par l'intermédiaire du descripteur qui désigne ce segment ; le processus désigne alors un emplacement dans le segment par le couple (descripteur de segment, index de l'emplacement dans le segment).

Le segment constitue la plus petite entité à laquelle il est possible de donner une protection spécifique.

On notera qu'un segment n'a d'existence qu'à partir du moment où il peut être référencé, autrement dit où il existe au moins un descripteur qui le repère. La partie du système qui crée les segments (en allouant des zones contiguës de mémoire) et qui délivre le premier descripteur des segments créés sera étudiée au chapitre 6.

**Remarque 2.** La nature (descripteur ou mot) du contenu d'un emplacement de mémoire n'est pas, à la différence du Burroughs 6700, précisée par un préfixe. Elle est implicitement liée à la nature du segment (D-liste ou segment de données) auquel appartient cet emplacement.
Les droits d'accès qui figurent dans le descripteur de segment, définissent les instructions qui sont permises sur ce segment, par l'intermédiaire de ce descripteur.

Les instructions possibles sur un segment de données, sont les instructions classiques de lecture, d'écriture et d'exécution d'un mot du segment.

Les instructions possibles sur une D-liste sont les instructions de lecture et d'écriture d'un descripteur d'une D-liste, et l'instruction d'appel qui sera étudiée plus loin.

A chacune de ces instructions est associé un droit dans le descripteur du segment. Les droits d'accès relatifs aux segments de données seront notés (L, E et I) et ceux relatifs aux D-listes (Ld, Ed, A).

Il peut exister plusieurs descripteurs pour un même segment (partagé ou non entre plusieurs processus), chacun d'eux définissant des droits d'accès différents pour le segment.

**Remarque 3.** En pratique, les droits d'accès figurant dans un descripteur, sont indépendants, de sorte que certains segments peuvent recevoir à la fois des droits de segments de données et des droits de D-listes. Cette possibilité est seulement utilisée dans la partie la plus protégée du système (cf chapitre 6) pour pouvoir considérer un emplacement de segment à la fois comme une donnée et un descripteur ; sans cela la protection ne serait plus assurée.

## 2.2 Le langage machine et l'accès au segment

Le langage machine est constitué d'instructions, de longueur fixe, contenues dans un emplacement (de segment exécutable).

Il existe deux sortes de registres programmables par un processus :

- les registres de données ($R_0, R_1, ..., R_7$) dont les contenus sont nécessairement issus de segments de données (ou d'autres registres de données) ou bien sont des valeurs immédiates ;

- les registres de descripteurs ($R_{D0}, ..., R_{D7}$) dont les contenus représentent des descripteurs de segments ; ces descripteurs sont nécessairement issus de D-listes ou de registres de descripteurs.

Généralement une instruction met en jeu un emplacement de segment et un registre. Suivant la nature du segment manipulé, les instructions diffèrent. On distingue celles qui mettent en jeu segments de données et registres de données, et celles qui mettent en jeu D-listes et registres de descripteurs.
Une instruction est composée de trois champs : op, R' (R<sub>D</sub>, X, dep)

- le code opération,

- le nom d'un registre R' ,

- le champ adresse qui contient un triplet (nom de registre de descripteur, nom d'un registre d'index, déplacement) soit (R<sub>D</sub>, X, dep).

L'emplacement du segment sur lequel porte l'instruction est alors désigné de
la façon suivante :

. R<sub>D</sub> contient le descripteur du segment référencé,

. dep (auquel est éventuellement ajouté le contenu du registre de données X) spécifie le déplacement de l'emplacement dans le segment.

Le code opération précise la nature de l'instruction mise en jeu (lecture, écriture ... d'un segment de donnée ou d'une D-liste).

Le registre R' est nécessairement un registre de descripteur, lorsque
l'instruction manipule une D-liste ; sinon, le registre R' est un registre
de données.

Il ressort de ce schéma d'adressage, qu'aucun segment ne peut être manipulé,
sans utiliser le (ou les) descripteur(s) qui le repère. En outre l'accès à
un emplacement de segment n'est possible que si, au préalable, un descripteur
de ce segment a été chargé par le processus dans un registre de descripteur.
En résumé, le processeur réalise le contrôle de la référence à un emplacement
de segment, en vérifiant :

- d'abord que le code opération est compatible avec les droits d'accès figurant dans le descripteur du segment référencé ; ce descripteur est contenu dans le registre de descripteur mentionné dans le champ adresse de l'instruction (contenu du registre R<sub>D</sub>);

- ensuite que le déplacement de l'emplacement n'est pas supérieur à la taille du segment.

Un processus peut copier un descripteur de segment d'une D-liste dans une autre, en utilisant un registre de descripteur intermédiaire, à la condition de respecter les droits d'accès associés aux D-listes. Cette copie peut éventuellement s'effectuer en restreignant les droits figurant dans le descripteur copié.
# III DOMAINE D'EXECUTION D'UN PROCESSUS - ESPACE ADRESSABLE

## 3.1 Notion de domaine

Nous considérons ici un processus isolé ; à un instant donné, ce processus s'exécute dans un domaine. Un domaine regroupe les segments nécessaires à la réalisation d'un traitement et spécifie les droits d'accès à ceux-ci.

Dans la Plessey 250, un domaine est caractérisé par :

- un (ou plusieurs) segment(s) de code exécutable,

- une D-liste particulière, appelée descriptif, qui regroupe les descripteurs des segments (données ou D-listes) que les instructions du code sont libres de manipuler.

A tout instant, deux registres de descripteurs particuliers et un registre de données noté CO, non altérables normalement*, matérialisent le domaine dans lequel l'exécute le processus, de la façon suivante :

- $R_{D7}$ contient le descripteur (avec le droit I) du segment de code, dans lequel se trouve l'instruction en cours d'exécution ;

- CO contient l'index de l'emplacement contenant cette instruction ; il est incrémenté automatiquement au cours de chaque instruction ;

- $R_{D6}$ (registre de base du descriptif) contient le descripteur (avec le droit Ld) du descriptif.

Etant donné que le segment de code est aussi un segment du domaine, le descripteur qui le repère, figure également dans le descriptif du domaine.

On rappelle que le schéma d'adressage impose de charger au préalable dans un registre de descripteur, le descripteur du segment à accéder. Pour cette raison l'ensemble des registres de descripteurs ($R_{D0}, ..., R_{D7}$) et des registres de données définit l'espace adressable du processus, à un instant donné (figure 1).

Etant donné que les descripteurs figurant dans le descriptif peuvent repérer non seulement des segments de données mais aussi des D-listes, le processus en exécution dans le domaine a la possibilité d'accéder à un ensemble de segments beaucoup plus grand que celui qui est initialement déterminé par le contenu du descriptif.

<footnote>* autrement que par les instructions d'appel, de retour (et de branchement).</footnote>
<figure><img src="image_2.png" /><figcaption>Figure 1. Domaine d'un processus et espace adressable à un instant donné.</figcaption></figure>

**Exemple.** Le processus en exécution dans le domaine représenté sur la figure 1, exécute une instruction du segment A ; un descripteur contenu dans le descriptif peut être chargé au moyen du registre $R_D$, dans un registre de descripteur (autre que $R_D$ et $R_D$). Le segment de données D peut être écrit, en utilisant le registre $R_D$. La D-liste B' peut être lue au moyen de $R_D$.

Le descriptif apparaît donc comme la racine d'une structure de données à laquelle les instructions du code attaché au domaine peuvent avoir accès.
## 3.2 Changement de domaine d'exécution

Le domaine constitue une enceinte de protection dans la mesure où seuls les objets décrits dans le domaine, sont accessibles au processus qui s'y exécute et ceci avec les droits mentionnés. On limite de la sorte, la propagation des erreurs et on facilite leur détection.

Pour changer de domaine d'exécution, le processus utilise l'instruction particulière :

$$ \underline{\text{appel}} R_{D_i}^-, \text{dep} $$

où :

* $R_{D_i}^-$ est un registre de descripteur, qui contient le descripteur (avec le droit "appel" autorisé) de la D-liste qui constituera le descriptif du domaine appelé ;

* dep est le déplacement dans cette D-liste, de l'emplacement qui contient le descripteur du segment de code (avec le droit I autorisé) associé au domaine appelé.

En d'autres termes, un processus ne peut changer de domaine d'exécution que s'il possède dans son descriptif (où dans la structure de D-listes qui en dérive), le descripteur du descriptif du nouveau domaine avec le droit d'accès "appel" (noté A).

**Remarque 1.** Le droit d'accès "appel" associé à une D-liste ne permet ni la lecture, ni l'écriture de cette D-liste mais seulement l'appel du domaine dont elle constitue ce descriptif.

L'effet de l'instruction d'appel est le suivant :

- $R_{D_7}^-$ est chargé avec le descripteur du segment de code associé au domaine appelé et CO repère désormais la première instruction de ce segment (CO := 0) ;

- le registre de base de descriptif $R_{D_6}^-$ est chargé avec le descripteur du descriptif du domaine appelé ; en outre le droit $L_d$ est automatiquement forcé dans ce descripteur pour permettre au domaine appelé d'avoir accès (en lecture) à sa propre structure de données.

La progression du processus se traduit alors par une suite d'appel de domaines. Ces domaines sont interconnectés par des descripteurs possédant le droit "appel".

Les différentes possibilités d'évolution d'un processus, à un instant donné, se déduisent de la structure de données issue du descriptif du domaine dans lequel s'exécute le processus à cet instant. Chaque descripteur possédant le droit "appel" donne potentiellement accès à un nouveau domaine (et donc à un
nouvel ensemble de segments) et ainsi de suite (figure 2). Un programme (associé à un processus) se représente alors comme un réseau dans lequel les nouds sont des domaines, et les flèches des chemins d'accès possibles. Dans la Plessey la structure associée à ce réseau est établie au moment de l'assemblage ; tous les segments constituant le programme sont assemblés et les références externes résolues avant la première exécution du programme.

<figure><img src="image_3.png" /><figcaption>Figure 2. Réseau de domaines</figcaption></figure>
Lorsqu'un processus change de domaine, il a accès, par l'intermédiaire du code du domaine appelé, à un nouvel ensemble de segments ; un même segment peut toutefois appartenir à plusieurs domaines à la fois.

**Remarque 2.** Les registres de descripteurs (autres de $R_{D6}$ et $R_{D7}$) ne sont pas altérés à l'appel de domaine ; il peuvent être utilisés pour passer des segments en paramètres d'un domaine à l'autre.

A la différence de l'instruction d'appel, l'instruction de branchement ne permet pas de changer de domaine d'exécution. Elle permet de réaliser des ruptures de séquence, à l'intérieur d'un même domaine.

### 3.3. Retour de domaine - Pile du processus

L'instruction **retour** permet de revenir dans le domaine appelant, à l'instruction suivant l'instruction d'appel. A cet effet, une pile est associée à chaque processus. Lors de l'appel, les contenus des registres $R_{D6}$, $R_{D7}$ et CO sont automatiquement rangés, par câblage, dans les emplacements du sommet de la pile.

Au retour, ces registres sont automatiquement rechargés par les anciennes valeurs, qui définissaient le domaine appelant, au moment de l'appel, et le sommet de pile est décrémenté. De cette façon, le retour s'effectue vers le domaine appelant, à l'instruction suivant l'instruction d'appel.

En fait, le segment pile associé à un processus est divisé en 2 parties :

- une **zone de rangement**, dans laquelle sont rangés les contenus des registres de données ($R_0, ..., R_7$) et de descripteurs ($R_{D0}, ..., R_{D5}$) lorsque l'unité centrale est retirée au processus ;

- une **zone dynamique**, gérée en pile, dans laquelle sont rangés les contenus des registres $R_{D6}$, $R_{D7}$ et CO, lors de l'instruction d'appel de domaine ; le pointeur de sommet de pile est représenté par le premier mot de la zone de rangement.

**Remarque 1.** Les autres registres ne sont pas empilés lors d'un appel de domaine. La pile du processus est un segment particulier qui contient à la fois des mots et des descripteurs (cf. 2.1). Il est désigné par un descripteur, contenu dans un **registre pointeur de pile**, non programmable directement par le processus.
**Remarque 2.** A ce niveau de l'étude, on peut considérer que le registre pointeur de pile est un emplacement d'une D-liste particulière, fixe en mémoire, et dont le descripteur est uniquement manipulable par les domaines les plus privilégiés du système (chapitre 6).

<figure><img src="image_4.png" /><figcaption>**Figure 3.** Segment-pile d'un processus.</figcaption></figure>
## 3.4 Ré entrance d'un domaine

Les mécanismes d'adressage introduits n'assurent pas automatiquement la ré entrance d'un domaine.

Pour qu'un domaine partagé soit exécutable simultanément par plusieurs processus, il est nécessaire qu'il dispose d'une zone de travail, propre à chaque processus. Cette zone de travail doit au moins être constituée d'une D-liste dans laquelle figurent les descripteurs des segments privés, propres au couple domaine-processus.

Plusieurs solutions sont concevables :

Si le descriptif du domaine est propre au processus qui parcourt le domaine, une partie de ce descriptif (définie lors de l'assemblage) peut être utilisée comme zone de travail propre au processus (cf. 8.81).

Si le descriptif du domaine est partagé par tous les processus qui parcourent le domaine, il n'y a pas de zone de travail propre au couple domaine-processus. Toutefois, les registres du processus (à l'exception toutefois de CO, RD₆, et RD₇) qui rappelons-le sont communs à tous les domaines parcourus par ce processus, peuvent en tenir lieu momentanément.

Il semble que dans le Plessey 250 seule cette méthode soit utilisée.

**Remarque.** Par convention de programmation, le registre de descripteur RD₅ est utilisé pour repérer une D-liste particulière, qui par ce moyen devient commune à tous les domaines parcourus par le processus. Les segments et plus généralement les objets (cf. 4) dont les descripteurs sont contenus dans cette D-liste, sont appelés les globaux du processus.

# IV STRUCTURE D'UN OBJET CONSTRUIT

Un segment de données, ensemble contigu de n mots, peut être considéré comme un objet ("resource") élémentaire. Les opérations possibles sur cet objet sont alors les instructions de lecture ou d'écriture d'un mot du segment dans la limite [o,n]. De même, une D-liste est un objet élémentaire d'une autre classe, pour lequel les opérations de manipulation sont les instructions de lecture et d'écriture d'un descripteur dans la D-liste.

Il est possible dans la Plessey de construire des objets, ayant une structure plus complexe, et manipulables par des procédures spécifiques et non plus par n'importe quelle instruction ou suite d'instructions de la machine. Les caractéristiques générales de tels objets sont :
- un ensemble de segments de données et de D-listes, qui traduisent la structure de l'objet,

- un ensemble de segments de code qui traduisent les opérations permises sur cet objet.

En d'autres termes, un objet est défini dès qu'on été précisées sa structure (sa représentation) et les opérations qui permettent de la manipuler. Les mécanismes de protection visent justement à empêcher sa manipulation par d'autres opérations que celles qui ont été prévues au moment de sa définition.

Le concept de domaine permet alors de représenter un objet, en regroupant dans un même descriptif :

- les descripteurs des segments décrivant la structure de l'objet,

- les descripteurs des segments de code, traduisant les opérations possibles sur cet objet.

Un objet construit est alors représenté par le descripteur (avec le droit "appel") du descriptif du domaine qui incarne cet objet. La manipulation de cet objet se fait en utilisant l'instruction d'appel de domaine, dans laquelle $R_D$ contient le descripteur du descriptif du domaine associé à l'objet et dep désigne l'emplacement dans ce descriptif, du code associé à l'opération invoquée.

Deux objets de même classe sont représentés par deux domaines différents ayant en commun les segments de code correspondant aux opérations permises et ayant même structure.

**Exemple.** Considérons l'objet sémaphore ; il est défini, entre autres choses, par :

- une structure constituée d'un segment de données dans lequel est rangée la valeur du sémaphore et d'une D-liste qui regroupe les processus (voir chapitre 5) bloqués dans la file d'attente du sémaphore.

- deux segments de code correspondant aux opérations P et V.

Le domaine qui est associé au sémaphore $s_I$ est représenté sur la figure 4.
<figure><img src="image_5.png" /><figcaption>Figure 4. Représentation d'un objet sémaphore</figcaption></figure>

Un objet construit d'une certaine classe est créé dynamiquement durant l'exécution du programme. Le descripteur qui le représente est délivré par un domaine générateur associé à cette classe d'objet.

## V STRUCTURE DU PROCESSUS

Le terme processus désigne un programme en cours d'exécution. C'est l'entité dynamique qui accède aux segments et plus généralement aux objets construits par l'intermédiaire des instructions et des opérations programmées.

Un processus peut aussi être considéré comme un objet par d'autres processus, qui peuvent alors le manipuler au moyen d'opérations programmées.

Les opérations possibles sur un processus sont, par exemple, les opérations *bloquer* et *activer* qui ont pour effet de le faire passer respectivement à l'état "bloqué" ou "actif".

En tant qu'objet, un processus est donc représenté par une structure qui comprend :

- le segment-pile du processus ; on y trouve le contenu des registres, et les informations permettant d'effectuer le retour des différents domaines appelés ;

- un certain nombre de segments regroupant les informations propres au processus (par exemple, sa priorité, son état, le nom de l'usager auquel
il est associé,...);

- les segments de code réalisant les opérations bloquer et activer. Comme pour tout objet construit, cette structure est regroupée dans un domaine et le descriptif de ce domaine contient les descripteurs des segments précédemment cités. Le descripteur de ce descriptif (avec le droit "appel") représente alors l'objet processus (figure 5).

<figure><img src="image_6.png" /><figcaption>Figure 5. Structure de processus</figcaption></figure>

<footnote>Remarque. Dans l'exemple donné au chapitre 4, les processus bloqués dans la file d'attente (D-liste) du sémaphore, seraient représentés par le descripteur de leur structure.</footnote>
Un processus est créé dynamiquement par un autre processus ; par exemple, lorsqu'un usager débute une session "login", un processus initialisé sur l'interpréteur du langage de commande est créé et lui est associé.

Un domaine particulier du système, chargé de la gestion des processus, crée la structure du processus et l'initialise éventuellement avec l'information transmise ; ainsi, le segment-pile du processus contiendra le descripteur du domaine dans lequel sera lancé le processus créé, et les registres dont l'image figure dans la pile contiendront éventuellement les paramètres fournis par le processus créateur.

Le processus créateur reçoit, en retour, du domaine "allocateur de processus", le descripteur (avec le droit "appel") de la structure associée au processus ainsi créé.

# VI ORGANISATION DU SYSTEME

Le moniteur se compose d'un certain nombre de domaines réalisant les fonctions de base : gestion de mémoire, gestion des processus et des entrées-sorties. Ces domaines sont parcourus par les processus des usagers et leur protection se trouve assurée de la même façon que les autres domaines, sans mécanisme supplémentaire (mode maître et/ou "appel superviseur").

## 6.1 Gestion de la mémoire

### 6.11 Création de segment

Le domaine "allocateur de mémoire" a pour fonction de créer des segments aux processus qui en font la demande. Pour cela, il répartit l'espace en mémoire ou sur disque.

Cet allocateur délivre en résultat un descripteur du segment créé ; ce segment est soit un segment de données soit une D-liste. C'est le seul domaine du système capable de fabriquer des descripteurs.

### 6.12 Destruction de segment

Un processus qui possède un descripteur de segment (avec le droit d'écriture), peut demander explicitement à l'allocateur de mémoire la destruction du segment. Lorsqu'un segment est explicitement détruit, l'allocateur doit invalider tous les descripteurs qui répèrent ce segment. C'est seulement après, que l'allocateur peut réutiliser l'espace qui était occupé par le segment qu'il vient de détruire, pour y implanter un nouveau segment.
Un segment est _implicitement_ détruit, lorsqu'il n'existe plus aucun descripteur qui le repère. Cette situation est possible puisqu'un processus peut librement, par la copie de descripteurs dans les D-listes (avec l'accès Ed) surcharger des descripteurs existants. Pour résoudre les problèmes posés par la destruction des segments, l'allocateur met en jeu une procédure de "ramassage de miettes".

## 6.13 Mémoire fictive

En toute rigueur, le descripteur d'un segment ne contient ni l'adresse en mémoire de la base du segment, ni sa taille mais seulement le déplacement dans un segment particulier, de l'emplacement qui contient ces informations. Ce segment est appelé la Table des Descripteurs du Système (en abrégé SDT).

Il est fixé en mémoire et est repéré par un descripteur contenu dans un registre non programmable. Toutes les instructions du calculateur accèdent, à l'insu du programmeur, à la SDT pour former l'adresse physique de l'emplacement référencé. De cette façon, lorsqu'un segment est déplacé en mémoire, les différentes copies d'un descripteur n'ont pas besoin d'être mises à jour.

**Remarque 1.** Il existe, grâce aux registres de descripteurs, un mécanisme accélérateur qui évite, lors de l'exécution d'une instruction, d'effectuer systématiquement une indirection par la SDT.

**Remarque 2.** La SDT est résidente en mémoire et sa taille est limitée. De plus, l'adresse de segment qui figure dans chaque emplacement de la SDT est une adresse de mémoire principale. Lorsque le segment correspondant se trouve sur disque, un bit de déroutement permet d'invalider l'entrée associée de la SDT. Lorsque tous les descripteurs d'un segment se trouvent sur disque, l'entrée correspondante de la SDT peut alors être réallouée (par l'allocateur de mémoire) à un autre segment qui doit être rappelé du disque. Lorsqu'un descripteur est rangé sur disque, il est transformé de façon à repérer non par l'entrée correspondante de la SDT mais l'adresse sur disque du segment. référencé. Une tentative d'accès à un segment situé sur disque, provoque implicitement l'appel du domaine allocateur de mémoire.

## 6.2. Gestion des processus

La gestion des processus inclut les fonctions suivantes :

- la création et destruction des processus (chapitre 5),

- l'allocation du (ou des) processeurs aux processus actifs.
Le domaine "allocateur de processeur" est appelé lorsque le processus élu termine ou bien alors se bloque, à la suite par exemple de l'exécution d'une opération P sur un sémaphore. L'allocateur choisit un processus actif, dans une file d'attente, et réalise la commutation de processus élu, au moyen d'une instruction particulière, l'instruction *changer-processus*.

Cette instruction a pour paramètre, le descripteur (avec les droits L, E, Ld, Ed) du segment-pile du nouveau processus élu. Son effet est le suivant :

- elle range les registres (autres que $R_{D_6}, R_{D_7}$ et CO) de l'ancien processus élu dans la zone de rangement de la pile associée (qui est repérée par le registre pointeur de pile) et les registres $R_{D_6}, R_{D_7}$ et CO dans la zone dynamique, en sommet de pile ;

- elle charge le registre pointeur de pile avec le descripteur du segment-pile associé au nouveau processus élu ;

- elle recharge, en utilisant la nouvelle pile, le contexte (registres $R_{D_6}, R_{D_7}$ et CO) du nouveau processus ainsi que ses autres registres (zone de rangement).

Après l'exécution de cette instruction, le contrôle est rendu au nouveau processus élu dans le domaine dont le contexte est défini par le sommet de pile : ce domaine peut être un domaine usager ou éventuellement le domaine allocateur (dans le cas, où le processus élu était précédemment bloqué) (figure 6).

Le domaine allocateur est le seul domaine du système, habilité à manipuler la structure de l'objet processus. Pour cette raison, les fonctions de l'allocateur de processeur sont réalisées par les opérations *bloquer* et *activer* associées à la structure du processus (cf. chapitre 5). En outre, le parcours du domaine allocateur de processeur se fait, toutes interruptions masquées.

**Remarque 1.** Une interruption force l'exécution d'une instruction "changer processus" en faveur d'un processus d'interruption.

**Remarque 2.** L'instruction *changer-processus* n'est pas absolument nécessaire ; toutes les actions qu'elle réalise auraient très bien pu être programmées explicitement dans l'allocateur, à la condition de lui donner la possibilité de manipuler le registre pointeur de pile (cf. remarque du 3.3).
<figure><img src="image_7.png" /><figcaption>Figure 6. Changement de processus</figcaption></figure>

**Commentaires.** Dans ce schéma, avant d'exécuter l'instruction de changement de processus l'allocateur doit charger le registre intermédiaire $R_{D_i}$. Il vient :

charger-D, $R_{D_i}$ ($R_{D_6}$,d)

changer-processus ($R_{D_i}$,a)

Le descripteur de la pile du processus courant figure également dans la D-liste B.
## 6.3 Gestion des entrées-sorties

Les périphériques sont adressés de la même façon que les modules de mémoire. Chaque périphérique apparaît alors à l'unité centrale comme un segment de données, adressable, constitué d'un petit nombre d'emplacements représentant en fait les registres de commande, d'état et de données du périphérique associé.

Il n'existe pas d'instruction particulière d'entrée-sortie. Par exemple l'opération de lecture d'une donnée sur un périphérique est obtenue par une instruction d'écriture d'un mot de commande dans l'emplacement correspondant du segment associé au périphérique. L'écriture dans ce mot qui a la fonction d'un registre de commande déclenche le transfert.

Ce segment de données est repéré par un descripteur qui en assure la protection ; seul le domaine qui possède dans son descriptif (ou la structure qui en dérive) le descripteur du segment peut manipuler le périphérique.

## 6.4 Gestion des fichiers et des catalogues

En plus des domaines de gestion de la mémoire, des processus et des entrées-sorties, le système comporte un certain nombre de domaines partagés, destinés à faciliter la programmation. Ce sont les domaines de :

- gestion de fichiers,

- gestion des catalogues.

Un fichier est un objet construit, constitué d'un ou plusieurs segments, contenant des lignes de caractères représentant, par exemple, le texte source d'un programme. Le domaine de gestion de fichiers permet alors de créer et d'éditer des fichiers.

Un catalogue est une structure permettant de regrouper les noms symboliques de plusieurs entités ; ces entités sont soit des valeurs immédiates, soit des objets élémentaires (D-listes ou segments de données), soit des objets construits (domaines). La structure associée à un catalogue est alors représentée (cf. figure 7), entre autres, par les segments suivants ; mis en correspondance :

- un segment de données, contenant les noms symboliques des entités,

- un segment de données, contenant éventuellement des valeurs immédiates,

- une D-liste, contenant les descripteurs repérant les objets ; les objets construits sont repérés par un descripteur de domaine.
<figure><img src="image_8.png" /><figcaption>Figure 7. Structure d'un catalogue</figcaption></figure>

Le domaine de gestion des catalogues permet de créer des catalogues, et de les gérer (introduction ou retrait de noms symboliques).

# VII ASPECTS EXTERNES DU SYSTEME

## 7.1 Interpréteur de commande

Lorsqu'un utilisateur conversationnel débute une session, l'allocateur crée un processus et le lui associe ; ce processus est lancé dans un domaine particulier, l'interpréteur de commande, qui analyse les commandes tapées par l'usager à son terminal, et qui exécute les actions correspondantes.

**Une commande** est désignée par un identificateur et il lui est associé un programme. Un catalogue général du système, appelé la *librairie des commandes*, regroupe les identificateurs des commandes ainsi que les descripteurs des programmes qui leur sont associés. Certaines commandes fournies par le système permettent à l'utilisateur de se définir ses propres commandes.
Au niveau externe, une commande se présente sous la forme d'un identificateur suivi d'un ou de plusieurs paramètres qui peuvent eux-mêmes être des commandes ; pour permettre à l'interpréteur de commande de préserver l'état d'une commande lors de l'interprétation d'une commande imbriquée, son code est récursif.

Avant d'exécuter l'action requise, le programme associé à la commande doit extraire et évaluer les paramètres. Si le paramètre est le nom symbolique d'un objet, sa valeur (donnée ou descripteur) se trouve dans un catalogue ; si le paramètre est le nom symbolique d'une commande imbriquée, une recherche dans la librairie des commandes permet de retrouver et d'exécuter le programme associé qui délivrera la valeur requise.

**Remarque.** L'interpréteur de commande crée pour la durée de la session un catalogue de travail, propre au processus, et destiné à contenir les identificateurs et les descripteurs (ou les valeurs) des objets créés par l'utilisateur pendant la session.

## 7.2. Commandes d'assemblage

Les commandes d'assemblage sont utilisées pour générer des segments de code. A chaque instruction du calculateur ou à chaque opération programmée du système correspond une commande d'assemblage distincte. L'exécution par l'interpréteur de commande d'une telle commande génère le code binaire de l'instruction ; à une opération programmée correspondent plusieurs instructions.

L'assemblage de tout un programme se fait alors en utilisant la commande "assembler" qui a pour paramètres :

- d'une part, le nom symbolique du segment qui contiendra le code généré,

- d'autre part, la suite des commandes d'assemblage représentant le code symbolique du programme à assembler.

Il existe également des commandes qui permettent de définir de nouvelles commandes, à partir de celles qui existent (macro-assembleur).

**Remarque.** Dans le langage d'assemblage, un descripteur est représenté par le nom symbolique et les droits d'accès du segment qu'il définit.

# VIII CRITIQUES [Ferrié]

Nous étudions dans ce chapitre les limitations que la structure et les mécanismes introduits apportent sur le plan général de la protection et du partage sélectif de l'information dans un tel système.
## 8.1 Point d'entrée d'un domaine et guichet

### 8.11 Notion de point d'entrée

La notion de point d'entrée permet d'assurer la protection du domaine dans la mesure où seuls les appels vers un point d'entrée du domaine sont autorisés. Du point de vue pratique, un point d'entrée est toujours associé à une procédure du domaine ; par contre, toutes les procédures exécutables dans un domaine ne sont pas nécessairement associées à des points d'entrée : elles sont alors dites locales au domaine.

Dans la Plessey, la notion de point d'entrée existe, mais avec certaines restrictions. En effet, tous les segments de code dont le descripteur figure dans le descriptif d'un domaine sont nécessairement associés à des points d'entrée dans la mesure où tout appel du domaine peut se faire vers l'un quelconque de ces segments de code. Notons que la protection est bien assurée, puisque l'exécution du segment de code choisi commence toujours à la première instruction du segment.

Il est cependant possible, au prix d'un effort de programmation, d'avoir des segments de code, locaux à un domaine, et qui n'en soient pas des points d'entrée : il suffit que les descripteurs qui les repèrent, figurent, non pas dans le descriptif du domaine, mais dans la structure de données (D-listes) qui en dérive.

### 8.12 Notion de guichet

On appelle guichet, le droit pour un processus d'appeler un domaine à un point d'entrée donné.

La notion de guichet permet de traduire l'utilisation sélective d'un point d'entrée ; son utilité apparaît dans deux circonstances :

- pour traduire le partage sélectif des points d'entrée d'un domaine entre plusieurs processus,

- pour traduire la variation des points d'entrée d'un domaine, en fonction de l'environnement d'exécution du processus.

Dans la Plessey, quand le descriptif d'un domaine partagé est également partagé, tous les points d'entrée sont accessibles sans restriction et les guichets sont les mêmes pour tous les processus autorisés à parcourir le domaine.

Au contraire quand le descriptif associé à un domaine partagé, est propre au processus qui parcourt le domaine, il est possible, au moment de sa création, de ne pas y faire figurer les points d'entrée inaccessibles ; ceci permet de donner des guichets différents aux processus qui partagent le domaine. Un
processus conserve les mêmes guichets sur ce domaine quel que soit
son environnement d'exécution ; il n'existe aucun mécanisme permettant de
restreindre ces guichets en cours d'exécution.

Ces limitations ont deux conséquences sur l'utilisation des objets
construits (cf chapitre 4) :

- d'une part, le partage d'un objet construit peut être effectué sélectivement, entre plusieurs processus, à condition que le descriptif du domaine qui représente cet objet soit propre au processus.;

- d'autre part, l'utilisation par un processus d'un objet construit se fait toujours avec les mêmes droits et ceci quel que soit le domaine du processus qui utilise l'objet : en particulier, lorsque l'objet construit est transmis en paramètre, il est impossible au domaine appelant de restreindre les opérations possibles sur cet objet.

## 8.2. Manipulation des objets construits

Un objet construit (cf. chapitre 4) est une structure complexe, manipulable uniquement par des procédures bien spécifiques.

Un objet construit est obtenu en regroupant à l'intérieur d'un même domaine :

- le (ou les) segment(s) traduisant la structure de l'objet considéré,

- le code de la (ou des) procédure(s) permettant de le manipuler.

Le domaine est alors la représentation, notée $op_α$, de l'objet (ici $α$) et de la procédure (ici *op*) permettant de le manipuler.

Deux objets $α$ et $β$, de même structure et manipulables par une même procédure *op*, sont représentés par deux domaines $op_α$ et $op_β$ différents qui ont en commun le segment de code de la procédure *op* (figure 8).

Dans le cas où la procédure *op* ne manipule qu'un seul objet $α$ à chaque exécution, la représentation $op_α$ n'apporte aucune limitation par rapport à une représentation, notée $op(α)$, qui séparerait la procédure *op* de l'objet $α$, et qui imposerait la transmission de l'objet $α$ en paramètre.

Les restrictions apportées par la représentation $op_α$ apparaissent quand on veut définir une procédure qui agit, à la fois, sur la structure de plusieurs objets construits (figure 9).
Dans la Plessey l'ensemble des objets α, β, v, qui sont manipulables à la fois, par une même procédure op, ne peut être défini que de façon statique* ; c'est là une solution très lourde comparée à la solution offerte par la représentation notée op(α), dans laquelle les objets α, β, ... manipulables à la fois par la procédure op, sont définis dynamiquement, au moment de l'appel de procédure.

<figure><img src="image_9.png" /><figcaption>Figure 8. Représentation d'objets de structure identique</figcaption></figure>

<figure><img src="image_10.png" /><figcaption>Figure 9. Représentation statique d'objets de structure identique, manipulables simultanément par la même procédure</figcaption></figure>

<footnote>*avant l'appel (au moment de la création des objets par exemple).</footnote>
## 8.3 Problèmes des domaines mutuellement méfiants

Dans la Plessey, il est possible de résoudre, avec certaines restrictions toutefois, les problèmes posés par la coopération des domaines mutuellement méfiants.

Au préalable, nous noterons que les registres de données et les registres de descripteurs (autres que $R_{D6}$ et $R_{D7}$) ne sont pas altérés lors d'un appel ou d'un retour de domaine. Le passage de paramètres entre domaines se fait donc en utilisant ces registres ; en particulier les registres de descripteurs permettent de passer en paramètres, des descripteurs de segments ou de domaines (dans le cas des objets construits).

### 8.31 Méfiance du domaine appelant

- Dans tous les cas, le domaine appelant est assuré que l'objet transmis en paramètre ne pourra être manipulé avec davantage de droits que ceux qui figurent dans le descripteur de l'objet. Toutefois, si l'objet transmis est un objet construit, la limitation apportée par les guichets (cf. 8.12) interdit au domaine appelant de restreindre les droits sur cet objet.

- Le domaine appelant est assuré qu'une erreur d'exécution dans le domaine appelé restera circonscrite à ce dernier ; ceci suppose bien sûr que le domaine appelant a éliminé des registres, les descripteurs des objets qu'il ne voudrait pas voir manipuler par le domaine appelé.

### 8.32 Méfiance du domaine appelé

- Le domaine appelé est protégé contre tout appel du domaine appelant qui ne respecterait pas les points d'entrée (cf. 8.11).

- Dans la mesure où il est possible de lire le contenu d'un registre de descripteur comme une donnée, le domaine appelé peut contrôler que le segment transmis en paramètre possède les droits attendus. Toutefois, dans le cas où l'objet transmis est un objet construit, le domaine appelé n'a aucun moyen de vérifier qu'il est conforme à ce qu'il attendait, parce qu'il n'y a pas d'information dans le descripteur permettant de le faire.

## 8.4. Problèmes liés à la réentrance et à la récursivité des domaines

### 8.41 Réentrance d'un domaine

Nous avons vu que la réentrance était obtenue en associant une D-liste de travail à chaque couple domaine-processus (cf. 3.4).
Si cette D-liste est uniquement constituée des registres de descripteurs, cela impose une gestion spéciale des registres ; en particulier ces registres ne restent propres au domaine que tant que ce dernier n'appelle pas un autre domaine. Du point de vue de la programmation, ceci constitue une grande limitation.

Si au contraire, la D-liste est constituée par une partie du descriptif, cela impose de créer et d'initialiser un descriptif, pour chaque processus, lors du premier appel du domaine. Etant donné qu'il n'y a pas dans la Plessey, d'édition de lien dynamique, qui permettrait de détecter le premier appel d'un domaine non lié, la création et l'initialisation d'un descriptif pour chaque processus doivent être réalisées avant l'exécution du programme.

**Remarque.** Seuls les objets construits qui sont créés dynamiquement par le système et transmis en paramètres, peuvent être représentés par des domaines réentrants.

## 8.42 Récursivité d'un domaine

Le récursivité est obtenue en associant cette fois, une D-liste de travail au domaine, lors de chaque appel du domaine par un processus.

Ceci peut être réalisé de plusieurs façons :

- soit en créant et en initialisant un descriptif, lors de chaque appel du domaine par un processus, étant entendu que ce descriptif serait détruit au retour (pour éviter la prolifération des descriptifs) ; une partie de ce descriptif pourrait alors servir de zone de travail au domaine considéré. Cette méthode ne peut fonctionner correctement que de manière interprétative, par exemple en détectant tous les appels et retours de domaine.

- soit en ayant un descriptif unique partagé par tous les processus qui parcourent le domaine ; dans ce cas, des mécanismes d'adressage particuliers qui n'existent pas dans la Plessey, doivent permettre de garder trace de la D-liste de travail associée à chaque exécution d'un domaine.

## 8.43 Mécanismes proposés

Dans l'hypothèse où le descriptif d'un domaine est unique et partagé par tous les processus, les mécanismes que nous proposons permettent d'assurer à la fois la réentrance et la récursivité d'un domaine.
### 1ère solution

Une première possibilité consiste à utiliser un registre de descripteur particulier, soit $R_{D_8}$, pour repérer la D-liste de travail associée à une exécution de domaine. Ce registre est, au même titre que $CO, R_{D_6}$, et $R_{D_7}$ automatiquement rangé au sommet de la pile du processus lors de l'appel et restauré lors du retour.

Dans ces conditions, la création de la D-liste doit être explicitement programmée, dans chaque point d'entrée du domaine ; sa destruction doit être programmée avant le retour.

La bonne manipulation de $R_{D_8}$ est laissée à la responsabilité du domaine et doit être assurée, en toute rigueur, par le compilateur.

### 2ème solution

Cette solution, voisine de la précédente, utilise comme espace de travail du domaine, la zone dynamique de la pile du processus ; elle évite la création et la destruction explicites de la D-liste.

Le registre non programmable $R_{D_8}$, modifié seulement par les instructions d'appel et de retour, repère, cette fois, dans la pile la zone de travail associée à une exécution de domaine. L'accès à un emplacement de la zone de travail se fait alors en utilisant $R_{D_8}$.

L'instruction d'appel a maintenant pour effet supplémentaire :

- de ranger automatiquement le contenu de $R_{D_8}$ dans la pile,

- de le recharger avec la valeur du sommet de pile.

Son ancien contenu sera restauré, par l'instruction retour.

Ce mécanisme suppose que le sommet de pile est remis à jour, à l'insu du programmeur, à chaque accès à la zone de travail (par câblage, par exemple). S'il n'existe pas d'instruction permettant de lire ce registre, alors la zone de travail reste bien locale à une exécution d'un domaine.
Références :

- Architectural features of System 250
  D.M. ENGLAND (Infotech State of the Art Report 14 - Operating Systems - 1972)

- Capability concept mechanisms and structure in System 250
  D.M. ENGLAND (International workshop on Protection in Operating System - IRIA août 1974)

- A data model based on the capability protection mechanism
  D.C. COSSERAT (International workshop on Protection in Operating System - IRIA août 1974).

- Contrôle de l'accès aux objets dans les systèmes informatiques
  J. Ferrié (thèse de doctorat d'état - Paris VI - 1975).