Lors de l'installation de 16.04 , on m'a demandé de désactiver " Secure Boot " si je voulais installer des modules / pilotes tiers .
Je n'ai pas obéi.
Et quand j'ai installé manuellement les seuls pilotes tiers que j'utilise ( bcmwl-kernel-source ), on m'a de nouveau demandé (lors de l'installation du paquet) de désactiver le "Secure Boot".
L'utilisation de bcmwl-kernel-source était parfaitement adaptée à Secure Boot dans 15.10 . Cela ne semble pas être lié à un bug pour moi.
Il semble donc que Ubuntu refuse de signer les pilotes / modules tiers pour le faire fonctionner (??) avec "Secure Boot". Ou semble-t-il considérer les modules tiers comme non sécurisés et rompre le "Secure Boot", ce qui oblige à le désactiver pour le rendre clair? Ai-je raison ?
la source
Réponses:
Ce n'est pas un bug, c'est une fonctionnalité.
Comme le dit Anthony Wong, lorsque vous installez un package DKMS, vous le compilez vous-même. Canonical ne peut donc pas signer le module pour vous.
Cependant, vous pouvez certainement utiliser Secure Boot, mais c’est exactement le cas où Secure Boot tente de vous protéger contre vous-même car il ne peut pas savoir si vous faites confiance à un module ou non.
Par défaut , votre ordinateur UEFI comporte une clé de plate-forme (PK), qui est l'autorité de certification ultime pour le chargement de code dans votre processeur.
GRUB, ou shim, ou d’autres mécanismes d’amorçage peuvent être signés numériquement par un KEK approuvé par l’autorité de certification racine (PK). Ainsi, votre ordinateur peut, sans aucune configuration, initialiser un logiciel comme Ubuntu Live USB / DVD.
Sur Ubuntu 16.04, le noyau est construit avec CONFIG_MODULE_SIG_FORCE = 1, ce qui signifie que le noyau imposera aux modules d'être signés par une clé de confiance de la plate-forme. Sachez que la plate-forme UEFI contient par défaut une PC sur laquelle vous n’avez aucun contrôle. Par conséquent, vous ne pouvez pas signer de fichiers binaires avec une clé reconnue par votre propre ordinateur.
Certaines personnes protestent contre cela, mais il n'y a vraiment pas de meilleur moyen (du point de vue de la sécurité) que d'être vous-même qui enregistre la nouvelle clé que vous voulez.
Si votre système de démarrage utilise shim, vous pouvez utiliser quelque chose appelé base de données de clés du propriétaire de la machine et inscrire votre clé en tant que MOK (vous pouvez le faire avec mokutil). Sinon, vous pouvez également inscrire votre clé dans la base de données UEFI en tant que clé de signature.
Une fois que vous avez inscrit votre clé, vous pouvez signer votre paquetage construit avec DKMS avec votre MOK (il devrait y avoir un script perl à
/usr/src/kernels/$(uname -r)/scripts/sign-file), et après l'avoir signé, vous pouvez le charger dans le noyau .Certes, quelqu'un devrait donner plus d'instructions visuelles à ce sujet, et probablement même créer un assistant ou un meilleur standard DKMS pour permettre la prise en compte des clés, mais c'est ce que nous avons maintenant.
Vous pouvez vous référer à cette explication pour signer vos propres modules de noyau: https://askubuntu.com/a/768310/12049
la source
En bref, il ne s’agit pas d’un bogue, mais d’une nouvelle modification introduite dans 16.04.
Parce que ce que vous installez est un paquet dkms. Les modules DKMS sont compilés sur votre propre machine et Canonical ne peut donc pas signer le module pour vous. Si Canonical ne peut pas le signer, il n’ya aucun moyen de le vérifier numériquement. Si le démarrage sécurisé est activé, cela signifie que votre module ne peut pas être utilisé. Pour l'utiliser, vous devez désactiver le démarrage sécurisé. C'est pourquoi la question vous pose la question.
Pour que cela ne se produise que dans 16.04 mais pas dans les versions précédentes, Rod Smith a donné une bonne réponse. Dans Ubuntu 16.04, Ubuntu commence à appliquer le démarrage sécurisé au niveau du noyau. Avant la version 16.04, Ubuntu ne vous oblige pas vraiment à utiliser les modules de noyau et de noyau signés, même si le démarrage sécurisé est activé. Mais ce n'est plus le cas en 16.04.
C'est le bogue associé: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1401532
Voici le schéma directeur associé: https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-installing-unsigned-secureboot
la source
Vous pouvez également créer votre propre clé, insérer la partie publique dans la base de données MOK et signer les modules que vous compilez avec la partie privée. Regardez ici pour des informations détaillées: Impossible de charger 'vboxdrv' après la mise à niveau vers Ubuntu 16.04 (et je souhaite conserver un démarrage sécurisé)
la source
La réponse acceptée est très complète, mais je voudrais ajouter cette simple information, extraite d’ici:
https://askubuntu.com/a/843678/664391
En principe, un démarrage sécurisé peut vous empêcher de charger certains pilotes que vous avez installés, ce qui peut être assez frustrant. Je suis passé par moi-même: le pilote s’est installé correctement, tout semblait aller pour le mieux, mais cela n’a pas fonctionné. Il m'a fallu un peu de temps pour constater qu'il s'agissait d' un démarrage sécurisé empêchant le système d'exploitation de le charger.
la source