L'impact UEFI & SecureBoot, quelle est sa gravité?

Je prévois d'acheter un nouvel ordinateur portable dans les prochains jours, et je suis assez impressionné par les nouveaux Ultrabooks cool. En tant qu'utilisateur de longue date de GNU / Linux, je vais bien sûr y installer une distribution de mon choix.

Il y a de fortes chances que je doive acheter un ordinateur avec Windows 8 préinstallé; et il est probable qu'il exécutera UEFI et aura un "démarrage sécurisé", sur lequel les noyaux non signés ne démarreront pas.

UEFI est probablement bon, le BIOS peut avoir besoin de se retirer. Je suppose que la chose velue est Secure Boot .

Pour autant que je peux comprendre, certains de confiance des certificats seront intégrés dans le firmware et ainsi dans le noyau etc . Si le certificat du noyau peut être retracé à l'un des micrologiciels , le noyau démarrera, sinon UEFI me dira et refusera de démarrer. Ce processus empêchera le démarrage d'un logiciel non certifié. Cela peut avoir des avantages bien que je ne puisse pas les voir.

Je me demande comment un noyau open source peut obtenir une de ces clés tout en étant libre . J'ai lu un fil sur la liste de diffusion Linux où un employé de Red Hat demande à Linus Torvalds de tirer un ensemble de modifications qui implémente la fonction pour analyser les binaires PE et prendre un ensemble complexe d'actions pour permettre au noyau de démarrer en mode Secure Boot (pour autant que je puisse comprendre) ). Ils veulent le faire parce que Microsoft ne signe que les binaires PE. M. Torvalds a gentiment rejeté cet ensemble de modifications, déclarant que le noyau implémente déjà la norme, qui n'est pas PE . RedHat essaie de pousser ce code vers le noyau afin de ne pas avoir à le bifurquer un jour.

Vous voyez, c'est une chose compliquée. Permettez-moi de poser mes questions:

• Quels avantages vais-je gagner avec UEFI et Secure Boot, en tant qu'utilisateur domestique?
• Comment se fait cette signature ?
• Qui peut obtenir des signatures / certificats? Est-ce payé? Peut-il être public? (Il devrait être disponible dans le code source de Linux, n'est-ce pas?)
• Microsoft est-il la seule autorité à fournir des signatures? Ne devrait-il pas y avoir une fondation indépendante pour les fournir?

• De quelle façon cet impact open source et noyaux libres, les développeurs du noyau amateur / universitaire , etc. . par exemple, ce démarrage ( un code de secteur de démarrage très basique ):

  hang:
     jmp hang
  times 510-($-$$) db 0
  db 0x55
  db 0xAA
  

Une nouvelle sur ce site Web est à l'origine de cette question. Un groupe d'utilisateurs espagnol de Linux appelé Hispalinux a déposé une plainte contre Microsoft à ce sujet auprès de la Commission Europan.

Dois-je m'inquiéter? Je refuse de n'utiliser ni logiciel propriétaire ni logiciel signé par des sociétés de confiance . Je l'ai fait jusqu'à présent et je veux continuer ainsi. Merci d'avance.

Ce processus empêchera le démarrage d'un logiciel non certifié. Cela peut avoir des avantages bien que je ne puisse pas les voir.

Vous disposez d'un nouveau mécanisme de sécurité pour contrôler ce qui peut et ce qui ne peut pas démarrer à partir de votre matériel. Une fonction de sécurité. Vous n'avez pas l'impression d'en avoir besoin jusqu'à ce qu'il soit trop tard. Mais je m'égare.

J'ai lu un fil sur la liste de diffusion Linux où un employé de Red Hat demande à Linus Torvalds de tirer un ensemble de modifications qui implémente la fonction pour analyser les binaires PE et prendre un ensemble complexe d'actions pour permettre au noyau de démarrer en mode Secure Boot (pour autant que je puisse comprendre) ).

Les pilotes, comme votre micrologiciel GPU, doivent être signés en ligne avec Secure Boot, sinon il peut s'agir d'un autre rootkit. Le statu quo est que ces pilotes sont signés au format PE. Le noyau peut démarrer sans ceux-ci de toute façon, mais le matériel ne fonctionnera pas. L'analyse du format PE dans le noyau est juste un choix techniquement plus simple pour cela que de demander à chaque fournisseur de matériel de signer leurs objets blob pour chaque distribution, ou de configurer un cadre d'espace utilisateur pour ce faire. Linus décide de ne pas sucer la bite de Microsoft. Ce n'est pas un argument technique.

Quels avantages vais-je gagner avec UEFI et Secure Boot, en tant qu'utilisateur domestique?

La fonctionnalité la plus visible est le démarrage rapide UEFI. J'ai mis la main sur plusieurs bureaux avec logo Windows 8 et ils démarrent si rapidement que je manque souvent de faire apparaître le menu de démarrage. Intel et les OEM ont une certaine ingénierie à ce sujet.

