James Bottomley <j...@linux.ibm.com> writes: > On Fri, 2023-09-22 at 08:00 +0200, Markus Armbruster wrote: >> Found this cleaning out old mail, sorry for missing it until now! >> >> I think we owe James a quick decision wether we're willing to take >> the >> feature. Stefan, thoughts? >> >> James Bottomley <j...@linux.ibm.com> writes: >> >> > From: James Bottomley <james.bottom...@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 based 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 two sockets to be >> > specified on the 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':'remote' >> > ,'port':'2321'}}" >> > >> > tpm-tis also works as the backend. >> > >> > Signed-off-by: James Bottomley <j...@linux.ibm.com> >> >> [...] >> >> > diff --git a/docs/specs/tpm.rst b/docs/specs/tpm.rst >> > index 535912a92b..1398735956 100644 >> > --- a/docs/specs/tpm.rst >> > +++ b/docs/specs/tpm.rst >> > @@ -270,6 +270,38 @@ available as a module (assuming a TPM 2 is >> > passed through): >> > /sys/devices/LNXSYSTEM:00/LNXSYBUS:00/MSFT0101:00/tpm/tpm0/pcr- >> > sha256/9 >> > ... >> > >> > +The QEMU TPM Microsoft Simulator Device >> > +--------------------------------------- >> > + >> > +The TCG provides a reference implementation for TPM 2.0 written by >> >> >> Suggest to copy the cover letter's nice introductory paragraph here: >> >> The Microsoft Simulator (mssim) is the reference emulation platform >> for the TCG TPM 2.0 specification. >> >> It provides a reference implementation for TPM 2.0 written by > > Sure, that's easy. > >> > +Microsoft (See `ms-tpm-20-ref`_ on github). The reference >> > implementation >> > +starts a network server and listens for TPM commands on port 2321 >> > and >> > +TPM Platform control commands on port 2322, although these can be >> > +altered. The QEMU mssim TPM backend talks to this >> > implementation. By >> > +default it connects to the default ports on localhost: >> > + >> > +.. code-block:: console >> > + >> > + qemu-system-x86_64 <qemu-options> \ >> > + -tpmdev mssim,id=tpm0 \ >> > + -device tpm-crb,tpmdev=tpm0 >> > + >> > + >> > +Although it can also communicate with a remote host, which must be >> > +specified as a SocketAddress via json on the command line for each >> > of >> >> Is the "via JSON" part in "must be specified ... on the command line" >> correct? I'd expect to be able to use dotted keys as well, like >> >> -tpmdev >> type=mssim,id=tpm0,command.type=inet,command.host=remote,command.port >> =2321',control.type=inet,control.host=remote,control.port=2322 > > Yes, I've verified that the dot notation works as well. However, I > thought QEMU was calling all stuff like this JSON notation? If not, > what do you usually call it? "json or dot notation"?
Our terminology is a bit fuzzy there. We commonly say "dotted keys" (although that's just the part left of the = strictly speaking) or "key=value,...". >> Aside: I do recommend management applications stick to JSON. [...]
