Ça fait au moins un an que Matthew Garret (mjg59) travaille sur le support de Secure Boot, non pas pour le plaisir de verrouiller les machines mais parce que ça sera une technologie incontournable vu que Microsoft compte l'imposer pour être certifié Windows 8.
On a toujours le choix. On pourrait aussi bien dire qu'essayer de faire du Logiciel Libre est inutile car de toutes façons Windows est vendu avec toutes les machines. Red Hat, vu sa position, avait tout à fait le pouvoir pour bien faire pencher la balance dans le sens du libre (je ne dis pas qu'ils y seraient arrivés tout seul, mais ils ont un poids certain). Je trouve très dommageable qu'ils aient accepté ce compromis foireux.
certains constructeurs peuvent rendre non optionnel cette fonctionnalité (Microsoft est revenu en arrière et n'impose plus que ça soit non désactivable)
On sait très bien que les « peuvent » dans ce cadre là sont très hypothétiques.
certains utilisateurs peuvent vouloir utiliser fonctionnalité et c'est leur droit.
Ils pouvaient déjà avant, c'est exactement le rôle de TPM. Ici, on parle de la rendre active par défaut partout, avec la clé de MS, ce qui est très différent. Cette remarque n'apporte donc aucune justification.
sur ARM, Microsoft impose que Secure Boot ne soit pas désactivable et aucune solution ne sera proposé pour le supporter.
Génial.
En résumé, la solution de Fedora sera de signer le stage1 de Grub2 (qui change rarement au cours de la vie d'une version contrairement au noyau) et non pas le noyau.
Et ? Au final, pour que Red Hat garde sa certification, il ne faut pas qu'il accepte avec ce bootloader de booter n'importe quel stage 2, et subséquemment n'importe quel noyau. Sinon, ils vont se faire révoquer leur clé. Bref, indirectement, ça revient à signer également le noyau.
C'est une solution qui a été choisie en concertation avec la fondation Linux afin d'être réutilisable par les autres distributions, ce que ne permette pas les autres solutions.
Mais c'est tout aussi pourri, parce que bien sûr Red Hat ne va pas signer n'importe quel stage 2 : seulement ceux qui chargent des noyaux vérifiés. Bref, Red Hat se place en autorité de certification de qui dans le libre aura le droit de booter en mode « sécurisé » !
C'est toujours la même chose dans les mondes fermés : on appâte les premiers en leur donnant du pouvoir sur les suivants. Comme ça, ils craquent plus facilement. Ce qu'a fait Red Hat est vraiment pas classe.
[^] # Re: RH ne supporte pas Secure Boot
Posté par benoar . En réponse au journal Canonical embrasse la technologie Microsoft (bootloader). Évalué à 3.
On a toujours le choix. On pourrait aussi bien dire qu'essayer de faire du Logiciel Libre est inutile car de toutes façons Windows est vendu avec toutes les machines. Red Hat, vu sa position, avait tout à fait le pouvoir pour bien faire pencher la balance dans le sens du libre (je ne dis pas qu'ils y seraient arrivés tout seul, mais ils ont un poids certain). Je trouve très dommageable qu'ils aient accepté ce compromis foireux.
On sait très bien que les « peuvent » dans ce cadre là sont très hypothétiques.
Ils pouvaient déjà avant, c'est exactement le rôle de TPM. Ici, on parle de la rendre active par défaut partout, avec la clé de MS, ce qui est très différent. Cette remarque n'apporte donc aucune justification.
Génial.
Et ? Au final, pour que Red Hat garde sa certification, il ne faut pas qu'il accepte avec ce bootloader de booter n'importe quel stage 2, et subséquemment n'importe quel noyau. Sinon, ils vont se faire révoquer leur clé. Bref, indirectement, ça revient à signer également le noyau.
Mais c'est tout aussi pourri, parce que bien sûr Red Hat ne va pas signer n'importe quel stage 2 : seulement ceux qui chargent des noyaux vérifiés. Bref, Red Hat se place en autorité de certification de qui dans le libre aura le droit de booter en mode « sécurisé » !
C'est toujours la même chose dans les mondes fermés : on appâte les premiers en leur donnant du pouvoir sur les suivants. Comme ça, ils craquent plus facilement. Ce qu'a fait Red Hat est vraiment pas classe.