Retour et partage d’expérience pour l’installation de rEFind, l’interface graphique de démarrage “shiny” à la place de grub, en conservant le secure boot.

La raison principale, j’ai un ordinateur portable 2 en 1, avec écran tactile, et je me suis dit que ce serait pratique de choisir son os, au démarrage, en appuyant sur l’écran.

Alors l’installation est très simple lorsque le “secure boot” est désactivé :

sudo dnf install rEFInd shim-x64 sbsigntools mokutil

sudo refind-install --shim /boot/efi/EFI/fedora/shimx64.efi

Redémarrage et c’est joli.

Par contre, j’ai mis du temps à trouver une solution, qui ne fait pas tomber rEFind vers l’interface mok lorsque le secure boot est activé, bien que les vmlinuz soient déjà signé.

La raison : il faut signer le fichier .efi de rEFind.

La solution a été partagée sur le forum de manjaro : https://forum.manjaro.org/t/howto-enable-secure-boot-with-refind/121403/5

Après l’installation de refind, il faut créer un fichier csv dans /boot/efi/EFI/refind/refind_x64.csv et ajouter :

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grubx64,1,Roderick W. Smith,rEFInd,0.13.3,https://www.rodsbooks.com/refind

Ensuite, il faut modifier le grubx64.efi en y ajoutant les données du fichier csv :

sudo objcopy --set-section-alignment '.sbat=512' --add-section .sbat=refind_x64.csv --adjust-section-vma .sbat+10000000 /boot/efi/EFI/refind/grubx64.efi

Puis signer le fichier grubx64.efi (Se rendre dans le répertoire /boot/efi/EFI/refind/)

sudo sbsign --key /etc/refind.d/keys/refind_local.key --cert /etc/refind.d/keys/refind_local.crt --output /boot/efi/EFI/refind/grubx64.efi /boot/efi/EFI/refind/grubx64.efi

Et pour vérifier que l’on est bien en secureboot :

sudo mokutil --sb-state

Pour activer l’écran tactile ou la souris, éditer le fichier /boot/efi/EFI/refind/refind.conf :

enable_touch
enable_mouse

Alors, j’ai également fait les premières manipulations expliquée dans le fil de discussion partagé ci-dessus. Mais je ne pense pas que ce soit utile.

J’ai évidemment fait d’autres manipulations, surtout sélectionner des fichiers par l’interface mok sans arriver au résultat voulu, peut-être créé des “local_key”, je ne m’en souviens pas, donc je ne sais pas s’il y a une étape à ajouter quelque part, mais je ne pense pas non plus.

S’il y a des personnes qui souhaitent tester et me faire un retour pour modifier le fil, faites vous plaisir.

