On 05/02/2017 02:50 PM, Marc-André Lureau wrote:
Hi
On Tue, May 2, 2017 at 10:25 PM Patrick Ohly <patrick.o...@intel.com
<mailto:patrick.o...@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
<stef...@linux.vnet.ibm.com <mailto:stef...@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.
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.
