The necessary features to make this simple were done after the Buster Freeze by some months.
This article has the best info on enabling it in Libvirt:
Until then I’ll take a crack at it and see how ready support is now.
Here is also Tails’ research on the topic:
Preliminary build support for KVM in debootstrap can be bolted on until it is developed upstream.
Status update:
Manually figured out the path to ovmf firmware and pointed libvirt to it and modified other settings to allow EFI boot.
<os>
<type arch='x86_64' machine='pc-q35-3.0'>hvm</type>
<loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader>
<nvram template='/usr/share/qemu/OVMF.fd'>/var/lib/libvirt/qemu/nvram/guest_VARS.fd</nvram>
<boot dev='hd'/>
</os>
<features>
<smm state='on'/>
<controller type='pci' index='0' model='pcie-root'/>
change piix3 bus to 0x02
Installed the latest packages required on Buster:
SecureBoot/Testing - Debian Wiki
apt install shim-signed grub-efi-amd64-signed linux-image-4.19.0-4-amd64
Result:
I can now boot into the EFI menu however the secure boot option is grayed out. Turns out there is a key enrollment step which is very difficult to do and most instructions out there are either outdated or irrelevant for Debian. Even harder is the question of how to accomplish this in an automated way because Whonix usability will go to shit if this is the amount of effort needed to boot the system.
Also turns out that enabling secure boot prevents VMs from supporting snapshots which makes it very impractical for everyday use.
Error creating snapshot: Operation not supported: internal snapshots of a VM with pflash based firmware are not supported
Other notes:
What is the security value of this feature if it relies on a shim signed with a key from MS that has been previously leaked?
While secure boot will prevent an attacker from loading their own modules, Sophisticated attackers are usually going to exploit holes in the signed code or arrange current running code in memory to execute their instructions. The only work on this is being researched by grsec under their KERNSEAL stuff which isn;t even available as of yet.
DATA ONLY ATTACKS
A rootkit attack that modifies kernel data structures without
injecting new code is called a “data-only rootkit attack.” Under
a data-only attack the attacker has full access to read and write
all kernel memory, but is unable to add new code or modify
existing code that will be executed with the kernel’s privilege
level.
Under QEMU with OVMF Secure Boot
https://docs.clip-os.org/clipos/boot_integrity.html#under-qemu-with-ovmf
Nice but looks like it supports Fedora paths of ovmf binaries also if we were to do this no snapshots are possible so lets stick to the iso verified grub boot.
Any update?