Dans le numéro de mai du magazine "Computer" on trouve un article très intéressant d'Andrew Tanenbaum :
http://www.computer.org/portal/site/computer/index.jsp?pageI(...)
Pour rappel Tanenbaum est un des experts mondiaux dans la conception de systèmes d'exploitation. Il a eu une dispute célèbre avec Linus Torvalds aux débuts des années 90 :
http://people.fluidsignal.com/~luferbu/misc/Linus_vs_Tanenba(...)
Linus, qui venait de lancer le noyau Linux, se voyait reprocher par Tanenbaum la conception traditionnelle qu'il avait retenu. Tanenbaum est un partisan résolu des microkernels (il est l'auteur du système Minix qui est un OS basé sur cette approche) et il a critiqué violemment le design monolithique de Linux.
Comme chacun sait ce design n'a pas empêché Linux de se répandre partout dans le monde et de devenir une référence incontournable dans le monde des OS. De plus ce design monolithique s'est trouvé amélioré par la possibilité de charger dynamiquement des modules. Linux n'est donc plus purement monolithique et son design est assez hybride.
Dans l'article de "Computer" tanenbaum annonce le début de la fin pour les noyaux de type Linux: Microkernels—long discarded as unacceptable because of their lower performance compared with monolithic kernels—might be making a comeback in operating systems due to their potentially higher reliability, which many researchers now regard as more important than performance.
Il passe en revue quatre approches qui permettent d'éviter les défauts de Linux, les deux premières étant des rustines sur l'existant qui permettent de conserver le code actuel alors que les deux dernières sont des approches radicales qui nécessitent une réécriture complète :
1) ARMORED OPERATING SYSTEMS
L'idée est d'encapsuler chaque driver dans une couche logicielle protectrice. Celle-ci intercepte les appels entre le driver et le kernel et s'assure de la conformité de ces appels. C'est le projet Nooks dont les buts peuvent se résumer en la protection du noyau contre les bugs des drivers, le redémarrage automatique des drivers fautifs et enfin le changement minimum du noyau Linux actuel.
Même si Tanenbaum reconnait que c'est un projet intéressant et qui peux améliorer la fiabilité, il pointe également le fait que certains bugs passent encore au travers de la couche de protection et que ces couches sont très contraignantes à écrire pour chaque appel noyau existant.
2) PARAVIRTUAL MACHINES
Cette fois-ci on utilise un microkernel réduit à sa plus simple expression directement sur le hardware et on fait tourner par dessus le noyau Linux classique. C'est l'approche de L4Linux ou de Xen. On peut même choisir de faire tourner deux instances de Linux : Une pour les drivers et l'autre pour les programmes en userland. Si une des instances se bloque on peut la tuer et la relancer...mais les processus qui étaient en cours sont perdus.
C'est maintenant que les approches plus radicales commencent (comme l'annonce Tanenbaum : The first two approaches focus on patching legacy operating systems. The next two focus on future systems.
3) MULTISERVER OPERATING SYSTEMS
L'architecture examinée ici est le concept classique de microkernel avec toutes les tâches non essentielles déportées en mode user. Tanenbaum détaille son OS Minix mais on peut également penser au Hurd.
Les avantages sont le confinement et la séparation de chaque processus, la simplicité conceptuelle et le nombre réduit de ligne de code critique en mode noyau. Selon Tanenbaum la puissance actuelle des machines fait que l'approche microkernel est maintenant plus avantageuse que la complexe et dangereuse architecture monolithique. Avec un écart de moins de 10% en performance cela vaut le coup.
On peut également assister à un magnifique lancer de troll :
Minix 3's reliability comes from multiple sources. First, only about 4,000 lines of code run in the kernel, so with a conservative estimate of six bugs per 1,000 lines, the total number of bugs in the kernel is probably only about 24—compared with 15,000 for Linux and far more for Windows.
4) LANGUAGE-BASED PROTECTION
Selon Tanenbaum c'est l'approche la plus révolutionnaire de toute...et c'est Microsoft Research qui poursuit ce but ! C'est un nouveau type d'OS, nommé Singularity, et il est basé sur un language formel spécifique (Sing#) qui permet, par design, une sécurité absolue.
Le kernel et le userland partagent la même adresse mémoire virtuelle (donc les performances sont bonnes) etla sécurité inhérente du language autorise, sans danger, ce partage mémoire.
Le Sing# est largement basé sur le C# mais avec des ajouts spécifiques aux OS (primitive d'envoi de messages, sémantique définie par des contrats formels).
Tanenbaum finit l'article en soulignant que des 4 approches, 3 se basent sur des microkernels.
Il conclut par cette phrase qui résonne comme une revanche sur la vieille controverse :
it is interesting to note that microkernels—long discarded as unacceptable because of their lower performance compared with monolithic kernels—might be making a comeback due to their potentially higher reliability, which many people now regard as more important than performance. The wheel of reincarnation has turned.
Journal La vengeance de Tanenbaum
7
mai
2006
# Révolutionnaire != Radical
Posté par Pinaraf . Évalué à 9.
Il dit qu'elles sont les plus radicales.
Ce concept serait révolutionnaire s'il était neuf, or Tanenbaum parle d'un ordinateur "Burroughs B5000" qui utilisait déjà ce concept.
# mouais
Posté par Pooly (site web personnel) . Évalué à 1.
Pour des serveurs surchargés je crois que les 10% sont plutôt utiles...
[^] # Re: mouais
Posté par lesensei . Évalué à 9.
Et je suis sûr que c'est la réponse que lui fera(it) Linus, comme il y a presque 15 ans: que la différence entre eux est que l'un est un chercheur, l'autre un technicien. Pendant que l'un théorise, l'autre a les mains dans le cambouis, et ne démordra pas de son idée...
Indépendamment, avoir un OS basé sur un langage similaire à Sing# en GPL serait probablement interressant pour le futur. À moins que ça existe déjà ?
[^] # Re: mouais
Posté par agmk . Évalué à 7.
>en GPL serait probablement interressant pour le futur. À moins que
>ça existe déjà ?
On en a beaucoup parlé sur DLFP, il y a IsaacOS http://isaacos.loria.fr/ qui devrait bientôt être libéré.
[^] # Re: mouais
Posté par brazz . Évalué à 10.
Son temps de commutation est hyper rapide, je me souviens avoir pu faire tourner des dizaines de process sur un 80386 serveur de télécoms ! Je n'ose pas imaginer le nombre qu'il peut faire tourner su un PC d'aujourd'hui...
C'est pour cela (rapidité, fiabilité et capacité) qu'il est massivement employé dans l'industrie, l'aéronautique, la médecine,etc domaines où ne peut pas avoir le luxe d'une erreur.
On peut récupérer des disquettes (!!!) ou CD de démo si l'on veut vérifier tout cela.
Evidemment le problème c'est qu'il est propriétaire...Mais cela n'enlève rien au fait que ça marche, et même bien!
Malgré toute mon estime pour ses travaux, je n'ai jamais compris pourquoi Linus s'obstinait hargneusement à nier l'intérêt du micro kernel, je pense que c'est d'ordre psychanalytique comme beaucoup de querelles de chercheurs, raison de plus pour montrer un peu de sagesse et de distance par rapport à ça.
[^] # Re: mouais
Posté par brazz . Évalué à 2.
http://www.qnx.com/products/eval/index.html
[^] # Re: mouais
Posté par brazz . Évalué à -2.
Son temps de commutation est hyper rapide, je me souviens avoir pu faire tourner des dizaines de process sur un 80386 serveur de télécoms ! Je n'ose pas imaginer le nombre qu'il peut faire tourner su un PC d'aujourd'hui...
C'est pour cela (rapidité, fiabilité et capacité) qu'il est massivement employé dans l'industrie, l'aéronautique, la médecine,etc domaines où ne peut pas avoir le luxe d'une erreur.
On peut récupérer des disquettes (!!!) ou CD de démo si l'on veut vérifier tout cela.
Evidemment le problème c'est qu'il est propriétaire...Mais cela n'enlève rien au fait que ça marche, et même bien!
Malgré toute mon estime pour ses travaux, je n'ai jamais compris pourquoi Linus s'obstinait hargneusement à nier l'intérêt du micro kernel, je pense que c'est d'ordre psychanalytique comme beaucoup de querelles de chercheurs, raison de plus pour montrer un peu de sagesse et de distance par rapport à ça.
[^] # Re: mouais
Posté par Sufflope (site web personnel) . Évalué à 2.
[^] # Re: mouais
Posté par Manger sur pattes . Évalué à 2.
[^] # Re: mouais
Posté par Krunch (site web personnel) . Évalué à 4.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mouais
Posté par inico (site web personnel) . Évalué à 5.
[^] # Re: mouais
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
[^] # Re: mouais
Posté par Lucas Bonnet . Évalué à 2.
Condition de concurrence ?
Je suis sûr qu'il y a mieux, mais il m'échappe là tout de suite...
[^] # Re: mouais
Posté par Sylvain Sauvage . Évalué à 3.
Il ne me semble pas très utile d'intégrer un terme reprenant condition : « il y a une course aux ressources » ou « une course aux ressources est possible », pas besoin d'alourdir avec « situation ».
[^] # Re: mouais
Posté par JaguarWan . Évalué à 4.
- source en php ou autre langage web qui n'escape pas ou mal ses requêtes SQL peut permettre défaçage, destruction/vol de données en base, emprunt de compte utilisateur, ...
- httpd troué ou mal configuré, c'est une possibilité de DoS ou de leak du code source php/perl/whatever
- ftpd troué ou mal configuré = un stro plein de warez potentiel (DoS et vol/destruction de données à envisager aussi)
etc...
Il y un bon nombre de couches logicielles entre le noyau et ce qui est exposé au réseau, et c'est autant de vecteurs d'attaque.
[^] # Re: mouais
Posté par renaud . Évalué à -3.
Tu le fais exprès ou quoi ? En théorie, avec un système comme ça, si ton caca est daubé, il foutra la merde dans la limite de ses privilèges, dont le noyau ne fait pas parti.
[^] # Re: mouais
Posté par JaguarWan . Évalué à 9.
Je voulais tout bêtement dire qu'un vil pirate écumant les sept mers de l'internet n'a pas besoin de s'amuser à exploiter un bug obscur de la pile tcp/ip pour piller, voler et violer quand il peut simplement mettre un bout des quotes et un morceau de sql dans un formulaire pour pourrir la base de donnée ou récupérer son contenu (et donc arriver à ses fins).
Le jour où les forbans virtuels n'auront plus d'autres possibilité que de mettre des shellcodes de 42 octets dans un paquet icmp très spécial pour prendre un serveur à l'abordage n'est pas encore arrivé je pense.
# plop
Posté par ced . Évalué à 4.
J'aurai quand même appris quelque chose aujourd'hui finalement (c'était mal parti pourant).
# Vive l'ASM !
Posté par Guillaume Knispel . Évalué à 5.
Le Sing# est largement basé sur le C# mais avec des ajouts spécifiques aux OS (primitive d'envoi de messages, sémantique définie par des contrats formels).
On peut donc coder n'importe quoi si on connait l'asm ? ;)
[^] # Re: Vive l'ASM !
Posté par ced . Évalué à -1.
The microkernel
(...) Although most of the microkernel is written in Sing#, a small portion is written in C#, C++, or assembler ...
Alors oui on peut coder n'importe quoi si on connait l'asm, mais cela n'est possible que dans le micro-noyau, et absolument pas dans un pilote ni dans un quelconque autre programme en user mode. Et heureusement sinon ça n'a plus aucun intérêt.
[^] # Re: Vive l'ASM !
Posté par TImaniac (site web personnel) . Évalué à 2.
http://msdn2.microsoft.com/fr-fr/library/62bwd2yd.aspx
Pour tout le reste (code "vérifié"), les accès mémoires sont contrôlés à l'exécution pour éviter d'aller taper n'importe où dans la mémoire.
Une fois cette étape de vérification effectuée, le moteur JIT va compiler le code "managé" en code natif et zou.
# Contrat
Posté par outs . Évalué à 5.
J'ai été voir (pas très profondement) sur le site et Sing# c'est de la programmation par contrat (ou alors j'ai loupé des bouts) mais ce n'est pas suffisant par assurer une sécurité absolue. C'est la même chose que pour eiffel ou tout ce qui a suivi, en fait c'est une méthode semi-formelle et comme on ne fait pas de preuves de corrections on n'a pas de sécurité absolue. Enfin rien n'empèche de faire les preuves a postériori mais les approches de certifications de programmes qui collent trop au code sont très difficiles à mener a terme.
C'est marrant cela ressemble énormément à isaac (contrat+objet).
[^] # Re: Contrat
Posté par Ontologia (site web personnel) . Évalué à 3.
Ca fait deux ans que je connais Singularity et que j'y penses quelques-fois.
Il faudrait dans l'idéal :
1/ Preuve formel des contrats, voir pour cela http://why.lri.fr
2/ Que l'OS ait une réfléxivité sur lui même au moyen d'une ontologie qui lui permettrai de structurer sémantiquement son organisation. On pourra alors concevoir des systèmes d'autoréparations, etc...
3/ Un méta-langage de programmation
Je travaille sur le 3/ de plus en plus, en commançant par le bas niveau.
Ca donne :
- Connaissance de la sémantique des données par le compilateur (sources XML, BDD, etc... par connaissances des grammaires, modèle de donnés respectifs (DTD, MLD,...))
- Pré structuration des données en fonction de la structure de celle-ci
- Généralisation du pattern matching
Exemple, je récupère pour tous mes client l'ensemble des références achetées et voudrait savoir quels sont pour chacun d'entre les plus achetées. Je voudrai aussi savoir si ceux-ci on acheté mon nouveau produit dont la référence est du type "ZX80-xxxxx", et enfin repérer ceux qui m'achète pour plus de 10 000 ¤ par référence (pour leur faire un prix spécial).
J'évite de demander au SGBD de faire le boulot.
Ne faites pas attention à la syntaxe, elle est pourrie.
Req := BDD.query "select nom_cli, ref_achetee, qte, prix_unit from commande_ligne";
Req.group by nom_cli;
// Req est une liste de struct où la struct contient un nom, une liste de ref, qte, prix
Tri_cli := Req.for_each nom_cli do
Req.select ref_achetee, sum(qte*prix_unit) as px_tot group by ref_achetee order by sum(qte*prix_unit);
let rec f l =Tri_cli.for_each
Règle1 : Match (e=(px_tot > 10 000))::[] -> Cli_special.add e |
Règle2 : Match (e=(ref_achetee.match "ZX80-[\w]{5}"))::[] -> Cli_techno.add e |
Règle3 : Match t::q and (not Règle1) and not (Règle2) -> f(t) ; f(q);;
f(Tri_cli);
L'idée c'est de mélanger le pattern matching de type avec le contenu des données en posant des contraintes. Idéal pour XML....
Bon stop, j'arrête de délirer....
En attendant, je cois beaucoup au concepts que j'ai conçu pour mettre dans Lisaac que sont les agents.
On pourrait faire beaucoup de choses avec un OS entièrement constitués d'agent autonomes (des threads) à mémoire étanche (toute transmission de données se fait par copie) basé sur de l'évènementiel.
http://wiki.loria.fr/wiki/0.5 (Outs, merci pour la remise en page ...)
Je crois que le concept est encore à largement affiner, mais ça permettrait de se simplifier la vie... et de tomber dans de gros bordel (pas facile de gérer les effets de bords des logiciels émergeants...)
IsaacOS va pour l'heure quand même beaucoup plus loin que Singularity qui reste un OS à micronoyau.
Il n'y a tout simplement plus de noyau dans IsaacOS....
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Contrat
Posté par viridis (site web personnel) . Évalué à 2.
Le projet venait d'ailleurs d'être mis sous GPL et j'ai donc 1 petites questions :
Où/quand pourra-t-on avoir accès aux sources ?!!
[^] # Re: Contrat
Posté par Ontologia (site web personnel) . Évalué à 4.
On le mettra en place quand Benoit aura eu le temps de finir d'écrire le compilo (il arrive au bout l), le débugguer, virer les bouts de codes qui appartienent à ST, me le filer pour que je le nettoie et surtout le commante, qu'on le teste avec le nouveau compilo, qu'on créer un distrib qui marche (une image qemu ou un truc de ce genre).
Bref qu'on ait le temps de faire un truc propre.
Je pense que d'ici juillet/août, ça devrait être bon, tout dépendra des tuiles qui nous tomberons dessus.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Contrat
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
# Tuer le troll
Posté par GTof . Évalué à 4.
Le débat entre micro noyaux et noyaux monolithiques n'a plus aucun sens, car les micro noyaux tout comme les noyaux monolithiques sont obsolète ! L'avenir appartient aux systèmes sans noyaux. Comme dirait Andy :
Parmi les systèmes sans noyau, il y a TUNES ( http://tunes.org/wiki ) qui pour l'instant n'a pas encore produit de code mais qui a de la documentation très riche et intéressante. Unununium ( http://unununium.org/ ) qui lui a du code mais très peu de documentation. Pour Unununium le site n'a pas été mis a jour depuis un an mais la mailling liste est active et biensur IsaacOS ( http://isaacos.loria.fr/ ) qui est bien connu ici.
Quand à l'approche radicale pour enfants de Singularity, laissez moi rire. Voici le descriptif du projet TUNES (tiré de http://tunes.org/tunes.html ) :
CA c'est du radical ! Quel petit joueur cet Andy ... ;)
[^] # Re: Tuer le troll
Posté par Ontologia (site web personnel) . Évalué à 1.
J'ai lu la "publi" de FR Rideau (le genre de type qui crie haut et fort que Pinochet est un gentil dictateur parce qu'il est néolibéral, voyez ? ), et franchement, malgré mes efforts, je n'ai rien pu en tirer d'autres que des désirs, mais rien de conceptuellement nouveau.
Je pense personnelement que son but se réalisera grace à des langages ontologique à reconnaissance de forme.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Tuer le troll
Posté par pierthi . Évalué à 9.
-----> [] (et vite)
[^] # Re: Tuer le troll
Posté par Achille Fouilleul (site web personnel) . Évalué à -3.
J'en comprends plutôt que Pinochet était un moins grand malheur pour le Chili qu'Allende. Un de ses textes renvoie vers un texte de Kasparov que j'ai trouvé intéressant: http://www.economiaysociedad.com/kasparov.html
[^] # Re: Tuer le troll
Posté par Nicolas Roard (site web personnel) . Évalué à 9.
C'est marrant, ça me donne physiquement envie de gerber. Je pense à umberto, un ami de ma copine, un poète, qui est parti en exil au royaume-uni après avoir été torturé...
Nan mais c'est sûr, d'après FR Rideau, le salaud, c'est pas pinochet, non non, c'est umberto, qui en toute probabilité était d'après lui un commissaire politique, immonde communiste avide de sang. Au mieux, umberto est juste un "idiot utile". Ben tient. Pauvre con va.
Mais qu'il aille se faire voir ce pauvre type, moi je vais allez vomir de mon côté.
Note: Comment peut on vouloir justifier des horreurs (pinochet) par d'autres horreurs (stalinisme et autres khmer rouges) ... et après ça parle de relativisme moral... pfff..
On est pas dans un modèle théorique de jeu à somme nulle, on peut très bien condamner les deux. À trop idéaliser le libéralisme (économique) hein...
# Lancer de troll /o/ ------------- *
Posté par JaguarWan . Évalué à 9.
Moi je dois être idiot mais je vois pas vraiment en quoi c'est tellement plus secure :)
Je m'explique:
Le 'compatimentage' des microkernel ça évite de tout planter si un driver se rate en déréférençant un pointeur NULL ou se pourrit la mémoire, certes.
Mais d'après ce qu'on voit des changelogs du noyau Linux, c'est pas tellement les buffer overflows ou les pointeurs NULL qui mettent le bazar dans la vraie vie, mais bien souvent des race conditions, des deadlocks, des integer overflows ou des trucs vicieux du même style.
Ces erreurs là, un design microkernel ne les empêche pas. J'irais même jusqu'à dire qu'un microkernel peut éventuellement rajouter des sources de race conditions/deadlock avec ses systèmes complexes d'IPC internes qu'on n'a pas dans un noyau monolithique.
D'autre part, vu qu'au final un driver doit bien piloter le matériel physique, en quoi un microkernel peut empêcher un driver foireux de faire un DMA sur un bout du noyau (entraînant un affreux panic) ?
Le principe du 'un driver plante mais pas tout le noyau' peut aussi devenir inutile dans certains cas. Par exemple, agpgart plante et n'est pas récupérable, mais radeon est toujours aussi fringuant. Ça me fait une belle jambe :)
Donc en résumé, je suis tout à fait d'accord que le design microkernel permet de mitiger les risques liés essentiellement aux corruptions mémoires dans les drivers, mais je ne trouve pas que ça soit LA solution pour avoir un noyau sécurisé car ça ne couvre qu'une petite partie des sources d'erreur au prix d'une complexité non négligeable introduite par les IPC.
A mon avis, rien ne vaut du code propre et bien audité si on veut quelque chose de secure, genre le kernel monolithique d'OpenBSD...
Corrigez moi si je me trompe :)
P.S: je pense que c'est valable pour ces OS écrits en langages exotiques aussi, car ils ne font qu'éviter de pourrir la mémoire à priori.
[^] # Re: Lancer de troll /o/ ------------- *
Posté par GTof . Évalué à 6.
Evidemmennt les micro noyaux ne sont pas LA solution pour éradiquer tous les bugs, si ton programme est foireux, il est foireux, la séparation va seulement limiter l'impact des bugs. Je donnais l'exemple de fglrx qui parfois fait tout planter. Lors de démonstration de Hurd, le conférencier avait killer le prog en charge de sa partition home, le système n'a pas bronché et a redémarrer le prog, les services qui n'utilisaient pas la partition home n'ont pas été affecté. Sur un serveur, il serait dommage qu'un plantage du driver de la webcam qui sert a la vidéo surveillance fasse planter tout le système et par conséquent le serveur ssh qui aurait permis de réparer le problème.
Je pense que l'architecture micro noyaux n'est pas une fin en soit mais un moyen de dépasser les limites actuelles. Sous linux les modules sont en espace noyaux, il est donc nécessaire pour la sécurité que n'importe qui ne puisse pas en charger. Pourtant si veut monter un système de fichier sur une machine sous linux où on est pas root, on y était bien obligé. Depuis il y a FUSE, et si on regarde les projets de systèmes de fichiers implémenté avec FUSE, certains sont bien rodés (sshfs est une merveille) et serait peut être intégrés dans le noyaux sans trop de résistance, d'autres sont encore instables et jamais il n'aurait été mis dans le noyaux, et même s'ils était disponibles en module séparés, aucun admin sérieux ne les chargerait.
D'autre part, avoir des drivers en tant que simple programme en espace utilisateur permet de choisir son langage de programmation, je suis d'accord que c'est aussi faisable dans le noyaux, mais des programmes en O'Caml, C++, Java,... demanderaient qu'une run-time soient codé dans le noyau, personnellement je ne croient pas que ce soit ajouté un jour. La capacité de développer des drivers dans des langages de haut niveau elle aussi limite les bugs, prennons le cas de O'Caml, la gestion de la mémoire, le typage static fort, ... évite de nombreux bugs (mauvais ordre des paramètres, mauvais calcul de pointeur, etc ...) et tous ceux qui font l'amalgame entre langages de haut liveau et lenteur iront se référer aux performance du compilateur d'O'Caml.
Quoi qu'on en disent et même si on s'appelle Linus, l'approche micro noyau s'imposera, non pas pour faire plaisir a Tanenbaum ou pour éradiquer les bugs (sinon personne ne serait plus sous windows) mais pace que on veut de la flexibilité et de la simplicité (je considre qu'il est plus simple de programmer son fs en fuse, que de l'intégrer au noyau). C'est pas pour rien que Linux est passé a un système modulaire et lorgne de plus en plus sur le userspace (udev, fuse, ...).
# Andrew Morton : "Trop de bugs dans le noyau 2.6"
Posté par Sébastien TeRMiToR . Évalué à -1.
http://www.quebecos.com/modules/news/article.php?storyid=132(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.