[libvirt] Encrypted vTPM state

[Stefan Berger]

On 6/27/19 12:25 PM, Daniel P. Berrangé wrote:
> 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.

Besides persisting the key for as long as the Secret exists but with 
different DAC rights, I suppose.


> 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.

I just added this to swtpm. Now we can pass keys or passwords from which 
they are dervied via fd.


>
>> - 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.


I would scratch this then. I thought it would make it easier for higher 
layers that don't want to do secrets management.

'

>
> '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


Thanks


   Stefan.