Installer VirtualBox en conservant Secure Boot

4

J'essaie d'installer VirtualBox sur Ubuntu 16.04 tout en conservant Secure Boot. Lorsque je l'ai installé à l'aide de Synaptic, on m'a demandé de supprimer SecureBoot. J'ai dit No .

J'ai suivi ces instructions: Impossible de charger 'vboxdrv' après la mise à niveau vers Ubuntu 16.04 (et je souhaite conserver un démarrage sécurisé) et lien Les deux sont à peu près les mêmes (j'ai laissé les fichiers MOK dans le répertoire / root comme dans le deuxième lien). Tout semble bien fonctionner, j'ai redémarré, remis mon mot de passe, redémarré. Tout va bien

Mais lorsque j'essaie d'utiliser VirtualBox, cela ne fonctionne toujours pas. Si je le lance depuis le terminal, je reçois:

WARNING: The character device /dev/vboxdrv does not exist.
     Please install the virtualbox-dkms package and the appropriate
     headers, most likely linux-headers-generic.

     You will not be able to start VMs until this problem is fixed.

Mais ces deux packages sont déjà installés et à jour.

L'un des commentaires dans la réponse en haut de l'autre message dit de réinstaller virtualbox-dkms avant de suivre ces instructions. J'ai essayé et le même résultat.

J'ai essayé la réponse ici: problème avec l'installation de VirtualBox Ce qui me pousse à nouveau à me demander si je veux désactiver le démarrage sécurisé, auquel je dis No , et revenir à la case départ.

Si je lance modprobe , je reçois: modprobe: ERROR: could not insert 'vboxdrv': Required key not available

Avez-vous une idée sur la façon de faire fonctionner VirtualBox avec SecureBoot activé (veuillez ne pas me demander de le supprimer ...)?

merci

    
posée ddeunagomez 14.05.2017 - 08:02
la source

1 réponse

4

Je n’ai essayé aucune de ces procédures. Cependant, je le fais de manière différente, mais c’est une méthode fastidieuse très . Cette description semblera plus facile que cela car je fais référence à une grande page que j'ai écrite et qui couvre le pire des passages fastidieux. Ma procédure est la suivante:

  1. Prenez le contrôle de Secure Boot : dans mon cas, j'ai configuré mon ordinateur de manière à intégrer ma propre clé publique Secure Boot au micrologiciel. De cette façon, je n'ai pas besoin d'utiliser Shim ou MOK. J'ai retiré les clés de Microsoft et ajouté les clés de mon choix et celles de Canonical à l'ordinateur sur lequel j'utilise cette procédure, mais vous pouvez configurer les vôtres avec les clés de votre choix. La partie essentielle de votre question est que vous devez inclure une clé que vous générez, avec une clé privée que vous conservez pour que cela fonctionne. Vous aurez également besoin de clés utilisées pour signer des composants standard - clé de Canonical, clé de marché publique de Microsoft, ou les deux. Si vous double-amorcez avec Windows, vous aurez besoin de la clé publique utilisée par Microsoft pour signer son propre chargeur de démarrage. Voir cette page de la mienne pour tous les détails sanglants - mais sachez que c'est fastidieux et difficile, de sorte que vous pouvez passer un certain temps à faire fonctionner cette partie. Notez que la plupart des UEFI facilitent la restauration du jeu de clés standard, ce qui réduit les risques liés à l’essai de cette procédure.
  2. Signature des modules VirtualBox : l'étape suivante consiste à signer les modules du noyau VirtualBox. Cela se fait à peu près de la même manière que les pages auxquelles vous avez lié le lien; Cependant, j'ai un script pour aider à automatiser ce processus (voir ci-dessous).
  3. Charger le module VirtualBox : après avoir signé les modules, ils doivent être chargés. Cela devrait se produire automatiquement au redémarrage; mais si vous voulez utiliser VirtualBox sans redémarrer, vous devez explicitement utiliser modprobe pour chacun des modules ( vboxdrv , vboxnetflt , vboxpci et vboxnetadp ).
  4. Répétez les étapes 2 et 3 après chaque mise à jour du noyau : après une mise à jour du noyau, vous devez répéter les étapes 2 et 3.

