Depuis des mois maintenant, plusieurs développeurs ou sociétés travaillent sur des méthodes pour permettre à Linux de démarrer sur un PC équipé du Secure Boot. Plusieurs techniques existent, mais lorsqu’un développeur pose la question de l’intégration des clés dans le noyau, Linus Torvalds se fâche pour de bon.
Un même problème, plusieurs solutions
Le sujet du Secure Boot dans la communauté open source est délicat. Cette fonctionnalité, présente dans les spécifications de l’UEFI, permet à un système d’exploitation de contrôler l’intégrité de la chaine des éléments impliqués dans le boot. Cela demande notamment le concours des constructeurs de GPU, et puisque Microsoft est arrivé le premier, ce sont surtout ses propres clés de sécurité qui importent.
Plusieurs solutions ont été envisagées, notamment celle de Matthew Garrett, développeur chez Red Hat, et celle mise en avant par la Linux Foundation. Les deux sont différentes et il se pourrait au final qu’elles soient rapprochées pour faire front commun. Mais un autre développeur de chez Red Hat, David Howells, a carrément posé la question de l’intégration éventuelle des clés de sécurité Microsoft au sein du noyau. Le bénéfice serait simple : permettre à une distribution Linux de démarrer directement sur une machine possédant le Secure Boot.
Linus Torvalds explose
La question a soulevé l’ire de Linus Torvalds, père du noyau Linux. Dans une réponse relativement grossière, il laisse éclater sa colère : « Si Red Hat veut pratiquer la gorge profonde sur Microsoft, c’est votre problème. Cela n’a absolument rien à voir avec le kernel que je maintiens. Il est facile pour vous les gars d’avoir un processus signature qui parse le binaire PE, vérifie les signatures et signe les clés résultantes avec votre propre clé. […] Pourquoi serais-je concerné ? Pourquoi le kernel devrait-il s'occuper d’une stupidité telle que « nous ne signons que les binaires PE » ? Nous supportons le X.509 qui est le standard pour les signatures ». Et d’indiquer que tout doit être fait en espace utilisateur et qu’aucune excuse n’est valable pour l’inclusion dans le kernel.
Au centre de la colère de Linus Torvalds se trouve en fait la manière dont Microsoft a conçu sa solution. Selon David Howells, la solution serait d’intégrer les clés de sécurité dans un certificat X.509, puis de placer ce dernier dans un EFI PE (Extensible Firmware Interface Portable Executable) pour le faire signer par Microsoft, ce dernier ne signant que des binaires. Mais les binaires sont justement à l’opposé de la philosophie open source : les fichiers sont déjà compilés et les développeurs n’en ont pas la maîtrise, à la manière d’un corps étranger. Les binaires se retrouvent le plus souvent dans certains pilotes, notamment graphiques, mais l’inclusion dans le noyau est une autre paire de manches.
La question de l'universalité
Matthew Garrett a toutefois participé lui aussi à la conversation. Il a ainsi tenu à rappeler que les constructeurs de composants souhaitent des clés qui ont été signées par un tiers de confiance. Actuellement, seul Microsoft répond à cette appellation, posant le délicat problème des entités responsables des signatures. Torvalds répondra que toute cette problématique n’intéresse pas grand-monde, et surtout pas lui.
Mais le véritable souci pour Garrett est l’universalité. Il explique ainsi que Red Hat se doit de trouver une solution et que celle-ci sera très certainement l’utilisation des clés de Microsoft car elles sont déjà employées par NVIDIA et AMD. Il se demande donc si toutes les distributions vont utiliser un modèle commun ou si chaque kernel aura sa propre solution.
Une question dont Microsoft doit bien peu se soucier.
Commentaires (231)
#1
Quelle merde ce secure boot
" />
#2
Si Red Hat veut pratiquer la gorge profonde sur Microsoft,
" />
Ca peut faire un film sympa
#3
Et bien, ça l’air d’être un beau bordel cette protection.
#4
Suck my boot !
" />
#5
Et read heat c’est pas un acteur de confiance pour signer des clé?
En tout cas si on sort des dogmes et qu’on est pragmatique la solution qui consiste à utiliser les clés de MS ne pose aucun problème pratique.
Linux paie sa fragmentation, faut pas en vouloir à MS d’avoir mit au point une technologie pour sécuriser les machine non plus.
#6
Le problème c’est que Linux est un système ouvert, dont les sources sont publics.
" />
Si les clefs de Microsoft sont incluses dans les sources de Linux, tout auteur de virus pourra en faire autant…
Sinon, cette histoire me rappelle le coup du deCSS…
#7
Toujours aussi fin ce garçon…
" />
Il a vraiment un problème de quéquette sexisme dans ses déclarations.
#8
#9
J’ai pas très bien compris… Linus Torvalds est en colère sur le fait que MS oblige le Secure Boot ? Ou il est en colère sur le fait qu’on arrête pas de lui demander ce qu’il en pense et comment il compte adapter le kernel linux à cette problématique ?
#10
#11
#12
#13
#14
Je me demande bien pourquoi Red Hat s’interrese autant au secure boot. Les clients Red Hat qui font du dual boot avec Windows doivent pas être nombreux !
#15
#16
Il a raison. Pas de binaires dans le noyau…
Et je le trouve très mesuré pour le coup, c’est rare chez lui.
#17
#18
#19
Déjà que l’UEFI c’est codé avec la bite. Inutilement compliqué et buggué.
Rien que le fait que ça m’oblige a avoir une partition FAT me prouve que c’est de la daube.
M’en branle de leur Secure boot moisi, que MS aille se faire voir.
:fuck: <- il me manque ce smiley :p
#20
#21
#22
#23
Une question dont Microsoft doit bien peu se soucier.
Bien au contraire : ca doit leur fournir l’occasion de rire. Pour paraphraser Tolor, ils sont heureux de proposer une solution qui n’est compatible qu’avec leur vision monopolistique de l’industrie.
Fin bon, ca a permis a Tovalds de s’enerver, il a besoin de lacher un peu de pression de temps en temps
#24
#25
Au centre de la colère de Linus Torvalds se trouve en fait la manière dont Microsoft a conçu sa solution. Selon David Howells, la solution serait d’intégrer les clés de sécurité dans un certificat X.509, puis de placer ce dernier dans un EFI PE (Extensible Firmware Interface Portable Executable) pour le faire signer par Microsoft, ce dernier ne signant que des binaires. Mais les binaires sont justement à l’opposé de la philosophie open source : les fichiers sont déjà compilés et les développeurs n’en ont pas la maîtrise, à la manière d’un corps étranger. Les binaires se retrouvent le plus souvent dans certains pilotes, notamment graphiques, mais l’inclusion dans le noyau est une autre paire de manches.
Je n’ai pas nécessairement compris cela de cette facon.
Microsoft ne signe que des binaires PE. PE est un format 100% Microsoft. La solution proposée par le développeur Red Hat est donc d’embarquer dans un binaire PE le module Linux à signer par Microsoft. Cela implique donc de développer coté Linux et kernel la brique à même de parser le binaire PE pour en extraire le module Linux et l’utiliser.
Et la Linus n’est pas d’accord…
#26
C’est un problème insoluble dans la mesure où les 2 entités ont une vue complètement différente de l’informatique domestique.
Pour Microsoft (comme pour Apple,..), c’est l’industrie qui est maître de ta machine et doit essayer de la protéger même contre toi-même. Et le Secure Boot a été conçu dans cette optique.
Pour la Fondation Linux, c’est l’administrateur de la machine qui a tous les pouvoirs et donc toute la responsabilité.
Ces 2 vues sont complètement incompatibles. Et comme la majorité des gens n’aiment pas les responsabilités, la 2ieme finira rapidement par disparaître.
#27
#28
#29
il est en colère parce qu’un développeur propose une solution qui n’est pas compatible avec sa vision personnelle
Il est surtout en colère parce qu’on lui propose une mauvaise solution à un problème, même en laissant en dehors la discussion sur le problème lui même.
#30
#31
#32
#33
#34
#35
#36
#37
#38
#39
#40
#41
#42
#43
#44
#45
#46
#47
#48
#49
#50
Le fait que ce soit imposé par MS dans les specs des machines livrées avec Windows 8?
Je pense que par source, il voulait dire source fiable ;)
#51
#52
#53
#54
#55
#56
#57
Encore un truc qui sert à rien.(le secure boot)
" />
Ils en ont pas marre chez MS de ralentir l’évolution de l’informatique ?
#58
#59
#60
#61
#62
#63
#64
#65
#66
#67
#68
#69
#70
#71
#72
#73
#74
#75
#76
#77
#78
#79
#80
#81
#82
#83
#84
#85
#86
#87
#88
#89
#90
#91
#92
Et tu considères pareil quand tu as les specs d’une machine? Tu ne crois jamais les specs d’un constructeur, c’est pour toi pas une source fiable ?
Heeuu.. on s’est mal compris, par cource fiable, j’entends un vrai lien vers une vrai doc.
#93
#94
#95
Comme disait Thomas J. en reprenant les propos de son copain Benjamin F. :
Si tu es prêt à sacrifier un peu de liberté pour te sentir en sécurité, tu ne mérites ni l’une ni l’autre.
#96
Je peut deja vous donnez le motif de pourquoi dans 4 ans la desactivation sera impossible .
Bah oui , comme on peut mettre a jours les UEFI depuis windows . Il sera dit que l’on pourrais en flashant le UEFI desactivé le Secureboot . Donc la solution logic et que le secureboot ne sois pas desactivable par UEFI .
Accepter aujourd’hui seciureboot avec comme solution de contournement de le désactiver dans le UEFI et une erreur .
ET personnelement je pense pas que les gens qui install des linux a la chaine seront content de booter les serveurs par carte RSA,ILO,IDRAC pour aller dans le bios et perdre 30 minute par serveur et ceci malgres le processus industrilalisation qu’il ont mit en place pour l’installation automatique par PXE , forman , spacewalk, ou autres par ex .
#97
#98
#99
#100
Je suis pas un expert mais j’ai pas tout compris a cette histoire…. Pourquoi red hat ne demande pas une clé de sécurité à verisign par exemple ? Dans mes souvenirs c’était ce qui devait être fait.
#101
#102
#103
#104
#105
#106
#107
#108
#109
Je croyais que c’était Ubuntu qui faisait son truc dans son coin et que RedHat via sa fedora utilsait la solution de la fondation.
" />
Me trompe-je ?
#110
“Secure Boot” est une très bonne idée qui est très mal conçue. Tous les ingrédients d’un bon conflit entre les “pour” et les “contre”.
Avoir une signature de la chaine de boot, fournie par le bios/uefi, c’est un bon moyen pour un OS de savoir ce qui s’est passé avant que l’OS prenne la main.
Donner le pouvoir au bios/uefi d’interdire le boot à moins de connaitre une clé secrete qui n’est pas donnée au propriétaire du PC, c’est du bridage pur et simple.
#111
parce que c’est évident, si techniquement c’est possible, c’est forcément que ce sera fait. C’est sûr à 100% même si tu n’as aucune source qui pourrait indiquer qu’ils ont l’intention de le faire…
L’histoire, c’est une source pas trop mal je trouve…
#112
#113
Question bête quel est la position de BSD vis à vis de l’uefi ?
#114
#115
#116
#117
Si Secure boot est désactivable actuellement sur les PC et pas sur les Tablettes win, c’est surtout pour une chose : pas d’historique a supporter coté tablette alors que ceux qui veulent un pc pour y mettre win7 auraient bien gueulé si y avait pas moyen de démarrer autre chose que win8.
Par contre, à la fin du support de win 7, Secure boot désactivable sera devenu inutile et considéré dangereux par MS (vu que tous leurs OS supportés seront compatibles). Et là, ils pourront négocier la suppression de cette option.
(C’est vrai que pas grand chose ne le confirme actuellement, mais les scénarii de ce type ne sont pas nouveaux venant de MS…)
#118
#119
#120
#121
#122
#123
#124
#125
#126
#127
#128
#129
#130
#131
#132
#133
Debian ne prend en pas charge ni le GPT (utilisé par l’UEFI), ni le SecureBoot. Autant le second point est moins problématique parce que Windows ne force pas l’utilisation du SecureBoot pour s’installer ainsi que le fiat qu’il soit désactivable dans le BIOS/UEFI, autant le second est un problème si tu as une carte mère UEFI only.
#134
#135
#136
#137
#138
#139
#140
#141
[TROLL]
De toute façon, on se prend le choux pour rien.
Avec l’avènement du “Cloud”, des DRM, des forfaits et des offres Internet segmenté (ça va forcément arrivé, j’en ai la certitude)
UEFI et Secure Boot seront le dernier de nos soucis dans une station de connexion au réseau. (Ou Minitel 2.0)
[/TROLL]
#142
#143
#144
#145
#146
#147
#148
#149
#150
#151
#152
#153
#154
#155
Mais LOL !!
" /> 
" />
" />
" />
" />
y’a que moi qui fait un bond ?!!
Ah parce que un anti-virus peut te protéger avant le boot de l’OS ?
[quote:4477732:TexMex]
S’il est lancé en premier : oui.
On est pas obligé d’avoir un OS pour avoir un antivirus.
y’a 15ans on avait des anti-virus 100% autonome (en bootsecteur)
suit un blabla incompréhensible !! jVachez/Illuminati
[quote:4477732:TexMex]
mais pitié, étudie un peu notre domaine d’expertise, apprends le fonctionnement d’un ordinateur, code un programme sans utiliser d’API, paye ton antivirus en ASM pur et surtout , surtout arrête de raconter des connerie !!
#156
#157
#158
#159
#160
#161
#162
Perso je ne le sens pas en colère.
La réaction intégrale :
Guys, this is not a dick-sucking contest.
If you want to parse PE binaries, go right ahead.
If Red Hat wants to deep-throat Microsoft, that’s your issue. That
has nothing what-so-ever to do with the kernel I maintain. It’s
trivial for you guys to have a signing machine that parses the PE
binary, verifies the signatures, and signs the resulting keys with
your own key. You already wrote the code, for chissake, it’s in that
f*cking pull request.
Why should I care? Why should the kernel care about some idiotic “we
only sign PE binaries” stupidity? We support X.509, which is the
standard for signing.
Do this in user land on a trusted machine. There is zero excuse for
doing it in the kernel.
#163
#164
#165
#166
#167
#168
#169
#170
#171
#172
#173
#174
#175
#176
#177
Le Secure Boot n’est-il pas un moyen supplémentaire d’augmenter la sécurité de certaines machines accessible physiquement dans des secteurs critiques .
Cette technologie pour le grand public n’est pas forcément bien perçue mais elle est loin d’être inutile.
Si cette technologie a été mise en place , je pense que c’est aussi parce qu’il y avait une demande ,tout simplement afin de réduire considérablement un type d’attaque qui doit représenter un pourcentage assez faible mais qui peut faire pas mal de dégâts .
Le plus important c’est qu’il n’y a pas de limitation et que tout le monde peut en profiter quelque soit l’OS .
#178
#179
#180
#181
#182
#183
#184
#185
#186
#187
#188
#189
#190
#191
D’ailleurs au passage (toujours :) ), apparemment Microsoft aurai signé un bootloader pour Linux. Donc inutile de signer systématiquement les nouveaux noyaux.
Dans la série, je bloque tout le monde et j’impose mon OS, ya comme un bug là …
#192
#193
#194
#195
#196
#197
#198
#199
Pas le choix, les clés doivent être publiées car tous le monde doit pouvoir changer d’OS, et mettre un OS open source.
#200
#201
#202
#203
moi tout ce que je vois c’est que du materiel (bien physique mobilier) que je vais acheter sera en fait n appareil en licence locative indéfinie puisque je ne disposerait pas de tous les choix/droits possibles pour l’utiliser d’une façon autre que celle prevue par le concessionnaire (qui est con mais ne cesse/cede rien du tout, du reste) et son partenaire commercial
merci si j’veux ca j’achete du apple !
quand j’achete des bouts de pc pour monter mon pc, ou quand j’achete mon pc, ca m’appartient c’est à moi…
j’prefere meme pas faire d’analogie foireuse avec la voiture sinon j’vais etre grossier
#204
#205
#206
#207
#208
#209
#210
#211
#212
tu peut quand meme toujours pas installer sur le deuxieme disque .
En meme temps comme ca microsoft sont sur de pas effacer de donnée :)
Pas cable de memorise le disque choisis pour l’install
Obliger de debrancher tous mes disque pour faire l’install de windows8 :(
#213
#214
Vous êtes sûr d’encore posséder un Personal Computer, ne serait-ce pas, plutôt, un Profiler Computer ou un Bullet Computer
" />
" />
Celui qui prend son PC pour une console, qu’il réfléchisse à deux fois avant de se mettre un bracelet au pied (à moins de ne pas avoir qu’un seul PC)
#215
#216
Je voudrais corriger une grosse bêtise que j’ai lu plusieurs fois dans les commentaires : le Secure Boot n’empêche pas de booter sur un autre disque !!!
Si vous voulez utiliser un Live CD, il n’y a rien à faire ! Juste dire à l’UEFI de booter sur le CD !
Ce n’est que si vous voulez faire un branchement (multi-boot) que le problème se pose. Dans ce cas, il faut que l’intégralité de la chaîne de démarrage, de l’UEFI à CHAQUE système d’exploitation soit vérifiée. D’où le besoin d’un multiboot et de chaque noyau signés avec la même clef !
Ou autre méthode, signer jusqu’au multiboot (genre grub) et ensuite c’est lui qui vérifie entre lui et chaque OS (ce qui permet ds clefs différentes pour chaque OS).
Avant de parler de Secure Boot et d’UEFI, apprenez à l’utiliser tout comme je le fais depuis 3 mois !
#217
#218
#219
#220
au final, quels sont critères discriminants à prendre en compte si l’on cherche une nouvelle config bien prise en charge ?
#221
#222
#223
#224