Hi, I’ve discovered an odd behavior on Fedora Server and I was wondering if it is intended or a bug, and if it needs to be reported somewhere. I was trying to use Fedora Server 43 in a QEMU virtual machine with the UEFI x86_64: /usr/share/edk2/ovmf/OVMF_CODE_M4.secboot.qcow2 firmware, an Emulated TIS 2.0 TPU device and a LUKS encrypted qcow2 volume. I wanted to follow this link for auto unlocking LUKS via TPM, however when I get to the last step and reboot I am still prompted for the LUKS password. I was able to follow this guide on a “baremetal” machine with Fedora KDE, as well as a QEMU Virtual Machine with the same configuration but with Fedora KDE 43 and have LUKS auto-unencrypt. I would want Fedora Server to be unattended, but protected against hard drive theft. Having to type in the LUKS password every boot would make it a lot less unattended than I would want. I have been able to reproduce this behavior across 3 host machines, an Intel Xeon E5-2600 running Fedora Server 43 , an AMD Ryzen 7 7840 running Fedora KDE 43, and an Intel i9 (forget the model #) running Fedora Server 42.
If the host is not using encrypted storage for the qcow2 image and vm meta data then you have not protection at rest.
I can simply use the vm image and the tpm data, that is on disk to unlock the image.
On the other hand I would have expected what you setup to work.
The idea would be the host would also be encrypted, and I was planning to use the emulated TPM in combination with a real TPM on the host, my understanding was you can’t use the real TPM across multiple VMs.
I was also expecting this to work, is this a bug that should be reported, and if it is do you know how to report it?
Maybe report against kvm?
I am still unclear why you think this is required to improve security.
I want my drives encrypted, and I want to pass through an entire HDD to a VM, which I also want encrypted. I want them encrypted in case of theft.
Aha, so the host’s encrypted disk does not contain the VM’s disk image it’s a seperate drive. Got it.