Re: [PATCH] tpm: add backend for mssim

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Dec 12, 2022 at 01:58:29PM -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:
> > > > On Mon, 2022-12-12 at 15:47 +0000, Daniel P. Berrangé wrote:
> > > > > Copy'ing Markus for QAPI design feedback.
> > > > > 
> > > > > On Sat, Dec 10, 2022 at 12:10:18PM -0500, James Bottomley wrote:
> > > > > > The Microsoft Simulator (mssim) is the reference emulation
> > > > > > platform for the TCG TPM 2.0 specification.
> > > > > > 
> > > > > > https://github.com/Microsoft/ms-tpm-20-ref.git
> > > > > > 
> > > > > > It exports a fairly simple network socket baset protocol on two
> > > > > > sockets, one for command (default 2321) and one for control
> > > > > > (default 2322).  This patch adds a simple backend that can
> > > > > > speak the mssim protocol over the network.  It also allows the
> > > > > > host, and two ports to be specified on the qemu command line.
> > > > > > The benefits are twofold: firstly it gives us a backend that
> > > > > > actually speaks a standard TPM emulation protocol instead of
> > > > > > the linux specific TPM driver format of the current emulated
> > > > > > TPM backend and secondly, using the microsoft protocol, the end
> > > > > > point of the emulator can be anywhere on the network,
> > > > > > facilitating the cloud use case where a central TPM service can
> > > > > > be used over a control network.
> > > > > 
> > > > > What's the story with security for this ?  The patch isn't using
> > > > > TLS, so talking to any emulator over anything other than
> > > > > localhost looks insecure, unless I'm missing something.
> > > > 
> > > > Pretty much every TPM application fears interposers and should thus
> > > > be using the TPM transport security anyway. *If* this is the case,
> > > > then the transport is secure.  Note that this currently isn't the
> > > > case for
> > > 
> > > What about all the older kernels that are out there?
> > 
> > No current kernel uses transport security.  In the event the patch
> > eventually gets upstream, the kernel be secure against interposer
> > attacks going forwards.  I would imagine there might be pressure to
> > backport the patch given the current level of worry about interposers.
> > 
> > > > 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?

Well technically libvirt doesn't have todo anything. We are free
to decide to only support locally hosted mssim deployments, and
declare that off node access is unsupported and warn it is
potentially insecure .

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