Windows 8 : le Secure Boot gênera-t-il le monde Linux ?

La politique de certification mise en place par Microsoft autour du futur Windows 8 pourrait selon certains acteurs du monde du libre compromettre les chances d'utiliser un système d'exploitation tiers sur les machines concernées, dans la mesure où elle requiert l'activation de Secure Boot, une fonction de sécurité gérée au niveau de l'UEFI. L'éditeur assure que son choix n'aura aucune conséquence pour l'utilisateur final, mais ne convainc pas ses détracteurs.

La sortie d'un nouveau Windows s'accompagne toujours d'un programme de certification dans le cadre duquel es partenaires OEM de Microsoft ont la possibilité d'apposer sur leurs machines un joli macaron de type « certifié pour Windows X » dès lors que ces dernières répondent à certain nombre d'exigences techniques.

L'un des niveaux du programme associé au futur Windows 8 devrait prévoir la présence de l'UEFI (Unified Extensible Firmware Interface, successeur du vénérable BIOS), ainsi que l'activation au niveau de cette dernière de la fonction Secure Boot. Gérée directement au niveau firmware, elle a pour objet de vérifier l'intégrité de la chaîne de démarrage de la machine et de bloquer le lancement du système si un élément étranger est repéré. Ce faisant, la machine est théoriquement protégée des logiciels malveillants de type rootkits, capables de se charger avant l'OS.

Pour Matthew Garrett, développeur chez Red Hat, le fait d'activer systématiquement le Secure Boot pourrait compromettre les chances d'utiliser sereinement un système alternatif aux côtés de Windows 8. Dans un billet daté du 20 septembre, il rappelle en effet que Secure Boot repose sur un système de signature numérique qui impose que le fabricant de l'ordinateur ou de la carte mère intègre à son produit la « clé » lui permettant d'identifier un système sain. Tout nouvel élément logiciel intervenant au niveau du démarrage de la machine doit donc disposer de sa propre signature dans le cas où Secure Boot est activé.


Le problème, selon lui, réside dans le fait que les principales distributions Linux ne disposent pas aujourd'hui de ladite signature, et toutes ne sont pas en mesure d'entrer en contact avec tous les OEM pour se faire intégrer au programme. Il est en outre difficile de faire signer numériquement des logiciels distribués sous licence GPL, puisque leur code source doit rester accessible, empêchant toute confidentialité. En l'état actuel des choses, Garrett estime donc qu'une machine certifiée pour Windows 8 - sur laquelle Secure Boot est donc activé - risque d'avoir du mal à faire fonctionner Linux aux côtés ou à la place de Windows 8.

La polémique naissante n'a pas laissé Microsoft indifférent. Deux jours plus tard, l'éditeur s'est fendu d'un billet explicitant la mécanique du Secure Boot. Il y rappelle que ce dispositif est géré directement au niveau de l'UEFI et non par Windows directement. Il souligne également que les OEM auront tout loisir d'adapter leurs firmwares pour que soient gérés d'autres gestionnaires de démarrage que celui de Windows. Enfin, il fait valoir que l'utilisateur garde le contrôle sur sa machine, puisque le Secure Boot doit normalement pouvoir être désactivé au niveau de l'UEFI. Dans ce cas, il n'y a effectivement plus d'obstacle à la modification de la séquence de démarrage... pour peu que l'option ait bien été intégrée par le fabricant.

Dans un second billet, publié vendredi, Garrett émet quelques doutes. Plusieurs OEM auraient ainsi déjà informé Red Hat qu'ils n'implémenteraient pas cette option, faisant du Secure Boot une composante inaliénable de leurs produits. Et si Microsoft, avec 90% des parts de marché, n'aura aucun mal à faire accepter ses clés à l'ensemble des acteurs du marché, les choses pourraient d'après lui se révéler bien plus complexes pour des éditeurs de moins grande envergure.

« Rien n'indique que Microsoft empêchera les vendeurs de fournir l'option permettant de désactiver cette fonctionnalité et de lancer un code non signé. Néanmoins, l'expérience nous a montré que beaucoup de vendeurs et OEM ne cherchent qu'à fournir le minimum des fonctionnalités requises pour leur marché », écrit Garrett.