0
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.
> Lire le journal (34 commentaires, moyenne: 3,8).
Vous avez demandé le commentaire #709080.
Run by 
Cette page a été générée par Templeet en 0.0885s (dont 0.0103 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
mouais
Pour des serveurs surchargés je crois que les 10% sont plutôt utiles...
W-Fenec : Webzine rock/métal/indus
[^]Re: mouais
C'est d'ailleurs exactement ce qui est à souligner dans la phrase liminaire de Tanenbaum:
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
>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à ?
On en a beaucoup parlé sur DLFP, il y a IsaacOS http://isaacos.loria.fr/ qui devrait bientôt être libéré.
Wr ar fbhunvgr cnf ha qrfgva sharfgr à yn cncnhgé. Nzra.
[^]Re: mouais
Ca n'est pas exactement le cas, le concept de micro kernel est utilisé par exemple par QNX depuis des années avec une meilleure compacité et un meilleur rendement que Linux, il permet (outre le temps réel) depuis des années de faire des choses que l'on ne peut toujours pas faire simplement et de façon fiable avec Linux (tolérance de pannes, clustering, traitement distribué et autre)
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
Pardon, j'avais oublié le lien
http://www.qnx.com/products/eval/index.html
[+] [^]Re: mouais
Ca n'est pas exactement le cas, le concept de micro kernel est utilisé par exemple par QNX depuis des années avec une meilleure compacité et un meilleur rendement que Linux, il permet (outre le temps réel) depuis des années de faire des choses que l'on ne peut toujours pas faire simplement et de façon fiable avec Linux (tolérance de pannes, clustering, traitement distribué et autre)
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
Pour des serveurs je crois qu'une sécurité accrue est utile...
Le meilleur hébergeur de forums, gratuit et sans pub !
[^]Re: mouais
Une charge plus faible augmente légèrement la sécurité de la machine.
[^]Re: mouais
De quelle manière ? Parce que ça chauffe moins et donc il y a moins de risque d'incendie ?
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
[^]Re: mouais
Si ton serveur est surchargé, un attaquant a beaucoup plus de chance de pouvoir utiliser une faille du style le logiciel verifie que le fichier n'est pas un lien symbolique, c'est okay, quelque instant plus tard il ecrit dedans mais manque de bols quelqu'un a remplacé le fichier par un lien symbolique vers /etc/shadow ...
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
[^]Re: mouais
Ou (mode « j'me la pète ») : les race conditions (comment on dit en français ?) sont plus facilement exploitables.
[^]Re: mouais
Situation de concurrence ?
Condition de concurrence ?
Je suis sûr qu'il y a mieux, mais il m'échappe là tout de suite...
[^]Re: mouais
Course aux ressources / course à la ressource.
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
Pas besoin de remonter jusqu'au noyau pour la sécurité d'un serveur...
- 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
Il dit qu'il voit pas le rapport.
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
Il dit 5, 4, 3, 0 et après, paf, pastèque !
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.