Fonctionnement d'un système d'exploitation

[invite7545251678]

Bonjour,

J'aimerais savoir comment fonctionne un OS car ça me paraît bien flou. Voici en particulier quelques questions dont les réponses pourraient m'aider à améliorer ma compréhension de la "bête" :

Où est-il mis en mémoire ? Qu'est-ce qui le fait démarrer (le bios ?) ?
Qu'est-ce qu'on appelle "noyau" d'un OS (d'après ce que j'ai compris, ce serait un sous-programme qui gérerait les interruptions...) ?
Qu'est-ce qu'on appelle OS en mode superviseur ou en mode utilisateur ?

Merci d'avance pour votre aide
-----

[ProgVal]

Bonjour,

Si par "mettre en mémoire", tu entends "chargé dans la RAM", alors, il s'agit très souvent du début de la mémoire (c'est réglable lors de la configuration du noyau Linux, par exemple)
Lorsque le PC démarre, il lit le disque dur à partir du début (le programme situé dans la ROM est chargé de le faire). Généralement, au début du disque, il y a un gestionnaire de démarrage (Windows Loader, LILO, ou GRUB), qui est un petit programme, te permettant uniquement de choisir quel OS tu veux choisir.

Le noyau, c'est la partie la plus abstraite d'un système (à part HAL sous Windows, mais on peut l'oublier). Linux a un noyau monolythique : il gère tout. Windows a un micro-noyau : le micro-noyau charge ses modules et gère leur façon de "communiquer" entre eux ; chaque module a une fonction : gestion des processus, du matériel, de la RAM, des fichiers, ...

Un OS n'est pas en mode superviseur ou utilisateur, c'est le microprocesseur (un CPU). Ce sont les deux modes d'exécution dans lequel il peut être. Les seuls à devoir se préoccuper de ceci sont ceux qui programment en Assembleur, et il se font de plus en plus rares (surtout sur les PC), même s'il en reste sur les systèmes embarqués.

En espérant avoir répondu à tes questions,
ProgVal

[Towl]

Où est-il mis en mémoire ?

Il n'y a pas de règle, en général, il est mis plutot au début de l'espace d'adressage, mais rien n'empeche de le mettre ou l'on veut

qu'est-ce qui le fait démarrer (le bios ?)

A l'heure actuelle, c'est un poil plus compliqué :
- La première étape est le démarrage d'un mini programme, appelé BIOS. Celui ci se charge en gros de détecter les disques, de faire une mise à 0 des composant, et de chercher le MBR sur le disque.
- Dans le MBR, il y a un champ qui sert à dire ou se trouve la prochaine instruction à exécuter. Le BIOS, une fois qu'il a terminé, fait un saut à cette adresse est execute se programme.
- ce programme est appelé Boot Loader, ou System Loader. Tu en as plusieurs de bien connus (LILO/Grub pour Linux, NTLDR pour Windows NT/Xp/Vista/7, ...). Ce programme offre un premier aspect un peu plus évolué : detection des différents systemes d'exploitation, invite de commande, interface simili graphique,... De meme que le BIOS, une fois un OS sélectionné, il saute à l'adresse correspondant
- démarrage de l'OS à proprement parlé.

Et encore, j'ai simplifié, Grub à part exemple 4 stage lui permettant d'accomplir différentes opération. Mais chacun de ces programmes (BIOS, Boot Loader, OS final) est un OS, plus ou moins minimaliste

Qu'est-ce qu'on appelle "noyau" d'un OS (d'après ce que j'ai compris, ce serait un sous-programme qui gérerait les interruptions...) ?

Un noyau est un programme qui offre différents trucs :
- gestion de la mémoire
- gestion des périphérique
- ordonnancement (quel programme doit s'executer à l'instant T)
- ...
Il existe différents type de noyau, on les distingue généralement en 2 types :
- les noyaux monolythique, qui est un unique programme et qui fait toute ces actions
- les micro-noyau qui eux sont de tout petit programme extremement minimaliste, qui disposent ensuite de "plugins" pour ajouter des fonctionnalités

Linux par exemple est un noyau à la base monolythique, mais avec l'arrivée de la gestion des modules (drivers et autres) devient hybride.
Windows NT à la base à été concu comme un micro-noyau, mais devant la complexité de la tache est devenu hybride.

Des noyaux purement "micro noyau" existent (notamment MACH et Hurd) mais sont plus difficile à développer (perte de performance du au switch insessant entre les modules)

Qu'est-ce qu'on appelle OS en mode superviseur ou en mode utilisateur ?

Pour fonctionner correctement, un noyau doit disposer d'un accès total aux différentes ressources, il tourne alors en mode superviseur, souvent appelé Ring 0 sur les architectures x86 ou kernel land
Au contraire, un programme utilisateur (navigateur, lecteur multimédia,..) ne doit surtout pas disposer d'un accès aux ressources illimité, mais doit plus passer par un programme qui lui donnera des interfaces d'accès. Ce mode est appelé userland (ou ring 4)

Un petit exemple d'un programme qui veut lire un fichier (fait de mémoire, j'ai plus la liste des appels successif en tete ) :
- le programme tourne en userland, fait un appel à la fonction open() pour ouvrir le fichier
- cette fonction est présente dans la dll kernel32.dll (de mémoire) et va vérifier différents trucs (permissions sur le fichier, nom de fichier valide,...). Si la vérification est un succès elle va effectuer un appel systeme (ie générer une interruption)
[switching de contexte, on quitte le mode utilisateur pour passer en mode noyau]
- le noyau va intercepter cet appel et effectuer la demande (donner un pointeur vers le fichier)
[re switching de contexte du mode noyau a utilisateur]
- open nous renvoie le pointeur sur le fichier ouvert

