On Thu, Jun 27, 2019 at 12:15:12PM -0400, Stefan Berger wrote: > Hello! > >   Marc-André told me there was interest in encrypting the vTPM state.  I do > have some patches along these lines from a long time ago that I haven't > upstreamed. I'd be curious about some feedback on some corner stones of the > design to support this: The biggest concern was how the secret would be passed to swtpm. IIUC currently its passed via a file which is a problem Having an encrypted TPM state and an unencrypted file containing the decryption key alongside is no better than just having an unencrypted TPM state. We need to be able to pass the key to swtpm without it hitting disk.

The easiest answer is to have a way to pass down a pre-opened file descriptor for the read end of the pipe to swtpm. Libvirt can then write the key to this pipe.

> - Encryption of the vTPM state must be added when a vTPM's XML is created. > It's not possible to convert existing not-encrypted vTPM state to encrypted > vTPM state. This is due to a limitation of 'swtpm.' I dont see a problem here. Same situation with disk encryption. > - vTPM state encryption would be based on libvirt's Secret support. I assume > the secrets can migrate along the domain XML. Yes, it should use the virSecret object framework. It is the mgmt app's responsibiltiy to ensure any required secret is present on the target host before starting the migration. We don't try to copy the secret objects across automatically. > - The XML for vTPM state encryption is similar to XML used for 'luks': > https://libvirt.org/formatstorageencryption.html#example > > - The XML for an encrypted vTPM state could look like this: > >   <devices> >     [...] >     <tpm model='tpm-tis'> >       <backend type='emulator' version='2.0'> >         <encryption format='vtpm'> >             <secret type='passphrase' > uuid='32ee7e76-2178-47a1-ab7b-269e6e348015'/> >         </encryption> >       </backend> >     </tpm> >   </devices> Yep, this makes sense. > Here the user is referencing an already existing Secret. This secret would > NOT be automatically undefined when a VM is undefined. > > - Another possibility may be this XML here: > >   <devices> >     [...] >     <tpm model='tpm-tis'> >       <backend type='emulator' version='2.0'> >         <encryption format='default'/> >       </backend> >     </tpm> >   </devices> > > In this case the Secret would be automatically generated and this domain XML > be rewritten to look like the one in the first example. The domain XML would > then reference the created secret via usage=vtpm-<vmuuid>, which would be an > indication that this secret can be deleted when the VM is undefined. Historically we've not tried to do anything clever with automatically creating & deleting secrets. Left that policy upto the mgmt app. I'm particularly wary of automatically deleting secrets as that could leave the data inaccessible.

'virsh undefine' has itself though implemented logic for deleting extra resources associated with a guest. eg deleting disks. > - The Secret XML to be passed to virsh secret-define would look like this: > >       <secret ephemeral='no' private='yes'> >          <description>vTPM passphrase example</description> >          <usage type='vtpm'> >             <name>vtpm_example</name> >          </usage> >       </secret> Mgmt apps will likely want different values for ephemeral= and private= attributes to more tightly restrict access, but the <usage> is fine. Regards, Daniel