Re: [Qemu-devel] [PATCH v3 8/8] tpm: Added support for TPM emulator - Marc-André Lureau

From: "Marc-André Lureau" <marcandre.lureau@gmail.com>
To: Patrick Ohly <patrick.ohly@intel.com>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>
Cc: Amarnath Valluri <amarnath.valluri@intel.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v3 8/8] tpm: Added support for TPM emulator
Date: Tue, 02 May 2017 18:50:18 +0000	[thread overview]
Message-ID: <CAJ+F1CK4jN2Nb6eKB1x9Km0xnurs976=Kb0idFpPgtH+JHYTcQ@mail.gmail.com> (raw)
In-Reply-To: <1493749518.4241.225.camel@intel.com>

Hi

On Tue, May 2, 2017 at 10:25 PM Patrick Ohly <patrick.ohly@intel.com> wrote:

> On Tue, 2017-05-02 at 13:19 -0400, Stefan Berger wrote:
> > On 05/02/2017 01:09 PM, Marc-André Lureau wrote:
> > > On Tue, May 2, 2017 at 8:59 PM Stefan Berger <
> stefanb@linux.vnet.ibm.com>
> > > wrote:
> > >
> > >> And who is going to implement that qemu-swtpm? Obviously this
> discussion
> > >> doesn't contribute to progress if nobody is doing that in the end.
> > >>
> > > The same persons who try to push for that emulated TPM code. The
> easiest
> > > approach would be to copy/adapt the swtpm code in qemu, if the licence
> is
> > > compatible. I can help with that if there is a consensus it's a better
> > > approach.
> >
> >
> > It's a matter of time and at least I don't have time for that.
>
> Neither do I, and nor (I believe) does Amarnath. The approach with using
> the existing swtpm project seemed attractive to us exactly because it
> avoids having to write and maintain more than just the glue code between
> the two projects.
>

The main argument is not about having more or less code in qemu to
maintain, but yes this is a concern (although giving up that maintenance to
a seperate project with mostly Stefan-alone isn't a much better
alternative). btw, is the project actually used by something else than
qemu? (I am not talking about developpers/testing). If not, then it makes
sense to make it part of qemu.

But it's mostly a technical reason, to avoid having to rely on a foreign
protocol and project with all the compatibility constrains.

In the end, we may decide to start with a separate project, and change it
in the future if it's problematic (that would break some cases, such as
being able to freely switch the helper). Tbh, I am not so happy with the
code quality of swtpm, and I haven't looked closely at libtpms. Having a
qemu-swtpm as part of qemu would probably help improve it too, and bring a
few more developers for maintainance...

-- 
Marc-André Lureau