Re: [PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device

On Tue, May 12, 2020 at 01:29:43PM -0300, Daniel Henrique Barboza wrote: > > > On 5/11/20 8:50 AM, Daniel Henrique Barboza wrote: > > > > > > On 5/11/20 8:28 AM, Daniel P. Berrangé wrote: > > > On Mon, May 11, 2020 at 08:26:53AM -0300, Daniel Henrique Barboza wrote: > > > > > > > > > > > > On 5/11/20 6:57 AM, Daniel P. Berrangé wrote: > > > > > On Mon, May 11, 2020 at 11:22:57AM +1000, David Gibson wrote: > > > > [...] > [...] > > > > > > Currently libvirt only allows a single <tpm>, but we can trivially > > > lift that restriction to allow multiple if desired too. > > > > I don't believe it'll be necessary. Since it's only this TPM Proxy device that > > can coexist with other TPMs, my idea is to do what I did here in this series, > > but instead of creating a new device type I'll re-use the existing TPM device > > in a 'tpmproxy' pointer in the domain for this case. > > > > I'll still thinking about whether a new backend type is warranted or not. For > > this PPC64 case alone it'll be simpler to just add a new 'model' called > > 'spapr-tpm'-proxy' for the existing TPM passthrough type. Creating a new > > backend type makes it easier to add other TPM Proxy devices when other archs > > implement it though. > > Update: I tried it out the new "backend" approach and didn't enjoy the results. > It ended up replicating a large amount of existing cgroup/dac/selinux code that > handles the existing "passthrough" backend and, all said and done, it didn't alleviate > that much the parsing/format XML logic comparing to the alternative. > > I chose then to go to the simpler route - adding a new 'passthrough' model called > 'spapr-tpm-proxy'. This will not scale well if/when more TPM proxies devices are > added in the future, but we can cross that bridge when we come to > it. TBH, I think that's unlikely to happen. The TPM proxy exists because of the design of POWER's secure VM model, and because it was easy to add an hcall to PAPR for this, without thinking how it would integrate with other TPM devices or PAPR's existing / concurrently designed vTPM interface. I don't think there's any general reason you'd want a device like this, distinct from just a vTPM.