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

[Marc-André Lureau]

Hi

On Wed, May 3, 2017 at 3:29 PM Daniel P. Berrange <address@hidden>
wrote:

> On Wed, May 03, 2017 at 11:24:42AM +0000, Marc-André Lureau wrote:
> > Hi
> >
> > On Wed, May 3, 2017 at 3:17 PM Dr. David Alan Gilbert <
> address@hidden>
> > wrote:
> >
> > > * 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.
> > >
> >
> > It's not about reimplementing TPM emulation. swtpm is a small utility
> > talking to libtpms doing the heavy work. swtpm could quite easily be
> > copied/adapted to fit in qemu if it's only meant to be used by qemu.
> > However, it seems the helper is going to be used by other projects, so it
> > make sense to make it a seperate project. Nevertheless, I think we should
> > carefully review the protocol and the compatibility situation before
> > committing this work, it's a major burden ahead..
>
> Yes, I agree that reviewing the protocol is a very neccessary step, to
> ensure it is going to be forwards compatible in a manner suitable for
> QEMU.
>
> In particular we need to understand what, if any, relationship there
> needs to be wrt machine types & live migration stability. eg if a
> VM is booted and the protocol negotiates version X, and we then live
> migrate to a host with a newer swtpm, we need to ensure that the
> protocol doesn't negotiate something that leads to guest OS incompatiblity
> problems in accessing the TPM.
>
>
Not only the protocol, but the management aspect of this helper too. See
the commit message for instance for the preparatory swtpm steps and
arguments.

If it would be part of qemu, there are more chances we could make it speak
qmp for instance, which would likely help in the future.


> basically similar scenario to that which we have had with vhost-user
> and version compatibility with external vhost-user server implementations
> across live migration.
>
>
Yes, this is already quite painful and not very well tested, I would rather
avoid this situation even at the cost of small code duplication...
-- 
Marc-André Lureau