web-dev-qa-db-fra.com

Installer VirtualBox en conservant Secure Boot

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 déclaré Noname__.

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 https://stegard.net/2016/10/virtualbox -secure-boot-ubuntu-fail / 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 bon

Mais quand 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 paquets 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 même résultat.

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

Si je lance modprobej'obtiens: modprobe: ERROR: could not insert 'vboxdrv': Required key not available

Toute idée sur la façon de faire fonctionner VirtualBox avec SecureBoot activé (veuillez vous abstenir de me dire de le supprimer ...)?

merci

5
ddeunagomez

Je n'ai essayé aucune de ces procédures. Je le fais cependant d'une manière différente - mais c'est une méthode very fastidieuse. Cette description vous semblera plus facile que cela car je me réfère à 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 critique pour les besoins 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 ça marche. Vous aurez également besoin de clés utilisées pour signer les 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 qu’il s’agit d’une procédure fastidieuse et complexe, vous pouvez donc passer un bon bout de 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. Signez les 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. Chargez 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, les étapes # 2 et # 3 doivent être répétées.

Pour plus de commodité, j'ai écrit un script pour effectuer les étapes 2 et 3 en une seule commande. Je l'appelle sign-vbox. C'est ici:

#!/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. (Il attend le même format que uname -r renverrait 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 les clés locales pour cela. Le fichier de clé privée doit être aussi sécurisé que possible, par exemple, avoir 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 bugs, 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. L'utilisation de ce script n'aidera que si vos modules du noyau ne sont pas correctement signés.

5
Rod Smith