Le projet GNU Boot est bien embêté : pour la deuxième fois en moins d’un an, l’équipe de développement s’est retrouvée à pousser du code propriétaire dans leur logiciel. Problème, le projet se veut 100 % libre. Le cas illustre la difficulté du monde open source et libre à prévoir du support matériel avec les marques courantes.

GNU Boot est un jeune projet 100 % libre dont la mission est de remplacer le logiciel responsable de l’amorçage de la machine. En ligne de mire, les BIOS et autre UEFI. L’idée est bien de se débarrasser de tout code propriétaire. Comme l’indique la page dédiée de GNU.org, il ne s’agit pas d’un projet développé depuis zéro, mais d’une distribution, dans le sens où le projet rassemble des logiciels existants comme Coreboot, GRUB et SeaBIOS.

Quand il est installé, GNU Boot est donc responsable de l’initialisation de la machine et du passage de relai au système d’exploitation. Pour une personne voulant se débarrasser de tout code propriétaire sur son ordinateur, GNU Boot est donc un composant important. La philosophie et l’éthique du libre sont prépondérantes pour une partie des utilisateurs.

Or, les développeurs ont prévenu il y a quelques jours qu’ils avaient découvert du code non libre dans une mise à jour. S’ils ne s’en sont pas rendu compte avant, c’est que le code en question n’est pas directement dans le logiciel, mais dans les données de test qui ont été utilisées. Explications.

Des données de test propriétaires

Dans une annonce publiée le 19 octobre, l’équipe de développement a annoncé une découverte désagréable : du microcode non libre dans la Release Candidate de GNU Boot 0.1.

On apprend ainsi que le code source de vboot utilisé dans Coreboot et dans le paquetage vboot-utils (disponible dans de nombreuses distributions GNU/Linux) contient du code non libre. Ce dernier est présent dans les données de test situées dans tests/futility/data. On y trouve ainsi du microcode, des BIOS et firmwares non libres.

Les fichiers tarballs correspondant ont donc été recréés pour se débarrasser des intruses. L’équipe ajoute que le processus a été modifié pour que le problème ne se reproduise pas. « Nous stockons maintenant les changements dans le tag à l'intérieur de notre dépôt git et régénérons simplement les tarballs avec le système de construction disponible pour un tag donné », indiquent les développeurs.

Problème, le composant vboot, dans lequel résidait ces données, est présent dans de nombreuses distributions. L’équipe en charge de GNU Boot essaye donc de les joindre pour les avertir du problème. Si la difficulté concerne avant tout les distributions 100 % libres, d’autres systèmes plus communs sont également concernés, comme Debian et Fedora. Bien que du code propriétaire puisse être présent en fonction des choix de l’utilisateur, certains dépôts ne doivent contenir que du logiciel libre.

Le logiciel libre face au matériel courant

Les personnes rompues au logiciel libre le savent : concevoir des composants ou des pilotes n’est pas toujours simple, en fonction du matériel. NVIDIA est un cas emblématique, le pilote libre pour gérer ses GPU sous Linux étant beaucoup moins poussé que le pilote propriétaire. Lequel pose souvent problème dans la prise en charge de certaines technologies, comme on l’a vu à plusieurs reprises avec Wayland.

Ce n’était d’ailleurs pas la première fois que GNU Boot était embêté sur ce point. En décembre 2023, les mêmes développeurs s’étaient en effet aperçus que du code propriétaire était présent dans le logiciel. Il provenait principalement de microcode destiné aux processeurs AMD et pour certains ports de cartes mères.

Le cas était déjà intéressant. La mise à jour du microcode pour les cartes mères KCMA-D8, KFSN4-DRE et KGPE-D16 d’ASUS avait ainsi été abandonnée, alors que ce matériel est encore populaire chez les personnes souhaitant utiliser facilement Coreboot/Libreboot, dont GNU Boot est un fork.

C’est un souci récurrent du code 100 % libre. Les développeurs n’ont pas accès à certaines documentations et il est souvent nécessaire de recourir à la rétro-ingénierie. Or, c’est un long processus qui limite de fait le nombre de matériels compatibles. Dès lors, il est courant pour les adeptes du logiciel libre de devoir se contenter de composants anciens. Quand bien même cela limite les performances, les fonctionnalités ou encore l’efficacité énergétique, comme le soulignait Phoronix en fin d’année dernière.

Le matériel ouvert ne résout pas le problème

La solution ne résiderait-elle alors pas dans le matériel ouvert ? Ces initiatives sont relativement nombreuses et on peut en trouver une liste sur la version anglaise de Wikipedia. Le matériel ouvert se distingue par des caractéristiques totalement libres, dans le sens où tout le monde peut avoir accès à la documentation et où tous les composants sont sous licence libre, dont TAPR et HDPL. Toute personne est libre de faire ce qu’elle veut de ce matériel.

Ces matériels ont rarement la faveur des industriels cependant et ne sont pas si répandus. Parfois, un projet attire cependant beaucoup l’attention, comme ce fut le cas avec les produits Arduino ou, plus récemment, l’architecture RISC-V. Dans le cas de GNU Boot cependant, rien n’est simple, car il s’agit de donner accès à du code libre sur des ordinateurs déjà complets, notamment portables.