Re: [PATCH 2/2] tpm: add backend for mssim

[Stefan Berger]

On 12/15/22 14:40, James Bottomley wrote:
> On Thu, 2022-12-15 at 14:35 -0500, Stefan Berger wrote:
> > On 12/15/22 14:22, James Bottomley wrote:
> > > On Thu, 2022-12-15 at 13:46 -0500, Stefan Berger wrote:
> > > > On 12/15/22 13:01, James Bottomley wrote:
> > > > > From: James Bottomley <James.Bottomley@HansenPartnership.com>
> > > > >
> > > > > 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.
> > > > >
> > > > > The implementation does basic control commands like power
> > > > > off/on,
> > > > > but
> > > > > doesn't implement cancellation or startup.  The former because
> > > > > cancellation is pretty much useless on a fast operating TPM
> > > > > emulator
> > > > > and the latter because this emulator is designed to be used
> > > > > with
> > > > > OVMF
> > > > > which itself does TPM startup and I wanted to validate that.
> > > > >
> > > > > To run this, simply download an emulator based on the MS
> > > > > specification
> > > > > (package ibmswtpm2 on openSUSE) and run it, then add these two
> > > > > lines
> > > > > to the qemu command and it will use the emulator.
> > > > >
> > > > >        -tpmdev mssim,id=tpm0 \
> > > > >        -device tpm-crb,tpmdev=tpm0 \
> > > > >
> > > > > to use a remote emulator replace the first line with
> > > > >
> > > > >        -tpmdev
> > > > > "{'type':'mssim','id':'tpm0','command':{'type':inet,'host':'rem
> > > > > ote'
> > > > > ,'port':'2321'}}"
> > > > >
> > > > > tpm-tis also works as the backend.
> > > >
> > > > Since this device does not properly support migration you have to
> > > > register a migration blocker.
> > >
> > > Actually it seems to support migration just fine.  Currently the
> > > PCR's
> > > get zero'd which is my fault for doing a TPM power off/on, but
> > > switching that based on state should be an easy fix.
> >
> > How do you handle virsh save  -> host reboot -> virsh restore?
>
> I didn't.  I just pulled out the TPM power state changes and followed
> the guide here using the migrate "exec:gzip -c > STATEFILE.gz" recipe:
>
> https://www.linux-kvm.org/page/Migration
>
> and verified the TPM pcrs and the null name were unchanged.

> > You should also add a description to docs/specs/tpm.rst.
>
> Description of what?  It functions exactly like passthrough on

Please describe all the scenarios so that someone else can repeat them when 
trying out **your** device.

There are sections describing how things for swtpm and you should add how 
things work for the mssim TPM.

https://github.com/qemu/qemu/blob/master/docs/specs/tpm.rst#the-qemu-tpm-emulator-device
https://github.com/qemu/qemu/blob/master/docs/specs/tpm.rst#migration-with-the-tpm-emulator


> migration.  Since the TPM state is retained in the server a
> reconnection just brings everything back to where it was.

So it's remote. And the ports are always open and someone can just connect to 
the open ports and power cycle the device?

This may not be the most important scenario but nevertheless I wouldn't want to 
deal with bug reports if someone does 'VM snapshotting' -- how this is 
correctly handled would be of interest.

   Stefan

> James