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

[David Gibson]

On Wed, May 13, 2020 at 10:06:23AM +1000, David Gibson wrote:
> 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.

Indeed, arguably, this would be better modelled by just some sort of
machine or firmware feature flag, rather than a "device" as such.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200513/22480d15/attachment-0001.sig>