You are not logged in.
Hi *,
I'm trying to determine whether it's normal or not that I cannot enable Secure Boot in QEMU VMs firmware, despite using
/usr/share/edk2/x64/OVMF_CODE.secboot.4m.fd
as the firmware file and having a writable OVMF_VARS.4m.fd copy.
I've been following the wiki on UEFI in QEMU, and I see no mention of something else being needed.
Basically I'm having the same problem as reported on Reddit here and there. Looks like it used to work for some, and I feel like it used to work for me in the past as well, but no dice right now.
Here's the command I am using to test it:
cp {/usr/share/edk2/x64/,}OVMF_VARS.4m.fd
qemu-system-x86_64 \
-machine type=q35,accel=kvm \
-cpu host -smp 2 -m 1G \
-cdrom archlinux-2024.12.01-x86_64.iso \
-drive if=pflash,format=raw,readonly=on,file="/usr/share/edk2/x64/OVMF_CODE.secboot.4m.fd" \
-drive if=pflash,format=raw,file="OVMF_VARS.4m.fd"
Then I press Esc straight away (or "Reboot into Firmware Interface" from the Arch ISO menu if I didn't get the time), go into Device Manager > Secure Boot Configuration, and here "Current Secure Boot State" is Disabled without any way for me to enable it.
I read the mention in upstream README about the need to enroll the keys oneself, so I followed the instructions to do it, but when I boot with
-smbios type=11,path=PkKek1.oemstr
added there's no difference.
The issue seems to me that Arch doesn't include OvmfPkg/EnrollDefaultKeys in its edk2-ovmf package, so I cannot launch it from the EFI Shell. But before I open a bug report I wanted to poll other users to know whether someone has Secure Boot working in its QEMU/libvirt VMs, and if so how they did it.
Thanks for your input!
Offline
I just checked in virt-manager and it is exactly the same thing: no way to toggle "Current Secure Boot State" to "Enabled" in the VM UEFI parameters despite selecting the /usr/share/edk2/x64/OVMF_CODE.secboot.4m.fd firmware.
When I tried to manually edit the XML to switch
<feature enabled="no" name="enrolled-keys"/>
to yes, it gave the following error: "Unable to find 'efi' firmware that is compatible with the current configuration".
I'm at a loss.
Offline
The more I read about it and the more it seems it all boils down to Arch not providing the required files in the edk2-ovmf package. Compare with the content of Debian's package for example: they have those .ms and snakeoil.{fd,pem,key} files in there, which would explain why Secure Boot works in a Proxmox VM.
Edit: same thing with Fedora's package which provides a OVMF_VARS.secboot.fd file.
Last edited by Neitsab (2024-12-05 19:57:35)
Offline
I've finally managed to do it! Here's what I did:
- I downloaded the latest Fedora's build of edk2-ovmf (in my case I used this one)
- I unpacked the RPM package and copied the usr/share/edk2/ovmf/UefiShell.iso to my working directory
- I started the "VM" with the following command:
qemu-system-x86_64 \
-machine type=q35,accel=kvm \
-cpu host -smp 2 -m 1G \
-cdrom UefiShell.iso \
-drive if=pflash,format=raw,readonly=on,file="/usr/share/edk2/x64/OVMF_CODE.secboot.4m.fd" \
-drive if=pflash,format=raw,file="OVMF_VARS.4m.fd"
-smbios type=11,path=PkKek1.oemstr
(Note that this requires you to have followed the aforementioned instructions to generate the PkKek1.oemstr file)
- in the UEFI shell, I followed the instructions from the Fedora docs and got:
Shell> fs0:
FS0:\> EnrollDefaultKeys.efi
info: SetupMode=1 SecureBoot=0 SecureBootEnable=0 CustomMode=0 VendorKeys=1
info: SetupMode=0 SecureBoot=1 SecureBootEnable=1 CustomMode=0 VendorKeys=0
info: success
- then I shut down the VM from the EFI Shell with "reset -s", went back to my original command, entered the firmware settings... And there it was, Secure Boot Current State set to Enabled!
Now I can toggle "Attempt Secure Boot" on and off and have a Secure Boot-enabled OVMF_VARS file
Last edited by Neitsab (2024-12-05 19:27:51)
Offline
I've just stumbled upon https://gitlab.archlinux.org/archlinux/ … -/issues/1 which describes exactly this issue, shows that the issue is pretty old. All my work was in vain At least it provides some context for the Arch side.
See https://bugs.archlinux.org/task/78419 for a more recent duplicate and https://www.spinics.net/linux/fedora/fe … 21045.html for a slightly less cumbersome solution. Basically do
qemu-img convert -O raw -f qcow2 edk2-ovmf-20240813-2.fc41.noarch/usr/share/edk2/ovmf/OVMF_VARS_4M.secboot.qcow2 OVMF_VARS_4M.secboot.fd
to get an already working SecureBoot-enabled VARS file that you can then use in your QEMU invocations.
Last edited by Neitsab (2024-12-05 20:01:54)
Offline
although a nice read - don't bump your own topic this way - if noone replied yet just edit your post
anyway - my personal opinion: secureboot is complete marketing bullshit and as useless as full drive encryption
why? because it's usually implemented incomplete or just wrong
secureboot and encryption are only helpful if you keep the chain all the way to the applications that get executed, thier configs and the data you can access
the very second you allow any arbitrary code to run you break the chain it's supposed to offer
tldr: only if you can build a complete chain from the platforms master key all the way up to what code you can run and what data you can access with its useless garbage
with windows in a domain and policies about what is allowed to execute and what is able to be accessed this might work - but for linux you'd have to build and sign everything yourself basically going the full Linux From Scratch route - or what gentoo used to be before it started to provide pre-built binaries
so - why even bother with it?
as for drive encryption: that loses its value the second you bring "physical attack" into play: yes, it may cause some trouble if you just lose a device by forgetting it on the seat next to you - but what does it help you if you work actively on the machine and I just walking up to you punching you in the face and just steal the unlocked device?
or for locking your phone with a finger print - well - that wouldn't stop yakuza from just cutting your finger right off your hand
sure - may sounds extreme - but THAT's the real threat vectors one should think about when considering secureboot and drive encryption - everything is just homelab level nonesense and you bett off with just doing everything remote on a server with your machine being merely a dumb terminal not storing or processing any data on its own
Offline
having a similar issue, trying to enable secure boot for a windows VM that i intend to use with an intune enrollment, meaning secure boot is a requirement.
not able to enable secure boot in VM's BIOS, presumably because the arch package provides no pre-enrolled keys.. trying to force enable "enrolled-keys" in the domain XML would throw errors stating that no supported 'efi' firmware could be found because none of the configured firmware entries arch provides for libvirt have keys enrolled, fair enough..
there are a couple of packages on the aur related to this, specifically there is one that pulls down the fedora package and extracts it but following those instructions to enroll keys in an efi shell just resulted in errors - i admit i am perhaps out of my depth here.. i was not trying to enroll any distro/self signed keys
so, eventually, i solved this issue for windows by er.. cheating?
- downloading the ubuntu noble ovmf package "ovmf_2024.02-2_all.deb"
- extract the files
- copied <extractdir>/share/OVMF/OVMF_CODE_4M.ms.fd to /usr/share/ovmf/x64/OVMF_CODE_4M.ms.fd
- copied <extractdir>/share/OVMF/OVMF_VARS_4M.ms.fd to /usr/share/ovmf/x64/OVMF_VARS_4M.ms.fd
- copied <extractdir>/share/qemu/firmware/40-edk2-x86_64-secure-enrolled.json to /usr/share/qemu/firmware0-edk2-x86_64-secure-enrolled.json
- edited /usr/share/qemu/firmware0-edk2-x86_64-secure-enrolled.json and updated paths to firmware "fd" files to match above paths
- force a reload of the libvirtd daemon
- edited the VM domain XML to update firmware/nvram paths to point to the ubuntu firmware paths as above, and set the "enrolled-keys" feature setting to "yes"
- cleared the VM's nvram with...
virsh start windowsvm --reset-nvram
after all that, secure boot was enabled in the BIOS, and the OS reports secure boot is enabled
Offline