Pourquoi la désactivation de "Secure Boot" est une politique appliquée lors de l'installation de modules tiers
Lors de l'installation 16.04 , il m'a été demandé d'éteindre "Secure Boot" si je voulais installer 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 demandé à nouveau (lors de l’installation du paquet) désactiver "Secure Boot".
Utiliser bcmwl-kernel-source était parfaitement correct avec Secure Boot in 15.1. 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 ?
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 , il existe une clé de plate-forme (PK) sur votre ordinateur UEFI, qui est l'autorité de certification de confiance pour le chargement du 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), ce qui permet à votre ordinateur , sans aucune configuration, démarrez un logiciel tel que 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 sur 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.
Après avoir inscrit votre clé, vous pouvez signer votre package construit avec DKMS avec votre MOK (un script Perl devrait exister à /usr/src/kernels/$(uname -r)/scripts/sign-file), et une fois 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
En bref, il ne s’agit pas d’un bogue, mais d’une nouvelle modification introduite dans la version 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
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 veux garder un démarrage sécurisé)
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 découvrir que c'était un démarrage sécurisé empêchant le système d'exploitation de le charger.