Je vais maintenant essayer de régler le problème de rafraîchissement lent dans grub que j’ai juste après la sélection de fedora (ce n’est pas très grave), je suppose un chargement de driver manquant ou une résolution trop grande.

    Pourquoi pas.

    Sur le site du projet, j’ai vu une autre manière de signer les .efi. Je vais tester.
    C’est que je ne comprend pas pourquoi il faut ajouter des données dans le .efi avec un fichier csv, cela fonctionne mais je trouve ça étrange.

    Sinon je viens de tomber sur un article expliquant comment carrément remplacer les clés du secure boot.
    https://sysguides.com/fedora-uefi-secure-boot-with-custom-keys

    Et désolé pour les “tag”, je n’ai pas trouver comment en rajouter.

      Bridelice Super, pas de souci pour t’accompagner dans ce projet d’article au besoin.

      Quand j’ai lu ton message, j’ai effectivement été interpellé par ce fichier .csv à créer mais je ne sais pas quoi en dire pour le moment. J’avais regardé ce projet il y a quelques temps mais sans plus approfondir non plus.

      Oui, effectivement cet article pour remplacer les clés du secure boot semble intéressant pour mieux comprendre les processus derrière.

      Pour les tags, le choix se fait au dessus de la zone de Titre sinon une fois le message posté c’est accessible via le menu à côté du bouton Répondre en haut à droite.

      Je t’invite vivement à lire les Conditions d’utilisation dont le lien est aussi en bas de page ainsi que plus particulièrement la FAQ du Forum. Ceci te permettra de mieux appréhender le nouveau Forum.

        7 jours plus tard

        J’ai testé depuis une installation toute fraîche.
        Il faut bien créer ce fichier .csv, et l’ajouter dans le grubx64.efi. Je ne comprends toujours pas pourquoi.

        Il faut bien créer les clés. J’ai chercher pour signer avec un certificat fedora, mais je n’ai pas trouvé les clés privées, ce qui est plutôt logique, si quelqu’un les a, ou alors sait où elles se cachent, je prends, et cela éviterait la phase de création de clés.
        Alors il existe plusieurs méthodes pour le faire, je propose ici de passer par akmod, que je trouve plus simple d’utilisation :

        shim-x64 et mokutil sont déjà installé sur une fedora-workstation. Sans doute pour importer la clé mok de fedora à l’installation. (je ne sais pas si kernel-devel est vraiment nécessaire, mais à mon avis installé par akmods)

        sudo dnf install rEFInd sbsigntools kernel-devel akmods

        Générer sa clé :

        sudo kmodgenca

        Compléter le formulaire

        ou avec l’option -a si vous ne souhaitez pas compléter le formulaire.

        Les clés se trouvent dans

        sudo ls /etc/pki/akmods/certs/
        sudo ls /etc/pki/akmods/private/

        Charger sa clé par MOK

        sudo mokutil --import /etc/pki/akmods/certs/public_key.der

        Il vous demande de taper un mot de passe.
        Attention, lors de la phase de redémarrage, l’interface MOK est en clavier QWERTY. J’ai donc utilisé un mot de passe simple, qui ne sert qu’une seul fois.

        Redémarrer

        Au démarrage, vous allez tomber sur l’interface mok, suivre les instructions pour inscrire la clé, taper votre mot de passe. Vous pouvez également vérifier si c’est bien votre clé avant de l’enregistrer. Puis l’ordinateur redémarre.

        Convertir le .der en .pem utilisable par sbsign

        sudo openssl x509 -in /etc/pki/akmods/certs/public_key.der -inform DER -outform PEM -out /etc/pki/akmods/certs/public_key.pem

        Cacher le fichier à la vu de tout le monde

        sudo chmod o-r public_key.pem

        Installer refind

        sudo refind-install --shim /boot/efi/EFI/fedora/shimx64.efi

        Créer un fichier .csv dans /boot/efi/EFI/refind/refind_x64.csv et ajouter :

        sudo sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
        grubx64,1,Roderick W. Smith,rEFInd,0.13.3,https://www.rodsbooks.com/refind

        Modifier le grubx64.efi en y ajoutant les données du fichier csv :

        sudo objcopy --set-section-alignment '.sbat=512' --add-section .sbat=/boot/efi/EFI/refind/refind_x64.csv --adjust-section-vma .sbat+10000000 /boot/efi/EFI/refind/grubx64.efi

        Signer le chargeur de démarrage :

        sudo sbsign --key /etc/pki/akmods/private/private_key.priv --cert /etc/pki/akmods/certs/public_key.pem --output /boot/efi/EFI/refind/grubx64.efi /boot/efi/EFI/refind/grubx64.efi

        Redémarrer

        Cela ne me convient pas tout à fait, bien que ce certificat est créé par l’installation des modules graphiques nvidia par exemple, et donc évite la multiplication des certificats. Ne possédant pas de carte nvidia ou d’objet avec des drivers exotiques à charger, je ne peux pas vérifier qu’un certificat est bien créer et inscrit par mok ou autre. C’est une piste à creuser pour éviter la partie “mot de passe”, si cela est fait de façon “transparente”.

        Sinon, j’aurai lu que fedora utiliserai des certificats provenant de chez microsoft, mais j’ai lu cela en diagonale sur un forum, donc je ne suis pas vraiment en capacité de vérifier cette information.

        Zut, temps écoulé pour la modification

        Alors j’ai une erreur au démarrage :

        Secure Boot validation failure loading btrfs_x64.efi!

        J’ai simplement oublié de signer le driver :

        sudo sbsign --key /etc/pki/akmods/private/private_key.priv --cert /etc/pki/akmods/certs/public_key.pem --output /boot/efi/EFI/refind/drivers_x64/btrfs_x64.efi /boot/efi/EFI/refind/drivers_x64/btrfs_x64.efi

        En tout cas, si il y a une modification d’un fichier de demarrage, on est bien prévenu.

          Bridelice Merci pour ce nouveau retour bien complet.

          Tes essais ont permis de soulever d’autres soucis du coup, c’est cool.

            Alors, je commence à comprendre l’utilité du fichier .sbat :
            Je vais résumer ce que je comprends de ce lien : https://github.com/rhboot/shim/blob/main/SBAT.md
            Vous pouvez me contredire avec plaisir, si je raconte des bêtises.

            En gros, tous les fournisseurs d’OS doivent signer un fichier shim pour faire démarrer leur système par le secure boot. Mais cela créé beaucoup de clés dont il faut faire confiance. Et il n’est pas possible de toutes les avoirs dans nos puces matériels.
            Il y a donc un premier chargement s’appelant sbat permettant de charger shim, qui charge grub qui charge l’os.
            La taille du sbat est réduite au minimum pour éviter l’introduction de code malveillant.
            Si une faille ou un bug existe dans les autres niveaux de chargement. Le fichier sbat est mis à jour avec les versions minimal de grub ou de fedora à installer. C’est le mainteneur de l’os qui gère son/ses shim et met à jour le fichier sbat chez lui. (Cela fait beaucoup de fichier shim différent)
            Des failles exploitées ont déjà eu lieu comme le “boothole” https://www.it-connect.fr/boothole-une-vulnerabilite-qui-touche-linux-et-windows/ .
            Donc il faut “versionner” les fichiers shim, et c’est là qu’intervient le fichier csv.
            Un “bootloader” signé mais non “versionné” n’est pas valide. (Les drivers ne sont pas concernés par le sbat)

            Sinon j’ai repéré l’option –encryptkeys qui va de pair avec –localkeys lors de l’installation de rEFInd pour chiffrer la clé avec un mot de passe, qui semble intéressant pour une installation passant uniquement par l’outil refind-install, sbsign et mokutil.