Déjà c'est une architecture micro-kernel, les drivers ne sont pas dedans : autant que le kernel soit le plus fiable possible, et donc écrit dans un langage plus "sûr". L'idée étant de limiter le C et l'assembleur au strict minimum (bootstrap, HAL). Niveau sécurité, c'est toujours ça de gagné.
Ensuite l'intérêt est de faire tourner le kernel dans le même environnement que les process, pour éviter de le coût des changements de contexte : celà suppose donc d'avoir le même niveau de confiance dans les process que dans le kernel, et donc les mêmes technos (VM/C#/Sing#).
. Qu'on le veuille où non, les drivers utiliseront toujours des pointeurs et c'est dans les drivers que les failles seront trouvées.
Dans Singularity, les drivers sont écrits en Sing# (dérivé de C#) : c'est un langage type-safe qui t'offre un certain nombre de garanties à la compilation contre les bugs les plus classiques, et une vérification de tous les accès mémoires, même par pointeur, afin de t'assurer que la mémoire n'est jamais corrompu (les explications détaillées, notamment à partir de la section 3 dans le doc http://www.cs.kuleuven.ac.be/conference/EuroSys2006/papers/p177-fahndrich.pdf ). Un driver tournant donc dans un environnement "managé", il est isolable, il peut exploser dans son coin, il emporte pas le kernel avec lui dans sa chute.
Sur ce point, l'aspect centralisateur des dépôts est un bon point car les vérifications de l'un participe aux autres. Et puis il est toujours possible de faire tourner tous les analyseurs statiques qu'on veut sur les sources.
Attention, les vérificateurs statiques tournent sur le bytecode et pas sur le code source : bref, chaque "binaire" est vérifié et validé par le kernel lors de son installation. On s'en tapes donc pas mal du côté centralisateur, ce qui compte c'est d'imposer une vérification par le kernel des binaires (qui ne contiennent aucun code natif et invérifiable donc).
Le seul véritable problème dans l'approche de Singularity, c'est l'absence totale de compatibilité avec les softs existants qui produisent du code non vérifable (du code natif). Celà peut paraître rédhibitoire, mais en même temps sur des plateformes "nouvelles" (exemple Windows Phone 7), ils ont franchit le pas : toute application doit être écrite dans du code vérifiable, et vérifier avant mise sur le market.
D'après la doc pointée ci-dessus, ils réfléchissent à intégrer la protection "hardware" à base de ring pour sandboxer les applis natives.
[^] # Re: Bonne interview
Posté par TImaniac (site web personnel) . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à 4.
Déjà c'est une architecture micro-kernel, les drivers ne sont pas dedans : autant que le kernel soit le plus fiable possible, et donc écrit dans un langage plus "sûr". L'idée étant de limiter le C et l'assembleur au strict minimum (bootstrap, HAL). Niveau sécurité, c'est toujours ça de gagné.
Ensuite l'intérêt est de faire tourner le kernel dans le même environnement que les process, pour éviter de le coût des changements de contexte : celà suppose donc d'avoir le même niveau de confiance dans les process que dans le kernel, et donc les mêmes technos (VM/C#/Sing#).
Dans Singularity, les drivers sont écrits en Sing# (dérivé de C#) : c'est un langage type-safe qui t'offre un certain nombre de garanties à la compilation contre les bugs les plus classiques, et une vérification de tous les accès mémoires, même par pointeur, afin de t'assurer que la mémoire n'est jamais corrompu (les explications détaillées, notamment à partir de la section 3 dans le doc http://www.cs.kuleuven.ac.be/conference/EuroSys2006/papers/p177-fahndrich.pdf ). Un driver tournant donc dans un environnement "managé", il est isolable, il peut exploser dans son coin, il emporte pas le kernel avec lui dans sa chute.
Attention, les vérificateurs statiques tournent sur le bytecode et pas sur le code source : bref, chaque "binaire" est vérifié et validé par le kernel lors de son installation. On s'en tapes donc pas mal du côté centralisateur, ce qui compte c'est d'imposer une vérification par le kernel des binaires (qui ne contiennent aucun code natif et invérifiable donc).
Le seul véritable problème dans l'approche de Singularity, c'est l'absence totale de compatibilité avec les softs existants qui produisent du code non vérifable (du code natif). Celà peut paraître rédhibitoire, mais en même temps sur des plateformes "nouvelles" (exemple Windows Phone 7), ils ont franchit le pas : toute application doit être écrite dans du code vérifiable, et vérifier avant mise sur le market.
D'après la doc pointée ci-dessus, ils réfléchissent à intégrer la protection "hardware" à base de ring pour sandboxer les applis natives.