Re: [PATCH] tpm: add backend for mssim

[Stefan Berger]

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

> >   Either way, what is the latency that this introduces because I would
> > expect that this slows down IMA since the PCR extensions & TPM 2
> > response now go back and forth across the network?
>
> Most data centre protocols are now encrypted and networked (NVMeoF
> would probably be the poster child) with no real ill effects.  In terms
> of a TPM, the competition is an underpowered discrete chip over a slow
> serial bus, so I think we'll actually improve the latency not diminish
> it.

Compared to QEMU and swtpm talking over a local socket you probably have a 
decent amount of slow-down if this is over the network.
I still fail to see the advantage over what we have at the moment. Also I don't 
see what advantage the mssim protocol brings over what swtpm provides. If you 
are willing to do a 'dnf -y install swtpm_setup' and start the VM via libvirt 
it really doesn't matter what protocol the TPM is running underneath since it's 
all transparent.

   Stefan

> James