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?
Current way of installing kvm on debian is with UEFI + Secureboot support, any reason to keep holding back not to use/enable them by default?
Some things break by design and require user interaction to resolve when using Secure Boot:
The last two may not matter that much, the first two are more important, the first one especially.
Yeah first one only matters.
Ok so lets change first thing first, UEFI only, whats the issue?
Note, this is a KVM sub forum thread.
Lack of rationale. See:
BIOS vs EFI vs coreboot vs libreboot
Therefore low priority.
Waiting for @HulaHoop / input.
I had documented enabling UEFI as I was misled into thinking it was necessary for using vTPM in KVM. Patrick informed me that Sovereign Boot is the way to go for actual safety and freedom in this area.
Anyway while I don’t see the point of UEFI for real security, here’s how to do it:
AFAIK the KVM UEFI implementation allows for self enrolling your own keys. Whether the usability hit is worth it is another question
I think someone has written a modern version of memtest that supports newer memory and UEFI
https://old.reddit.com/r/linux/comments/lxmjqz/has_there_been_any_effort_of_porting_memtest86_to/
Yeah, that’s what I was referencing with “enrolling a MOK”, and the usability hit is the problem. Kicksecure tries to make it as easy as possible to enroll the keys, but it’s still a pain and there’s no way to make it not-a-pain since it’s a pain by design.
memtest86+ runs on UEFI nowadays I think, the issue is that it’s not signed and I’m not sure there’s any way to get it to be signed (I asked on a Debian mailing list some time back and got no response). Now not only do you have to enroll a MOK, you also have to sign the EFI binary for memtest86+ with that MOK, which is even more of a pain. I suppose Kicksecure could add some mechanism (apt trigger?) to automatically do that any time memtest86+ was upgraded, but then you’d still need to enroll the MOK.