Par souci de commodité, j'ai écrit un script pour effectuer les étapes 2 et 3 en une seule commande. Je l'appelle sign-vbox . La voici:

#!/bin/bash
# sign-vbox script, copyright (c) 2017 by Rod Smith
# Distributed under the terms of the GPLv3

if [ "$#" -ne 1 ] && [ "$#" -ne 0 ]; then
    echo "Usage: $0 [ {kernel-version} ]"
    exit 1
fi

if [ "$#" == 0 ]; then
    kernel_version=$(uname -r)
else
    kernel_version="$1"
fi

sign_file=$(find /usr/src/ -name sign-file | tail -n 1)

if [ -z $sign_file ]; then
    echo "Can't find the sign-file binary! Exiting!"
    exit 1
else
    path_to_modules="/lib/modules/$kernel_version/updates/dkms"

    if [ ! -f $path_to_modules/vboxdrv.ko ]; then
        echo "Could not find $path_to_modules/vboxdrv.ko!"
        echo "Is the kernel version correct?"
        exit 1
    fi

    echo "Signing modules for $kernel_version"
    $sign_file sha256 /etc/refind.d/keys/refind_local.key /etc/refind.d/keys/refind_local.cer $path_to_modules/vboxdrv.ko
    $sign_file sha256 /etc/refind.d/keys/refind_local.key /etc/refind.d/keys/refind_local.cer $path_to_modules/vboxnetadp.ko
    $sign_file sha256 /etc/refind.d/keys/refind_local.key /etc/refind.d/keys/refind_local.cer $path_to_modules/vboxnetflt.ko
    $sign_file sha256 /etc/refind.d/keys/refind_local.key /etc/refind.d/keys/refind_local.cer $path_to_modules/vboxpci.ko
    modprobe vboxdrv
    modprobe vboxnetflt
    modprobe vboxpci
    modprobe vboxnetadp
    echo "Loaded vbox modules:"
    lsmod | grep vbox
fi

Pour utiliser ce script, tapez simplement son nom. Il signe les modules VirtualBox associés au noyau en cours d’exécution. Si vous lui transmettez un numéro de version du noyau, il doit signer les noyaux associés à cette version du noyau, mais aucune erreur ne peut être commise en spécifiant le numéro de version du noyau. (On s'attend à ce que uname -r renvoie le même format si le noyau était en cours d'exécution.)

Notez que le script s'attend à trouver des clés privées ( refind_local.key ) et publiques ( refind_local.cer ) dans /etc/refind.d/keys/ . Vous devrez changer cet emplacement pour votre propre système, à moins que vous utilisiez rEFInd et que vous utilisiez des clés locales pour cela. Le fichier de clé privée doit être aussi sécurisé que possible, par exemple, avec les autorisations 0400 ( -r-------- ). Limiter l’accès au répertoire lui-même peut également être utile. Mieux encore, placez-le sur un lecteur flash USB que vous ne branchez que lorsque vous exécutez cette commande.

De plus, j’ai écrit ce script pour mon usage personnel. Il y a probablement des bogues, en particulier s’ils sont utilisés de manière inattendue. Certes, cela échoue assez mal si les fichiers sources du noyau nécessaires ne sont pas installés.

Il est concevable que ce script fonctionne avec les méthodes basées sur MOK que vous avez essayé d'utiliser si vous le dirigiez vers les fichiers de clé que vous avez générés, le fichier public que vous avez chargé dans le MOK. Je ne peux cependant pas vous le promettre, et bien sûr vos problèmes pourraient être dus à des modules de noyau mal signés ou à des problèmes du côté de Shim / MOK. Utiliser ce script n’aidera que si les modules de votre noyau n’ont pas été correctement signés.

    
réponse donnée Rod Smith 14.05.2017 - 17:29
la source

Lire d'autres questions sur les étiquettes