Re: [PATCH] tpm: add backend for mssim

[Daniel P . Berrangé]

On Mon, Dec 12, 2022 at 05:02:43PM -0500, Stefan Berger wrote:
> 
> 
> On 12/12/22 16:36, James Bottomley wrote:
> > On Mon, 2022-12-12 at 14:32 -0500, Stefan Berger wrote:
> > > 
> > > 
> > > On 12/12/22 14:12, James Bottomley wrote:
> > > > On Mon, 2022-12-12 at 13:58 -0500, Stefan Berger wrote:
> > > > > On 12/12/22 13:48, James Bottomley wrote:
> > > > > > On Mon, 2022-12-12 at 11:59 -0500, Stefan Berger wrote:
> > > > > > > On 12/12/22 11:38, James Bottomley wrote:
> > > > [...]
> > > > > > > > the kernel use of the TPM, but I'm trying to fix that.  The
> > > > > > > > standard mssim server is too simplistic to do transport
> > > > > > > > layer
> > > > > > > > security, but like everything that does this (or rather
> > > > > > > > doesn't
> > > > > > > > do this), you can front it with stunnel4.
> > > > > > > 
> > > > > > > And who or what is going to set this up?
> > > > > > 
> > > > > > I'm not sure I understand the question.  Stunnel4 is mostly
> > > > > > used to
> > > > > > convert unencrypted proxies like imap on 143 or smtp on 25 to
> > > > > > the
> > > > > > secure version.  Most people who run servers are fairly
> > > > > > familiar
> > > > > > with using it.  It's what IBM used for encrypted migration
> > > > > > initially.  You can run stunnel on both ends, or the qemu side
> > > > > > could be built in using the qemu tls-creds way of doing things
> > > > > > but
> > > > > > anything running the standard MS server would have to front it
> > > > > > with
> > > > > > stunnel still.
> > > > > 
> > > > > So it's up to libvirt to setup stunnel to support a completely
> > > > > different setup than what it has for swtpm already?
> > > > 
> > > > I don't think so, no.  Libvirt doesn't usually help with server
> > > > setup (witness the complexity of setting up a server side vtpm
> > > > proxy) so in the case tls-creds were built in, it would just work
> > > > if the object is
> > > 
> > > I see, so you are extending the TPM emulator with TLS on the client
> > > side so you don't need another tool to setup a TLS connection from
> > > the QEMU/client side.
> > 
> > I didn't say I would do this, just that it's an easy possibility with
> > the current qemu framework.  I actually need to fiddle with the TPM
> > externally to do some of my testing (like platform reset injection) so
> > I won't use TLS anyway.
> > 
> > > Is the server side across the network or on the same host?
> > 
> > It can be either.
> 
> For the remote TPM you'll need some sort of management stack (who
> is building this?) that does the port assignments (allocations and
> freeing, starting of TPM instances etc) for the possibly many TPMs
> you would run on a remote machine and then create the libvirt XML
> or QEMU command line with the port assignments. I am not sure I
> see the advantage of this versus what we have at the moment with a
> single management stack . Also, if you did this you'd have a single
> point of failure for many VMs whose TPM is presumably running on
> some dedicated machine(s).

IMHO this is largely tangential. Remote access is technically possible,
but local access is likely the common case. It isn't neccessary to
solve the full remote mgmt solution as a pre-condition for this
proposed patch.

All that matters is whether it is valuable to have the mssim backend
in QEMU. I think the benefit is weak when considering a full virt
mgmt stack like OpenStack/KubeVirt, as swtpm basically solves
everything people need to commonly do AFAICT.

None the less, I can understand why it is desirable to have the option
be able to run against the TPM reference implementation, for the sake
of testing behavioural compliance.

It is a shame there isn't a standardized protocol for software TPM
communication, as that'd avoid the need for multiple backends.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|