[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

UEFI Secure Boot support

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:

https://specs.openstack.org/openstack/nova-specs/specs/train/approved/allow-secure-boot-for-qemu-kvm-guests.html

Until then I’ll take a crack at it and see how ready support is now.

Here is also Tails’ research on the topic:

https://tails.boum.org/blueprint/UEFI_Secure_boot/


Preliminary build support for KVM in debootstrap can be bolted on until it is developed upstream.

1 Like

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:

    https://wiki.debian.org/SecureBoot/Testing

    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.

1 Like

Under QEMU with OVMF Secure Boot

https://docs.clip-os.org/clipos/boot_integrity.html#under-qemu-with-ovmf


1 Like

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.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]