Différence entre vmlinuz * -generic et * -generic.efi.signed
Dans /boot, il y a deux fichiers de noyau vmlinuz:
vmlinuz-4.8.0-37-generic
vmlinuz-4.8.0-37-generic.efi.signed
Quelle est la différence entre ces deux fichiers du noyau? Qui signe le second (s'il est effectivement signé, comme son nom l'indique) et comment mon UEFI/BIOS saurait-il se fier et utiliser *-generic.efi.signed au lieu de *-generic?
Le noyau avec un nom de fichier se terminant par .efi.signed est signé par Canonical pour une utilisation avec Secure Boot. La plupart des ordinateurs ont un micrologiciel qui ne fait pas confiance à la signature de Canonical. c'est uniquement avec l'aide du programme Shim (le binaire shimx64.efi sur le ESP ) que le noyau signé est approuvé.
Pour élaborer un peu, le chemin de chargement des composants signés d'Ubuntu avec Secure Boot activé ressemble à ceci:
EFI -> Shim -> GRUB 2 -> Kernel -> Kernel modules
- EFI fait confiance à Shim car il a été signé par Microsoft, dont les clés sont intégrées au micrologiciel.
- Shim corrige le sous-système Secure Boot d'EFI et inclut la clé publique de Canonical. Shim fait confiance à GRUB 2 car il a été signé avec la clé privée de Canonical.
- GRUB 2 appelle le système Secure Boot de EFI (maintenant corrigé par Shim) pour vérifier le noyau, qui est également signé avec la clé privée de Canonical.
- Le noyau vérifie que les modules du noyau sont signés par la clé privée de Canonical ou par une autre clé de la chaîne Secure Boot.
Avant IIRC, Ubuntu 15.10, GRUB 2 d’Ubuntu n’appliquait pas la stratégie de démarrage sécurisé sur le noyau et le noyau n’appliquait pas la stratégie de démarrage sécurisé sur ses modules. Cela a été resserré récemment, cependant. D’après nos connaissances, il n’est pas prévu d’exiger la signature des fichiers binaires système ordinaires.
Je ne sais pas pourquoi il existe un fichier de noyau non signé dans Ubuntu. Le fichier signé fonctionne correctement même sur les systèmes qui ne prennent pas en charge le démarrage sécurisé (y compris les ordinateurs à BIOS pur). Ainsi, le fichier non signé est plutôt redondant, autant que je sache.
Notez que chacun des composants à partir de Shim peut être obtenu sous forme non signée, ou leurs signatures enlevées. Si vous construisez vous-même Shim, vous pouvez remplacer la clé publique de Canonical par la vôtre, ou par toute autre clé publique de votre choix. (La plupart des distributions majeures ont leurs propres binaires Shim avec leurs propres clés intégrées.) Construire Shim à partir des sources serait inutile si vous ne le faites pas signer à Microsoft, ce qui coûterait 100 $ et prendrait un lot d'effort. Si vous devez signer des documents vous-même, il est plus facile d'ajouter votre clé en tant que clé de propriétaire de machine (MOK) plutôt que de reconstruire Shim et de la faire signer par Microsoft. Vous pouvez également modifier les jeux de clés pris en charge directement par EFI, afin d’éviter le recours à Shim. Ainsi, vous pouvez changer beaucoup de choses sur la manière dont toutes ces pièces s’assemblent. Voir ma page principale sur Secure Boot et ma page sur le contrôle total de Secure Boot pour plus de détails sur la gestion de Secure Boot.
La version signée est destinée au démarrage sécurisé UEFI. Il a été signé en utilisant un cryptage asymétrique. Ce qui signifie que la clé pour le déchiffrer est différente de celle utilisée pour le chiffrer. Le bios a seulement une clé publique et peut vérifier si la signature est correcte (n’a pas été falsifiée). La clé privée pour créer une telle signature est secrète et vous ne pouvez donc pas la créer vous-même. C'est pourquoi le bios fait confiance et lui permet de démarrer.
Pour plus d'informations: https://wiki.ubuntu.com/SecurityTeam/SecureBoot