%% %% $Id: slides.mgp,v 1.20 2004/11/08 13:50:08 kilobug Exp $ %% %% (c) Gaël "kilobug" Le Mignot , 2002 %% %% Permission is granted to copy, distribute and/or modify this document %% under the terms of the GNU Free Documentation License, Version 1.1 %% or any later version published by the Free Software Foundation; %% with no Invariant Sections, with no %% Front-Cover Texts, and with no Back-Cover Texts being LIST. %% A copy of the license can be found on http://www.gnu.org/licenses/fdl.html %% %% %% Default settings %% %%deffont "standard" tfont "standard.ttf" %%deffont "thick" tfont "thick.ttf" %%deffont "typewriter" tfont "typewriter.ttf" %deffont "standard" xfont "lucida-medium-r" %deffont "thick" xfont "lucida-bold-r" %deffont "typewriter" xfont "lucidatypewriter" %% %default 1 area 90 90, fore "black", back "white", leftfill, vgap 40 %default 1 font "thick", size 5, vgap 10, prefix " " %default 2 size 2, bar "gray70", vgap 10 %default 3 size 4, fore "black", vgap 40, prefix " ", font "standard" %% %% Default settings that are applied to TAB-indented lines. %% %tab 1 size 4, vgap 40, prefix " ", icon box "blue" 50 %tab 2 size 4, vgap 40, prefix " ", icon arc "purple" 50 %tab 3 size 4, vgap 40, prefix " ", icon delta3 "black" 50 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page %nodefault %area 90 90, fore "black", back "white", leftfill %charset "iso8859-1" %left, font "thick", size 5 %vgap 40 In short: just say NO TO DRUGS and maybe you won't end up like the Hurd people. %right -- Linus Torvalds %font "standard" %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page Introduction Qu'est-ce qu'un système d'exploitation ? Raisons historiques Traitement par lot (batch processing) Unix et le time-sharing Couche d'abstraction vis à vis du matériel Partage de ressources Assure la sécurité %pause Le projet GNU Le Logiciel Libre Liberté 0: libre utilisation Liberté 1: libre modification Liberté 2: libre diffusion Liberté 3: libre diffusion de versions modifiées Naissance du projet GNU Buts du projet GNU %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page Qu'est-ce qu'un noyau Beaucoup de programmes n'ont pas besoin d'accéder directement au matériel. %pause Pour accroître la sécurité, et permettre le partage des ressources, il est nécessaire d'avoir des protections au niveau du matériel. %pause Le matériel doit donc fournir au moins deux modes d'exécution : Mode noyau, où tout est permis Mode utilisateur, où certaines instructions sont interdites %pause On définit ainsi deux espaces au niveau du logiciel : Espace noyau : tout ce qui tourne en mode noyau Espace utilisateur : les autres programmes %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page Systèmes à base de noyaux monolithiques Design traditionnel des Unix Les parties communes à toutes les applications sont en espace noyau : Systèmes de fichier Ordonnanceur Gestion de la mémoire Pilotes de périphériques Couche réseau Beaucoup d'appels systèmes Problèmes : Développement difficile Effets des bugs dans une partie Peu modulaire %area 45 100 50 25 %right %image "monolithique.png" %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page Systèmes à base de micro-noyaux Seules les parties ayant vraiment besoin des privilèges sont en espace noyau : IPC (Inter-Process Communication = communication entre processus) Ordonnanceur basique Gestion de la mémoire basique Les parties essentielles sont en espace utilisateur : Ordonnanceur Gestion de la mémoire Systèmes de fichier Couche réseau (y compris les protocoles) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page Interlude : explication des RPCs Définitions RPC = Remote Procedure Call Implique deux processus: un client et un serveur Fonctionnement Le client indique au serveur la fonction qu'il désire appeler, ainsi que les paramètres (IPC) Le serveur effectue le traitement Le serveur renvoie une réponse avec le résultat Les stubs Permet d'effectuer un RPC en natif (en C par exemple) Ils s'occupent d'encoder et de décoder les paramètres Générés par des programmes: MiG, IDL4 %center, image "rpc.png" %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page Systèmes monoserveurs Un seul serveur, en espace utilisateur, s'occupe de ce que le noyau ne gère plus Exemples : MachOS L4Linux Avantages : Plus indépendant du matériel Développement plus simple Sécurité légèrement accrue Problèmes : Toujours aussi peu modulaire Effets de bord toujours aussi présents %area 45 100 50 20 %right %image "monoserveur.png" %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page Systèmes multi-serveurs Les fonctionnalités sont découpées dans une multitude de serveurs communiquant entre eux Avantages : Beaucoup plus modulaire Plus grande résistance aux failles Développement beaucoup plus aisé Problèmes : Coût des IPCs Nécessité de définir des interfaces %area 45 100 50 25 %right %image "multiserveur.png" %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page Le GNU Hurd Définition Serveurs, bibliothèques et interfaces Vocabulaire : Le Hurd (le Troupeau) : les programmes utilisateurs, pas un OS ni un micro-noyau GNU ou GNU/Hurd: le système complet %pause Buts du Hurd : Coeur du projet GNU Le GNU manifesto URL : http://www.gnu.org/gnu/manifesto.html Redonner la liberté aux utilisateurs Rester compatible, tout en dépassant les limites %pause Interfaces clairement définies, et figées Exemples: création de fichier anonyme, notification Permettre de remplacer des composants Éliminer les problèmes de compatibilité %pause C'est possible : grâce à l'expérience %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page Historique 1983 : Richard Stallman lance le projet GNU 1988 : Mach 3 est choisi comme micro-noyau 1991 : Mach 3 est diffusé sous une licence compatible 1991 : Thomas Bushnell, BSG, fonde le Hurd 1994 : GNU/Hurd boote pour la première fois 1997 : Le Hurd version 0.2 est publié 1998 : Marcus Brinkmann crée la Debian GNU/Hurd 2002 : La Debian GNU/Hurd fait désormais 4 CDs 2002 : Début du port du Hurd sur L4 2002 : Support des threads POSIX 2003 : Sortie de L4Ka: Pistachio 0.1 (puis 0.3) 2004 : Release Candidate d'ext2fs sans limite des 2GO %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page Le micro-noyau Mach : historique L'un des premiers micro-noyaux Projet de Carnegie-Mellon visant à implémenter une théorie relativement récente Beaucoup de nouveaux concepts IPC Conçu pour du multi-processeur et même du clustering External pagers Premier système à définir clairement les notions de tâche, threads, ... Premier micro-noyau à avoir du succès, repris par OSF/1 et d'autres groupes de recherche Base de MachOS OS mono-serveur (serveur UX de compatibilité BSD) Encore développé avec xMach mais s'éloigne des micro-noyaux %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page Le micro-noyau Mach Ce que Mach fait Principe d'une tâche : conteneur IPC complexe VM: algorithme de décision LRU Scheduler basique Gestion des drivers %pause GNU Mach GNU Mach 1.3 GNU Mach 2.0 Utilisation d'OSKit Lent, et buggué %pause Les ports IPCs asynchrones Receive right, send rights %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page Les translators Problème : comment obtenir un port ? Principe des naming services Problèmes Gestion des droits Nécessité de s'enregistrer Peu de flexibilité %pause Idée du Hurd : Utiliser le VFS comme naming service Fonction "file_name_lookup()" Application à `crash' %pause Propriétés d'un translator Programme s'exécutant normalement, sous l'identité de celui qui l'a lancé Hautement multi-threadé pour répondre à des demandes simultanées Répond à des RPCs : Les RPCs de gestion de fichiers : io_*, dir_*, ... D'autres si besoin est : proc_*, ... %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page Exemple de translator %font "typewriter", size 3 (mmenal@drizzt, 42) ~ $ %fore "red", cont id %fore "black" uid=1004(mmenal) gid=1004(mmenal) groups=1004(mmenal),40(src),50(staff),100(users),518(friends),642(hurdfr) %font "typewriter", size 3 (mmenal@drizzt, 43) ~ $ %fore "red", cont settrans -cgap ftp /hurd/hostmux /hurd/ftpfs / %fore "black" (mmenal@drizzt, 44) ~ $ %fore "red", cont cd ftp %fore "black" (mmenal@drizzt, 45) ~/ftp $ %fore "red", cont ls %fore "black" (mmenal@drizzt, 46) ~/ftp $ %fore "red", cont cd ftp.fr.debian.org %fore "black" (mmenal@drizzt, 47) ~/ftp/ftp.fr.debian.org $ %fore "red", cont ls %fore "black" debian debian-cd debian-non-US (mmenal@drizzt, 48) ~/ftp/ftp.fr.debian.org $ %fore "red", cont ls debian/ %fore "black" README README.mirrors.html README.non-US dists indices ls-lR.gz pool tools README.CD-manufacture README.mirrors.txt README.pgp doc ls-lR ls-lR.patch.gz project (mmenal@drizzt, 49) ~/ftp/ftp.fr.debian.org $ %fore "red", cont head -n 2 debian/README %fore "black" See http://www.debian.org/ for information about Debian GNU/Linux. Three Debian releases are available on the main site: (mmenal@drizzt, 50) ~/ftp/ftp.fr.debian.org $ %fore "red", cont cd .. %fore "black" (mmenal@drizzt, 51) ~/ftp $ %fore "red", cont ls %fore "black" ftp.fr.debian.org (mmenal@drizzt, 52) ~/ftp $ %font "standard" %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page La sécurité Jetons d'authentification Qu'est-ce qu'un jeton ? Le serveur `auth' Don, perte et création de jeton Compatibilité POSIX Les UIDs : un exemple de jeton Possibilité d'avoir plusieurs UIDs Possibilité de gagner et perdre des UIDs La commande `addauth' Programmes suid et translators non root Serveur password Principe Application : serveur ssh ou ftp Applications 'noauth' Le login shell Utilité pour le contenu "suspect" : gs, navigateur, ... %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page Interlude: mémoire virtuelle (1) Espace d'adressage virtuel Permet l'implémentation de protections Permet de charger le code n'importe où en mémoire Permet de partager de la mémoire entre applications Traduction effectuée par le matériel (MMU) Segmentation L'adressage se fait par un couple SEG:OFFS Un segment contient une base, une taille, et un mode de protection Segments standards transparents (code, donnée, pile) Permet de "swapper" un segment complet lors d'une pénurie de mémoire physique Limitations Granularité pas assez fine Fragmentation de la mémoire physique Manque de transparence pour les programmes %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page Interlude: mémoire virtuelle (2) Pagination Espace virtuel linéaire, continu La mémoire est divisée en petites pages (4K sur x86) Permet une bien meilleure granularité Transparent pour les programmes Une page peut être : Activée et mappée dans un cadre ( %fore "green", cont vert %fore "black", cont ) Désactivée et transférée dans un support annexe ( %fore "yellow", cont jaune %fore "black", cont ) Invalide ( %fore "red", cont rouge %fore "black", cont ) Accéder à une page non mappée provoque un `page fault' %center, image "virtual-memory-layout.png" %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page Pagination sous Mach Principes Mach décide quelle page garder en mémoire Les `pagers' sont en espace utilisateur Quand un programme `faults', un IPC est envoyé au `pager' %pause %center, image "mach-pager1.png" %pause %center, image "mach-pager2.png" %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page Pagination sous Mach (2) Utilités Implémentation de différents types de stockage Mémoire partagée transparente sur un cluster Utilisation pincipale dans le Hurd: diskfs Principe de diskfs et d'ext2fs Raison de la limite des 2GO Solutions possibles Mapper toutes les méta-données via un arbre de pagers intelligents Avoir un cache de mappings %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page État actuel Ça marche... Cette présentation est projetée sous GNU/Hurd La Debian GNU/Hurd fait 4 CDs On a maintenant un port des threads POSIX %pause ... mais c'est encore en développement Beaucoup de fonctionnalités manquent et certaines limites sont encore présentes Il reste des bugs : on a besoin de plus de testeurs Mach apporte beaucoup de limitations C'est lent C'est principalement dû à Mach Le code n'est pas encore optimisé %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page Le futur: L4 La philosophie L4Ka Définition de concepts basiques et orthogonaux Fournir uniquement les mécanismes de base Faire un micro-noyau le plus petit possible (nano-noyau) Hazelnut: 12K une fois booté ! Toujours garder les performances à l'esprit Des IPCs rapides IPCs synchrones mais RPCs asynchrones Code beaucoup plus petit: pas de pollution des lignes de cache Techniques d'optimisation (multiplexage d'espaces d'adressage, ...) Très peu de choses dans le noyau Des primitives d'IPC Des primitives pour l'ordonnancement Des primitives de gestion de la mémoire En tout : environ 11 appels systèmes %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page La sécurité sous L4 (1) Principes Sous L4, tout ce qui touche au système est fait par RPCs Contrôler les IPCs permet de contrôler l'application %pause Le système Clans & Chiefs Un clan = toutes les tâches crées par un même processus Le processus créateur d'un clan est appelé son chef Un processus ne peut communiquer directement qu'avec : un membre de son clan (un frère) son chef (son père) un membre du clan qu'il a créé (un fils) Les autres IPCs doivent passer par une chaîne de chefs qui peuvent modifier ou rejeter le message %center, image "clans-chief.png" %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page La sécurité sous L4 (2) Le nouveau système : IPC redirect Principe Chaque thread peut avoir un redirecteur qui contrôle les IPCs entrant et/ou sortant Les redirecteurs peuvent être redéfinis en cours d'exécution Raisons du changement Clans & Chiefs trop lourd Décision sur la personnalité de l'OS qui n'a pas à être prise dans le noyau Possibilité d'implémenter Clans & Chiefs Possibilités Surveillance d'applications (débuggage, sécurité) Principe de 'sandboxing' Possibilité d'exécuter du code natif non fiable sans risque Applications: web, contenu interactif %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page Conclusion Références GNU http://www.gnu.org Le GNU Hurd http://hurd.gnu.org Debian GNU/Hurd http://www.debian.org/ports/hurd HurdFr http://hurdfr.org #hurdfr sur irc.freenode.net L4 http://www.l4ka.org Remerciements Copyright (c) Gaël Le Mignot , 2002-2004 Document disponible en GNU FDL sur : http://kilobug.free.fr/hurd/pres-fr/ Questions ?