[Towl]

Tiens je me suis fait devancé

Un OS n'est pas en mode superviseur ou utilisateur, c'est le microprocesseur (un CPU). Ce sont les deux modes d'exécution dans lequel il peut être. Les seuls à devoir se préoccuper de ceci sont ceux qui programment en Assembleur, et il se font de plus en plus rares (surtout sur les PC), même s'il en reste sur les systèmes embarqués.

Attention à ne pas confondre mode protégé et mode réél qui sont des modes du processeur avec les rings qui sont des protections associés au mode protégé.
A l'heure actuelle, un OS tourne toujours en mode protégé, mais en Ring 0, contrairement à un programme qui tourne en mode protégé mais en Ring 4

[A voir en vidéo sur Futura]

[ProgVal]

Tiens je me suis fait devancé

En même temps, vu le pavé que tu as écris...

Attention à ne pas confondre mode protégé et mode réél qui sont des modes du processeur avec les rings qui sont des protections associés au mode protégé.
A l'heure actuelle, un OS tourne toujours en mode protégé, mais en Ring 0, contrairement à un programme qui tourne en mode protégé mais en Ring 4

Tu peux expliciter ? J'ai un peu de mal à suivre... (et, aussi : protégé = utilisateur et réel = superviseur, c'est bien ça ?)

[invite7545251678]

Merci pour ces explications. C'est déjà plus clair !

Par contre, j'ai vu qu'on présente la structure d'un OS par 5 couches : un noyau, interface entre le matériel et le logiciel, puis couche qui s'occupe de la mémoire, puis la gestion des périphériques, la gestion des fichiers et enfin l'allocation des ressources.
Or, d'après ce que vous dîtes, tout ce travail est fait par le noyau s'il est monolithique...
C'est bien ça ? on pourrait donc dire que le noyau, c'est en fait l'OS ? sinon, qui a-t-il de plus dans l'OS ?

[Towl]

Tu peux expliciter ? J'ai un peu de mal à suivre... (et, aussi : protégé = utilisateur et réel = superviseur, c'est bien ça ?)

A une époque "lointaine", on considérait que seul un programme pouvait tourner à la fois. Il n'était donc pas nécessaire d'utiliser des subterfuge comme la segmenation / pagination de la mémoire, ni meme d'avoir des zones protégées. Le programme qui tournait disposait alors d'un accès total aux différentes ressources. Ce mode de fonctionnement est dit "mode réél".


Les overflows ont toujours existées et, en mode réél, quand le programme plantait, tout plantait (en meme temps il n'y avait qu'un programme ). Avec l'avénement du multi tache, un programme qui plantait pouvait entrainer les autres, ce qui n'était pas consevable. Il a donc été décidé de mettre en place des méchanisme de protections, notamment au travers de la segmentation (puis pagination) et du concept de ring.
Un ring est un niveau de privilège dans lequel s'execute une application. Sur l'architecture x86, tu as 4 ring, numéroté de 0 à 3, mais généralement seul deux sont utilisés : ring0 et ring3. Le ring 0 dispose d'un accès quasi comparable au mode réel, tandis que le ring 3 est beaucoup plus contraint.

Le passage d'un ring à un autre s'effectue par une interruption, ou par une instruction spécifique (sysenter).

