David Madore's WebLog: Il faudrait faire une analyse statistique des bugs dans Linux

Index of all entries / Index de toutes les entréesXML (RSS 1.0) • Recent comments / Commentaires récents

Entry #2289 [older|newer] / Entrée #2289 [précédente|suivante]:

(samedi)

Il faudrait faire une analyse statistique des bugs dans Linux

J'assistais cette semaine, dans le cadre du séminaire Codes sources (dont j'ai déjà dit un mot, et où j'interviendrai moi-même plus tard ce mois-ci), à un exposé de Greg Kroah-Hartman, un des principaux développeurs du noyau Linux (et le mainteneur des noyaux stables/longterm). L'exposé portait sur la manière dont le noyau a commencé à introduire des concepts de programmation orientée objet, en partant du struct device, qui s'est mis à « hériter » de struct kobject puis de struct kref (cet héritage étant cependant sans fait aucune sécurité de typage statique ni vérification à l'exécution, et assuré — de façon très efficace — par la magie de l'arithmétique de pointeurs et de la macro container_of, au sujet de laquelle voir par exemple ici). Je peux peut-être juste lui reprocher d'avoir été un peu rapide (par exemple quand il a discuté de la fonction kref_put_mutexsource ici, cherchez le nom de la fonction — et expliqué pourquoi elle marchait et pourquoi une version antérieure contenait une race-condition, je n'ai pas vraiment eu le temps de digérer). Mais une chose est certaine : malgré des efforts pour harmoniser les API et les rendre plus systématiques et pratiques, la programmation de pilotes de périphériques pour Linux est difficile (et la programmation de nouveaux bus est, à ce qu'a dit l'orateur, extrêmement difficile). (La question a évidemment été posée de si le noyau devrait ou pourrait être programmé dans un autre langage que le C. Greg KH a brièvement mentionné Rust — ce qui m'a fait plaisir, parce que c'est un langage qui me semble très prometteur — mais il est évident que pour l'instant c'est de la science-fiction de penser changer quelque chose d'aussi profond.)

Mais ceci m'amène à une question qui me fascine, et sur laquelle je pense qu'il faudrait vraiment lancer une recherche un peu approfondie :

Peut-on approximer le nombre de bugs (et si possible, plus finement : le nombre de trous de sécurité, par exemple) qui existent actuellement dans Linux ? Peut-on évaluer la probabilité qu'un organisme un tant soit peu motivé (au hasard : la NSA) ait connaissance d'un tel bug qu'il ne dévoilerait pas, voire, en ait planté un volontairement, et la difficulté d'une telle entreprise ?

Je parle d'essayer de faire mieux qu'une estimation « au doigt mouillé », mais de mettre en place des modèles probabilistes un peu sérieux, à la fois de l'apparition des bugs dans le code et de leur détection. Puis fitter ces modèles contre toutes les informations qu'on peut extraire de l'arbre des commits Git et les bugfixes dans les noyaux stables.

Le modèle le plus grossier serait déjà de dire que chaque ligne de code ajoutée comporte une certaine probabilité — à déterminer — de contenir un bug, et que chaque unité de temps qu'elle reste dans le noyau apporte une certaine probabilité — à déterminer aussi — que ce bug soit détecté et corrigé. Rien qu'avec ce modèle grossier, en regardant depuis combien de temps existent les bugs qui sont corrigés dans les noyaux stables, on devrait pouvoir se faire une idée d'un ordre de grandeur du nombre de bugs et de trous de sécurité existant, et de combien de temps il faudrait continuer à maintenir un noyau stable/longterm pour qu'il y ait au moins 99% de chances qu'il ne contienne plus un seul trou de sécurité. Ensuite, on peut améliorer ce modèle de toutes sortes de façons : en raffinant selon l'auteur du code ou le sous-système où il s'inscrit (ou son mainteneur), en essayant d'estimer le nombre de fois que le code a été relu ou utilisé, en catégorisant finement les bugs, ou toutes sortes d'autres choses du genre.

C'est le genre d'idée extrêmement évidente dont je n'arrive pas à comprendre qu'elle n'ait pas déjà été poursuivie (et pourtant je ne trouve rien de semblable en ligne). Ça a pourtant tout pour plaire : on peut y glisser les mots-clés de sécurité informatique, de logiciel open source, de Big Data (la dernière connerie à la mode : il faut que tout soit à la sauce du Big Data maintenant), les conclusions d'une telle étude pourraient certainement intéresser la presse et leur fournir des gros titres racoleurs (cf. la NSA plus haut), ce serait d'ailleurs certainement le genre de choses qui aurait sa place dans, disons, une grande école spécialisée en télécommunications et informatique (exemple complètement au hasard). Mais bon, dans le monde actuel de la recherche, qui fonctionne par « projets » (i.e., par bullshit-scientifique-transformé-en-paperasse-administrative), tout est fait pour couper court à toute forme de créativité ou d'originalité : on ne peut faire quelque chose qu'en étant bien établi dans un domaine et en passant à travers un tel nombre d'obstacles dressés par des organismes à la con (ceux qui sont censés donner des sous pour aider la recherche, et qui dans la réalité servent surtout à faire perdre du temps) qu'il est quasiment impossible de se lancer — pour ma part, je serais certainement intéressé par un projet comme celui que je décris ci-dessus, mais pas au point de passer le temps délirant en écriture de rapports en tout genre qu'il faut soumettre pour obtenir quoi que ce soit de qui que ce soit.

↑Entry #2289 [older|newer] / ↑Entrée #2289 [précédente|suivante]

Recent entries / Entrées récentesIndex of all entries / Index de toutes les entrées