Bon, à chaque fois qu'il y a une discussion sur les microkernels, tout le monde dit que vraiment c'est super, que c'est plus sécurisé, etc...
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.
# Lancer de troll /o/ ------------- *
Posté par JaguarWan . En réponse au journal La vengeance de Tanenbaum. É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.