Donc en résumé :
- mode réel : plus utilisé, sauf pour booter le systeme dans un soucis de compatibilité
- mode protégé :
++- ring 0 -> kernel mode, supervisor mode, kernelland, ...
++- ring 3 -> userland, userspace, ...

Par contre, j'ai vu qu'on présente la structure d'un OS par 5 couches : un noyau, interface entre le matériel et le logiciel, puis couche qui s'occupe de la mémoire, puis la gestion des périphériques, la gestion des fichiers et enfin l'allocation des ressources.
Or, d'après ce que vous dîtes, tout ce travail est fait par le noyau s'il est monolithique...
C'est bien ça ? on pourrait donc dire que le noyau, c'est en fait l'OS ? sinon, qui a-t-il de plus dans l'OS ?

C'est bien ca, dans un noyau monolithique, tout est confondu, mais tu retrouves généralement ces différentes couches dans un but de simplification du code. Par exemple, tu as HAL (Hardware Abstraction Layer) qui est un composant qui permet d'avoir le meme comportement, quelque soit le systeme de fichier, de périphérique, en masquant la complexité réel.
Le but d'un code maintenable, c'est d'etre le plus générique et de supprimer au maximum les spécificité pour les regrouper.

Sinon, oui, un noyau, c'est l'OS. Mais par abus de langage, pour beaucoup un OS c'est plus que le noyau. Si l'on prend le cas de Windows, il ne viendrait pas à l'esprit de dire que l'interface graphique ne fait pas partie de l'OS. En fait pour etre exact, Windows n'est qu'une distribution (et l'unique) basée sur le noyau NT (tout comme OpenBSD sur le noyau OpenBSD, FreeBSD sur le noyau FreeBSD, ... ) Par contre tu as une multitude de distributions (Debian, RH, Mandriva, Ubuntu, ..) toute basée sur le noyau Linux

[invite7545251678]

Un petit exemple d'un programme qui veut lire un fichier (fait de mémoire, j'ai plus la liste des appels successif en tete ) :
- le programme tourne en userland, fait un appel à la fonction open() pour ouvrir le fichier
- cette fonction est présente dans la dll kernel32.dll (de mémoire) et va vérifier différents trucs (permissions sur le fichier, nom de fichier valide,...). Si la vérification est un succès elle va effectuer un appel systeme (ie générer une interruption)
[switching de contexte, on quitte le mode utilisateur pour passer en mode noyau]
- le noyau va intercepter cet appel et effectuer la demande (donner un pointeur vers le fichier)
[re switching de contexte du mode noyau a utilisateur]
- open nous renvoie le pointeur sur le fichier ouvert

Si j'ai bien compris, les instructions dans un OS sont de 2 types :
1) les instructions accessibles par toutes les applications
2) les instructions privilégiées (comme le mini programme "open")

Les instructions d'un logiciel sont lues par le processeur qui fonctionne en mode utilisateur. Si celui-ci détecte une instruction privilégiée, il se met en mode superviseur, génère une interruption et passe la main à l'OS.
Si l'OS accorde l'accès à cette instruction, le processeur bascule en mode utilisateur et exécute la fonction. Sinon, l'OS envoie un message d'erreur et le programme "plante".
C'est bien ça ?

[Towl]

Il n'y a pas vraiment d'instruction privilégiée, juste des zones mémoire privilégiées. Un programme qui se trouve en ring 0 dispose des privilèges du ring 0, et inversement.

Exemple :
supposons la mémoire à l'adresse 0x3A en ring 0, et qu'un appel vers cette adresse permette d'envoyer un buffer via la carte réseau 1.
Maintenant supposons le code suivant qui se contente d'appeler la fonction à cette adresse

mov eax, 0x3A
call eax

Si tu es en ring 0, le code va fonctionner correctement, puisque tu aura le droit d'executer la mémoire en ring 0.
Si tu es en ring 3, le code va échouer avec une erreur du type 'failed to read memory'. l'OS ne va prendre aucun initiative et se dire "tiens il essaye d'executer un code privilégié, passons en mode noyau pour qu'il puisse la faire". Le seul moyen de faire cet appel sera donc d'appeler une fonction noyau via un sysenter

; code de l'application
mov edx, 0x44 ; appel systeme correspondant à l'envoi d'un buffer sur la carte réseau
sysenter
; suite du code de l'application
....

; code du noyau apres detection du sysenter 0x44
mov eax, 0x3A
call eax

