Bon, on va dire que j'ai peur de voir un modèle comme ça appliqué parce que le système de vérification de code est complexe.
En tous cas, bonne explication! Cela dit, pourquoi ne pas simplement vérifier le code en userspace, pourquoi ré-écrire le code du kernel. Je trouve vraiment pas ça pertinent. Qu'on le veuille où non, les drivers utiliseront toujours des pointeurs et c'est dans les drivers que les failles seront trouvées.
On retombe donc sur un problème de vitesse de résolution de la faille et sur ce terrain, le libre a son intérêt. Même si le kernel n'est pas prouvé, le temps entre la découverte d'une faille et l'arrivée du patch est généralement de quelques heures. Il suffit d'appliquer le correctif sur son kernel et tout est bon. Cela dit, quid des failles pas publiques? Là, on est obligé de limiter l'exécution de code à des binaires plus ou moins prouvés par l'expérience. 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.
Au final, je dirai que l'idée a le mérite d'exister. Comme tu dis, on verra si ça marche en pratique.
[^] # Re: Bonne interview
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à 0.
Bon, on va dire que j'ai peur de voir un modèle comme ça appliqué parce que le système de vérification de code est complexe.
En tous cas, bonne explication! Cela dit, pourquoi ne pas simplement vérifier le code en userspace, pourquoi ré-écrire le code du kernel. Je trouve vraiment pas ça pertinent. Qu'on le veuille où non, les drivers utiliseront toujours des pointeurs et c'est dans les drivers que les failles seront trouvées.
On retombe donc sur un problème de vitesse de résolution de la faille et sur ce terrain, le libre a son intérêt. Même si le kernel n'est pas prouvé, le temps entre la découverte d'une faille et l'arrivée du patch est généralement de quelques heures. Il suffit d'appliquer le correctif sur son kernel et tout est bon. Cela dit, quid des failles pas publiques? Là, on est obligé de limiter l'exécution de code à des binaires plus ou moins prouvés par l'expérience. 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.
Au final, je dirai que l'idée a le mérite d'exister. Comme tu dis, on verra si ça marche en pratique.