On Thu, Jun 20, 2019 at 10:34:24AM -0400, Jim Rollenhagen wrote:
Hey y'all,
We have an internal use case which requires a VM with a TPM, to be used to store a private key. Libvirt has two ways to present a TPM to a VM: passthrough or emulated. Per kashyap and the #qemu IRC channel, libvirt stores the TPM's state on disk, unencrypted. Our risk profile includes "someone walks away with a disk", so this won't work for our use case.
The QEMU devs have asked for RFEs to implement vTPMs where the state never touches the disk, so I have hopes that this will be done eventually.
I haven't gotten around to file the two things requested for this feature for TPM passthrough. (At least for libvirt, anyone with an upstream Bugzilla account can file the RFE in its tracker[1].) (*) File a libvirt RFE to make it not store encryption keys on disk (currently it stores the TPM state under: /var/lib/libvirt/swtpm/). The libvirt/QEMU folks are still debating the design. It is likely to be similar to how libvirt handles the keys for LUKS encryption. (*) Daniel Berrangé suggested that we might also need an RFE for "swtpm" project[2] so as to allow libvirt / QEMU pass keys around without them being on disk. Currently `swtpm` has: --key file=<keyfile>[,format=<hex|binary>][,mode=aes-cbc|aes-256-cbc],[remove[=true|false]] E.g. to have a parameter that allows file descriptor passing: "--key fd=NN" - - - And for Nova, I agree, a "lightweight" spec would be useful to flesh out details. Based on the IRC chat on #qemu (OFTC), there's a subtle detail that Nova needs to pay attention to: as the key file would still pass through libvirt, the "mgmt app" (e.g. Nova) can control how long it is around for. Daniel suggested "mgmt app" can purge the keys from libvirt once the guest is running, and can tell libvirt to keep it only in memory. [1] https://libvirt.org/bugs.html [2] https://github.com/stefanberger/swtpm/wiki [...] -- /kashyap