Comparer ça aux milliers de lignes nécessaires dans l'OS pour arriver à se passer du concept de ring, c'est osé ;)
Pas tant que ça :
* même simple, le concept de ring reste "hardware" : en cas de faille, t'es pas dans la merde. La simplicité ayant pour seul avantage de diminuer la probabilité, son apparition est critique puisque non corrigeable.
* même simple et non buggé, le concept de ring ne résoud rien s'il y a un bug dans le kernel à travers un appel système : celui-ci peut être exploité et obtient un accès root, ce qui supprime tout le gain de fiabilité offert par la simplicité du ring.
* la "simplicité" a un coup non négligeable (task-switching), qui devient de plus en plus problématique dans un contexte d'architectures et de softs multi-threadés.
Singularity tente une approche différente, l'avenir nous dira si c'était la bonne solution, mais sur le papier c'est pas plus abhérent que le ring, et comparable sur le plan de la sécurité :
* pas d'utilisation des ring hardware : en cas de bug, ca reste patchable. Et puis portable, on le voit aujourd'hui, les architectures CPU bougent.
* pour limiter les bugs dans le kernel, utilisation d'un langage beaucoup plus sûr (Sing# : environnement managé, type-safe, programmation par contrat).
* pour limiter les programmes "dangereux", aucun code natif autorisé, que du code vérifiable ET vérifié avant toute exécution (à l'installation).
* Effet de bord : pas d'utilisation des rings, donc coût de task-switching limité.
Les OS actuels sont "by-design" très mal conçu au niveau sécurité : on fait tourner le code et on prie pour n'avoir laissé aucune faille de sécurité dans les nombreux appels systèmes, qui sont eux-même écrits dans un langage "by-design" nul au niveau sécurité (le langage C). Sans parler des impacts en userland sur les données utilisateurs qui sont difficilement maîtrisables.
Singularity a une approche totalement différente :
* on vérifie en amont que le soft n'est pas dangereux
* on l'exécute dans le contexte d'une machine virtuelle en cas de bug dans l'étape précédente
* on impose un modèle de machine virtuelle qui limite grandement les bugs involontaires des programmeurs pouvant conduire à des failles de sécu.
[^] # 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é à 5.
Pas tant que ça :
* même simple, le concept de ring reste "hardware" : en cas de faille, t'es pas dans la merde. La simplicité ayant pour seul avantage de diminuer la probabilité, son apparition est critique puisque non corrigeable.
* même simple et non buggé, le concept de ring ne résoud rien s'il y a un bug dans le kernel à travers un appel système : celui-ci peut être exploité et obtient un accès root, ce qui supprime tout le gain de fiabilité offert par la simplicité du ring.
* la "simplicité" a un coup non négligeable (task-switching), qui devient de plus en plus problématique dans un contexte d'architectures et de softs multi-threadés.
Singularity tente une approche différente, l'avenir nous dira si c'était la bonne solution, mais sur le papier c'est pas plus abhérent que le ring, et comparable sur le plan de la sécurité :
* pas d'utilisation des ring hardware : en cas de bug, ca reste patchable. Et puis portable, on le voit aujourd'hui, les architectures CPU bougent.
* pour limiter les bugs dans le kernel, utilisation d'un langage beaucoup plus sûr (Sing# : environnement managé, type-safe, programmation par contrat).
* pour limiter les programmes "dangereux", aucun code natif autorisé, que du code vérifiable ET vérifié avant toute exécution (à l'installation).
* Effet de bord : pas d'utilisation des rings, donc coût de task-switching limité.
Les OS actuels sont "by-design" très mal conçu au niveau sécurité : on fait tourner le code et on prie pour n'avoir laissé aucune faille de sécurité dans les nombreux appels systèmes, qui sont eux-même écrits dans un langage "by-design" nul au niveau sécurité (le langage C). Sans parler des impacts en userland sur les données utilisateurs qui sont difficilement maîtrisables.
Singularity a une approche totalement différente :
* on vérifie en amont que le soft n'est pas dangereux
* on l'exécute dans le contexte d'une machine virtuelle en cas de bug dans l'étape précédente
* on impose un modèle de machine virtuelle qui limite grandement les bugs involontaires des programmeurs pouvant conduire à des failles de sécu.