Donc en reprenant l'exemple de l'ouverture de fichier, voici ce que tu pourrais obtenir :

Tu veux faire un fopen(char* Filename, int Access), fonction très simple pour ouvrir un fichier (2 arguments).

-> Celle-ci va faire un appel à la fonction open(const char* Filename, int Access, ...), un poil plus compliquée (2 ou 3 arguments)

-> Celle-ci va faire l'appel final à la fonction ZwOpenFile( OUT PHANDLE FileHandle, IN ACCESS_MASK DesiredAccess, IN POBJECT_ATTRIBUTES ObjectAttributes, OUT PIO_STATUS_BLOCK IoStatusBlock, IN ULONG ShareAccess, IN ULONG OpenOptions) qui comme tu peux le voir est déjà un poil plus complexe

-> Et que fais ZwOpenFile() ? Elle va lancer un sysenter pour executer la fonction NtOpenFile().

Donc en résumé, tu auras :

              USERLAND                  |      KERNELLAND
fopen() -> open() -> ZwOpenFile() --(sysenter)--> NtOpenFile()

Mais rien ne t'empêche d'appeler directement ZwOpenFile (si tu aimes te complexifier la vie )

En esperant ne pas avoir été brouillon, pas toujours évident d'expliquer ca à l'écrit et sans tableau ^^

Edit: piouf, qu'est ce que j'écris comme pavés en ce moment

[polo974]

Exemple :
supposons la mémoire à l'adresse 0x3A en ring 0, et qu'un appel vers cette adresse permette d'envoyer un buffer via la carte réseau 1.
Maintenant supposons le code suivant qui se contente d'appeler la fonction à cette adresse
Code:
mov eax, 0x3A
call eax

Si tu es en ring 0, le code va fonctionner correctement, puisque tu aura le droit d'executer la mémoire en ring 0.
Si tu es en ring 3, le code va échouer avec une erreur du type 'failed to read memory'.

Il faut aussi dire que si le code d'accès aux données système (ou même d'un autre utilisateur) est en ring 3 (l'utilisateur est maître chez lui, il peut avoir le code qu'il veut), c'est alors la tentative d'accès aux données étrangères qui va déclencher l'erreur d'accès.

(Il me semble que le ring 1 soit maintenant utilisé pour la virtualisation.)

[Towl]

(Il me semble que le ring 1 soit maintenant utilisé pour la virtualisation.)

Oui et non. Un OS est à l'origine concu pour fonctionner en ring 0 et va régulièrement vérifié qu'il est toujours en ring 0. Plusieurs techniques ont été développée pour palier ca :
- modifier l'OS invité pour l'autoriser à tourner en ring 1 (paravirtualisation, avec Xen par exemple). Mais ne va pas fonctionner pour un OS propriétaire ou non supporté
- mettre en place un système de mapping : intercepter les instructions qui permette à un OS de deviner son ring et remplacer ring 1 par 0 à ce moment la. Ce qui est assez couteux en CPU (ancienne virtualisation)
- La virtualisation hardware, avec par exemple les instruction VMX d'Intel. Le principe est d'utiliser des ring négatifs pour l'hyperviseur, les OS invité seront alors toujours en ring 0, mais un ring 0 controlé -> plus besoin de modifier l'OS, pas de perte de performances du à l'interception des appels systemes

[invite7545251678]

En résumé, ring 0 c'est le mode noyau, ring 3 c'est le mode utilisateur ; si un programme (en ring 3) a besoin de chercher des données qui se trouvent dans une zone mémoire en ring 0, il a une instruction sysenter qui permet d'aller chercher ces données.
Mais du coup, n'importe quel programme qui a une instruction sysenter pourrait aller farfouiller en ring 0, non ?

[polo974]

En résumé, ring 0 c'est le mode noyau, ring 3 c'est le mode utilisateur ; si un programme (en ring 3) a besoin de chercher des données qui se trouvent dans une zone mémoire en ring 0, il a une instruction sysenter qui permet d'aller chercher ces données.
Mais du coup, n'importe quel programme qui a une instruction sysenter pourrait aller farfouiller en ring 0, non ?

Non, non, l'instruction sysenter n'est que le bouton de sonnette à l'entrée du système, ensuite le système fait son boulot de système, et c'est à lui de faire attention de ne pas mélanger serviettes et torchons.

[invite7545251678]

Donc il y a bien des zones mémoires dans lesquelles un logiciel utilisateur ne pourra jamais aller piocher des instructions. L'OS veille !!