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.