Si vous êtes le type d'utilisateurs Linux qui détestent les ballonnements et la duplication de code avec passion, vous pouvez également gérer le multiboot au niveau du micrologiciel et vous débarrasser complètement des chargeurs de démarrage. UEFI fournit un gestionnaire de démarrage avec lequel vous pouvez démarrer directement dans le noyau ou choisir de démarrer un autre système d'exploitation avec le menu du micrologiciel. Bien qu'il puisse avoir besoin de quelques retouches.

En outre, des graphismes plus sophistiqués pendant le démarrage et dans le menu du firmware. Meilleure sécurité au démarrage (Secure Boot). Les autres fonctionnalités (netboot IPv4 / 6, périphériques de démarrage 2 To +, etc.) sont principalement destinées aux utilisateurs d'entreprise.

Quoi qu'il en soit, comme l'a dit Linus , le BIOS / UEFI est censé "simplement charger le système d'exploitation et sortir de l'enfer", et UEFI semble certainement le cas pour les utilisateurs à domicile avec un démarrage rapide. Il fait certainement plus de choses que le BIOS sous le capot, mais si nous parlons d'utilisateurs à domicile, ils ne s'en soucieront pas.

Comment se fait cette signature?

Théoriquement, un binaire est chiffré avec une clé privée pour produire une signature. Ensuite, la signature peut être vérifiée avec la clé publique pour prouver que le binaire est signé par le propriétaire de la clé privée, puis le binaire vérifié. Voir plus sur Wikipedia .

Techniquement, seul le hachage du binaire est signé et la signature est intégrée au binaire au format PE et au formatage supplémentaire.

Sur le plan de la procédure, la clé publique est stockée dans votre micrologiciel par votre OEM et provient de Microsoft. Vous avez deux choix:

