Re: [pve-devel] [RFC 0/2] Initial TPM support for VMs

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

On 15.07.21 16:23, Stefan Reiter wrote:
> Design decision: 'swtpm' requires a *directory* per VM to store data, the files
> themselves are rather small (8.5kB for an initialized TPM 2.0 w/ BitLocker
> enabled). To allow for easier HA I went with a path in '/etc/pve/priv' for now,
> but that comes with it's own drawbacks. For example, a guest may write TPM state
> as often as they like, and Windows seems to do so every few seconds at random.
> (note: swtpm writes a temporary file and then uses atomic replace)
> 
> Other ideas for this:
> * store in regular path, e.g. '/var/lib' - how to do HA? (note that
>   live-migration works regardless, since the state is transferred via QEMU)
> * treat like efidisk and allow any storage - would be my favourite, but as said,
>   swtpm requires a directory, not a single file...
> 
> Missing feature/known issues:
> * backups and offline-snapshots don't include TPM data
> * migration may hickup, since destination and target are effectively "the same"
> * needs improved clearing logic, or potentially none at all (would be a benefit
>   for the "efidisk-like" variant)

For the record, I talked about this with Stefan yesterday before he left for vacation,
and while the size seems pretty much OK for a file on pmxcfs the frequent updates are
just a no go, so that approach is NAK'd (not only be me, Dietmar voiced his objections
too).

I recommended asking swtpm upstream if they'd accept options for passing a explicit
TPM state-file and a separate run-state dir for the swtpm locks and state (we wouldn't
even need the swtmp locks as access synchronization of the state-file would be already
by the pve-storage stack locks, but I do not care much for those as there'd be no
contention anyway).

Then we can put the actual state on a volume similar to EFI disks and the ephemeral
run-state somewhere in "/run/qemu-server/$vmid.swtpm/", with that we got snapshots,
migrations (when local storage is used) and backups covered to rather easily.

If upstream is reluctant then an idea would be to either patch it ourself or use the
libtpms to write a replacement tool in rust, but as said, I'd always try to discuss
our needs with upstream first - IMO other (clustered) hyper-visor systems won't be to
happy as is either.