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_mutex
— source
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.