1. Générez votre propre paire de clés et gérez-les en toute sécurité, installez votre propre clé publique sur le firmware et signez le binaire avec votre propre clé privée ( sbsign d'Ubuntu ou pesign de Fedora), ou
2. Envoyez votre binaire à Microsoft et laissez-le le signer.

Qui peut obtenir des signatures / certificats? Est-ce payé? Peut-il être public? (Il devrait être disponible dans le code source de Linux, n'est-ce pas?)

Comme les signatures / certificats sont intégrés dans les fichiers binaires, tous les utilisateurs sont censés les obtenir. Tout le monde peut créer sa propre autorité de certification et générer un certificat pour lui-même. Mais si vous souhaitez que Microsoft génère un certificat pour vous, vous devez passer par Verisign pour vérifier votre identité. Le processus coûte 99 $. La clé publique est dans le firmware. La clé privée est dans le coffre-fort de Microsoft. Le certificat est dans le binaire signé. Aucun code source impliqué.

Microsoft est-il la seule autorité à fournir des signatures? Ne devrait-il pas y avoir une fondation indépendante pour les fournir?

Le côté technique est plutôt trivial, comparé au processus de gestion de PKI, de vérification d'identité, de coordination avec tous les OEM et fournisseurs de matériel connus. Cela coûte cher. Il se trouve que Microsoft possède une infrastructure (WHQL) et une expérience dans ce domaine depuis des années. Ils proposent donc de signer des binaires. N'importe quelle fondation indépendante peut proposer la même chose, mais aucune ne l'a fait jusqu'à présent.

À partir d'une session UEFI à l'IDF 2013, je vois que Canonical a également commencé à mettre sa propre clé dans un firmware de tablette. Canonical peut donc signer ses propres fichiers binaires sans passer par Microsoft. Mais il est peu probable qu'ils signent des binaires pour vous car ils ne savent pas qui vous êtes.

Comment cela affectera-t-il les noyaux open source et gratuits, les développeurs amateurs / universitaires, etc.

Votre noyau personnalisé ne démarre pas sous Secure Boot, car il n'est pas signé. Vous pouvez cependant le désactiver.

Le modèle de confiance de Secure Boot verrouille certains aspects du noyau. Comme vous ne pouvez pas détruire votre noyau en écrivant dans / dev / kmem même si vous êtes root maintenant. Vous ne pouvez pas hiberner sur le disque (en cours de travail en amont) car il n'y a aucun moyen de s'assurer que l'image du noyau n'est pas modifiée en un kit de démarrage lors de la reprise. Vous ne pouvez pas vider le noyau lorsque votre noyau panique, car le mécanisme de kdump (kexec) peut être utilisé pour démarrer un bootkit (également en amont). Celles-ci sont controversées et ne sont pas acceptées par Linus dans le noyau principal, mais certaines distributions (Fedora, RHEL, Ubuntu, openSUSE, SUSE) sont livrées avec leurs propres correctifs de démarrage sécurisé de toute façon.

Personnellement, la signature du module requise pour la construction d'un noyau Secure Boot coûte 10 minutes tandis que la compilation réelle ne prend que 5 minutes. Si je désactive la signature de module et active ccache, la construction du noyau ne prend qu'une minute.

UEFI est un chemin de démarrage complètement différent du BIOS. Tout le code de démarrage du BIOS ne sera pas appelé par le firmware UEFI.

Un groupe d'utilisateurs espagnol de Linux appelé Hispalinux a déposé une plainte contre Microsoft à ce sujet auprès de la Commission Europan.

Comme indiqué ci-dessus, personne, sauf Microsoft, n'est intervenu pour faire le service public. Il n'y a actuellement aucune preuve de l'intention de Microsoft de faire du mal avec cela, mais rien n'empêche également Microsoft d'abuser de son monopole de fait et de faire un voyage en puissance. Ainsi, alors que les groupes d'utilisateurs FSF et Linux peuvent ne pas sembler assez pragmatiques et ne se sont pas réellement assis pour résoudre les problèmes de manière constructive, il est tout à fait nécessaire que les gens mettent la pression sur Microsoft et l'avertissent des répercussions.

Dois-je m'inquiéter? Je refuse de n'utiliser ni logiciel propriétaire ni logiciel signé par des sociétés de confiance. Je l'ai fait jusqu'à présent et je veux continuer ainsi.

Raisons d'adopter le démarrage sécurisé:

• Il élimine un véritable vecteur d'attaque de sécurité.
• Il s'agit d'un mécanisme technique pour donner à l'utilisateur plus de liberté pour contrôler son matériel.
• Les utilisateurs de Linux doivent comprendre le mécanisme de démarrage sécurisé et agir de manière proactive avant que Microsoft n'aille trop loin dans le monopole de la politique de démarrage sécurisé .

Je viens de passer par cela avec un récent achat d'ordinateur portable fourni avec Windows 8 et un démarrage sécurisé UEFI. Après beaucoup de temps et de recherches, voici ce que je peux répondre:

• Cela ne vous semble pas appartenir à la catégorie des «utilisateurs à domicile».

Les avantages de l'UEFI que l'utilisateur moyen remarquera est que la première chose qu'ils voient sur leur écran sera l'affichage du chargeur de démarrage UEFI de marque Microsoft / Vendor. Aucune de ces choses effrayantes comme "Appuyez sur Suppr pour l'installation, F11 pour sélectionner le périphérique de démarrage", etc.

Il passera ensuite bien dans l'écran d'attente du noyau / chargeur de démarrage Microsoft. Cela présente une «puissance pour inciter» l'expérience sur le thème de Microsoft. Si c'est un avantage réel est dans l'œil du spectateur, je suppose. J'étais assez contente de ne pas avoir les informations normales que je m'attendais à voir au démarrage. Par exemple, bonne chance si votre fournisseur n'utilise pas de clé standard pour entrer dans la configuration de base UEFI / Bios.

Oh, oui, et la théorie est que cela arrêtera les virus du secteur de démarrage, ou au moins obligera les créateurs à créer / voler l'ID de quelqu'un et à payer 99 $ à Verisign (la route RedHat Fedora. Google it.)

• Pour plus d'informations sur la façon dont la signature est effectuée, consultez ceci: http://al.robotfuzz.com/playing-with-uefi-secure-boot-part-2-basic-authenticode-signing-with-ms-tools /

• Qui ? Seul Microsoft?

Ah, et il y a le hic. Tout le monde peut signer le code avec n'importe quelle clé. Le problème est que la machine exécutera uniquement le code signé par une clé d'autorité de confiance. La moitié publique de la clé est installée dans le noyau UEFI du système en usine et est utilisée pour vérifier la signature des programmes UEFI (code de démarrage) signés avec la clé privée.

Devinez qui est la clé publique installée en usine? Devinez qui exige que le démarrage sécurisé soit activé par défaut?

Chaque fabricant de système y mettra évidemment la clé de Microsoft. Ils pourraient également mettre la clé de Canonical (Ubuntu), la clé de Red Hat, la clé d'Apple, etc.

• Votre code de secteur de démarrage? Non, c'est un report du BIOS. Si vous souhaitez expérimenter avec l'écriture de code UEFI, consultez http://x86asm.net/articles/uefi-programming-first-steps/

Et quelle est la solution pour un utilisateur d'ordinateur rebelle comme vous?

• J'espère que votre fournisseur de système vous permet d'accéder à la configuration de démarrage du système

• J'espère qu'ils vous permettront de désactiver le démarrage sécurisé. Le code de démarrage de Windows fonctionnera toujours sans démarrage sécurisé.

• Si vous êtes vraiment chanceux, le fournisseur du système vous permettra de mettre vos propres clés d'autorité de certification et vous pourrez signer vos propres trucs. Cela n'est vraiment nécessaire que si vous souhaitez jouer avec Secure Boot.

Mon ordinateur portable MSI me permet de faire tout ce qui précède.

J'aimerais voir un monde où n'importe qui peut acheter une copie gratuite d'une distribution Linux et remplacer son système d'exploitation. C'est ce que nous avions avant Secure Boot. Nous avions également beaucoup de virus du secteur de démarrage. Devoir désactiver le démarrage sécurisé dans la configuration de votre système est probablement un obstacle assez petit pour vérifier que vous avez le cerveau nécessaire pour installer un système d'exploitation, ou connaissez quelqu'un qui le fait.

Ne pas avoir la possibilité de l'éteindre est la mauvaise chose, et cela dépend du fabricant. Ne blâmez pas Microsoft, à moins qu'ils ne `` convainquent '' le fabricant d'empêcher la désactivation du démarrage sécurisé.