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

[Dr. David Alan Gilbert]

* Daniel P. Berrange (address@hidden) wrote:
> On Tue, May 02, 2017 at 03:35:48PM -0400, Stefan Berger wrote:
> > On 05/02/2017 02:50 PM, Marc-André Lureau wrote:
> > > Hi
> > > 
> > > On Tue, May 2, 2017 at 10:25 PM Patrick Ohly <address@hidden
> > > <mailto:address@hidden>> 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
> > >     <address@hidden <mailto:address@hidden>>
> > >     > > 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.
> > 
> > The intention would be to use it for RunC as well (plus higher layers
> > afterwards): https://github.com/opencontainers/runc/pull/1082
> > 
> > > 
> > > But it's mostly a technical reason, to avoid having to rely on a foreign
> > > protocol and project with all the compatibility constrains.
> > 
> > I understand. Ideally swtpm-0.1 would be equivalent to 1.0 with all features
> > available and no further protocol extensions necessary. In practice that may
> > look different.
> > 
> > > 
> > > 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...
> > 
> > libtpms combines a few source codes with some glue around it. The coding
> > style is different for TPM 1.2 and TPM 2 code for example and the code bases
> > are in the 10s of thousands of line. In the case of TPM 2 it 'lives from'
> > TCG code drops and thus there is no reformatting of source code etc.
> > 
> > If someone wants to get started on qemu-swtpm that's certainly cool but over
> > the years it's just been quite difficult to find developers for it to share
> > the burden. All that said, someone should state whether this series is a go
> > or no-go because of the external project it requires.
> 
> I think it is *good* that it uses the external swtpm project and do not
> want to see it reimplemented inside QEMU, particularly with the interest
> for swtpm to be used in container contexts via RunC. Such common 
> infrastructure
> for both containers & QEMU will be important given the increasing convergance
> of technology across containers & VMs.

I agree; there aren't that many people who understand the details of TPMs,
reimplementing one in QEMU isn't something you'd want to do.

Dave

> 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 :|
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK