Manually figured out the path to ovmf firmware and pointed libvirt to it and modified other settings to allow EFI boot.
<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>
<controller type='pci' index='0' model='pcie-root'/>
change piix3 bus to 0x02
Installed the latest packages required on Buster:
apt install shim-signed grub-efi-amd64-signed linux-image-4.19.0-4-amd64
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
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