[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to use uefi secure boot in a virtual machine in Debian Buster 10



On Sat, Aug 31, 2019 at 4:07 PM adrian15 adrian15 <adrian15sgd@gmail.com> wrote:
>
>   I have had too many problems trying to setup a proper secure boot in a kvm virtual machine.
>  So I finally wrote down the steps I used on:
> https://wiki.debian.org/SecureBoot/VirtualMachine
> which I linked from:
> https://wiki.debian.org/SecureBoot#Testing_Secure_Boot_in_a_virtual_machine
> .
>
> Feel free to edit wiki page if you find anything that can be improved.
>
> In any case in order to ease feedback I copy and paste the current page contents so that you can comment inline here in the mailing list.
>
> Introduction
> These instructions let you setup a virtual machine setup based on KVM and Tianocore which has secure boot on. This setup has already Microsoft keys built-in and probably the Redhat ones.
>
> These instructions should be run as a normal user. We assume sudo has been installed and the user who runs the commands can use sudo to get root privileges.
>
> Requirements
> VT-Technology or AMD-V (virtualization) turned on on your computer
> Debian Buster 10 amd64 installation booted from an 64-bit kernel
> Initial UEFI Setup
> We will use separate OVMF_CODE.fd an OVMF_VARS.fd files so that each virtual machine can have its own UEFI variables
>
> Install kvm if we have not yet and ovmf (ovmf is not strictly needed, see #TO DO below).
>
> sudo apt-get install qemu-kvm ovmf
> Create our virtual machine directory where its associated files live.
>
> mkdir ~/gnu/secureboot-vm
> cd ~/gnu/secureboot-vm
> Get secureboot firmware from Fedora
> First of all we get rpm package so that we can extract its contents.
>
> sudo apt-get install rpm
> We will create and use a temporary directory so that we don't mess too much our system.
>
> mkdir tmp-fedora-rpm
> cd tmp-fedora-rpm
> We are interested on the Fedora's secboot version of the OVMF_CODE and OVMF_VARS fd files. So that we don't have to add secure boot keys manually.
>
> wget "https://download-ib01.fedoraproject.org/pub/fedora-secondary/updates/30/Everything/i386/Packages/e/edk2-ovmf-20190501stable-2.fc30.noarch.rpm";
> rpm2cpio edk2-ovmf-20190501stable-2.fc30.noarch.rpm | cpio -idmv
> cp ./usr/share/OVMF/UefiShell.iso ../
> cp ./usr/share/edk2/ovmf/OVMF_CODE.secboot.fd ../OVMF_CODE.fd
> cp ./usr/share/edk2/ovmf/OVMF_VARS.secboot.fd ../OVMF_VARS.fd
> Now we can remove temporary stuff.
>
> cd ..
> rm -rf tmp-fedora-rpm
> Test a virtual machine and change its boot order
> In this case we want to test a raw image as the main hard disk with this filename: /home/rescatuxs/super_grub2_disk_hybrid_secureboot_usb_2.04s2-beta1.img .
>
>
> sudo kvm \
>  -m 2048 \
>  --machine pc-q35-2.5 \
>  -drive if=pflash,format=raw,readonly,file=./OVMF_CODE.fd \
>  -drive if=pflash,format=raw,file=./OVMF_VARS.fd \
>  -drive file=/home/rescatuxs/super_grub2_disk_hybrid_secureboot_usb_2.04s2-beta1.img,format=raw,index=0,media=disk \
>  -boot menu=on
> Press ESC when the machine boots and you see: Start boot option at the bottom.
>
> Choose the following options from the UEFI menus:
>
> Boot Maintenance Manager
> Boot Options
> Change Boot Order
> Press Enter
>
> What you get is:
>
> UEFI QEMU DVD-ROM
> UEFI PXEv4
> UEFI PXEv4
> UEFI PXEv6
> UEFI QEMU HARDDISK QM00001
> Now, we will change the list into this order:
>
> UEFI QEMU DVD-ROM
> UEFI QEMU HARDDISK QM00001
> UEFI PXEv4
> UEFI PXEv4
> UEFI PXEv6
> .
>
> That way we avoid having to wait for the different UEFI PXE entries to timeout.
>
> Press enter when finished. Commit Changes and Exit Press ESC till you get out of the BIOS.
>
> Test a virtual machine
>
> sudo kvm \
>  -m 2048 \
>  --machine pc-q35-2.5 \
>  -drive if=pflash,format=raw,readonly,file=./OVMF_CODE.fd \
>  -drive if=pflash,format=raw,file=./OVMF_VARS.fd \
>  -drive file=/home/rescatuxs/super_grub2_disk_hybrid_secureboot_usb_2.04s2-beta1.img,format=raw,index=0,media=disk \
>  -boot menu=on
> What you get
> You should be able to boot secure boot enabled cdrom or hard disk images. If any of these images are not properly signed by the Microsoft or Redhat keys then they will fail to boot.
>
> The read only firmware for your virtual machine is located at: ~/gnu/secureboot-vm/OVMF_CODE.fd .
>
> The read and write state of your UEFI variables for that specific virtual machine is located at: ~/gnu/secureboot-vm/OVMF_VARS.fd .
>
> Notes
> Apparently pc-q35-2.5 qemu machine type is needed so that secureboot works or, at least, shows a graphical output.
>
> Useful links
> https://fedoraproject.org/wiki/Using_UEFI_with_QEMU
>
> https://artem.services/?p=752
>
> https://ubs_csse.gitlab.io/secu_os/tutorials/virtual_env.html
>
> https://askbot.fedoraproject.org/en/question/86384/wiki-using-uefi-with-qemu/
>
> TO DO
> Debian only method with secureboot images
> If Debian ovmf package provides:
>
> OVMF_CODE.secboot.fd
> OVMF_VARS.secboot.fd
> in the future just install Debian ovmf package instead and use them instead.

hey Adrian,
  Thanks for documenting this. fyi, Debian's ovmf does provide
secureboot images in testing/unstable. The vars file w/ prebaked
Microsoft keys is OVMF_VARS.ms.fd.

  -dann


> Debian only method with UefiShell.iso from Fedora
> If someone else manages to use default Debian files:
>
> /usr/share/OVMF/OVMF_CODE.fd
> /usr/share/OVMF/OVMF_VARS.fd
> with the ?UefiShell.iso file from Fedora's edk2-ovmf package so that you can turn on a non secure boot vm to a secure boot one manually. Please update this page. I prefer doing that step manually than relying on:
>
> OVMF_CODE.secboot.fd
> OVMF_VARS.secboot.fd
> which have those keys embedded.
>
> virt-manager
> I prefer using qemu or kvm rather than relying on virt-manager or another GUI. If you manage to adapt these instructions to virt-manager please write another page and link to it from this one.
>
> Thank you
> Thanks to the people from #debian-efi channel on OFTC for their patience because I usually make too many questions there.
>
>
> adrian15
> --
> Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/index.php?pid=10


Reply to: