"Michael S. Tsirkin" <m...@redhat.com> wrote on 01/20/2016 11:03:11 AM:
> From: "Michael S. Tsirkin" <m...@redhat.com> > Subject: Re: [Qemu-devel] [PATCH v5 1/4] Provide support for the CUSE TPM > > On Wed, Jan 20, 2016 at 10:54:47AM -0500, Stefan Berger wrote: > > On 01/20/2016 10:46 AM, Daniel P. Berrange wrote: > > >On Wed, Jan 20, 2016 at 10:31:56AM -0500, Stefan Berger wrote: > > >>"Daniel P. Berrange" <berra...@redhat.com> wrote on 01/20/2016 10:00:41 > > >>AM: > > >> > > >> > > >>>process at all - it would make sense if there was a single > > >>>swtpm_cuse shared across all QEMU's, but if there's one per > > >>>QEMU device, it feels like it'd be much simpler to just have > > >>>the functionality linked in QEMU. That avoids the problem > > >>I tried having it linked in QEMU before. It was basically rejected. > > >I remember an impl you did many years(?) ago now, but don't recall > > >the results of the discussion. Can you elaborate on why it was > > >rejected as an approach ? It just doesn't make much sense to me > > >to have to create an external daemon, a CUSE device and comms > > >protocol, simply to be able to read/write a plain file containing > > >the TPM state. Its massive over engineering IMHO and adding way > > >more complexity and thus scope for failure > > > > The TPM 1.2 implementation adds 10s of thousands of lines of code.The TPM 2 > > implementation is in the same range. The concern was having this code right > > in the QEMU address space. It's big, it can have bugs, so we don't want it > > to harm QEMU. So we now put this into an external process implemented by the > > swtpm project that builds on libtpms which provides TPM 1.2 functionality > > (to be extended with TPM 2). We cannot call APIs of libtpms directly > > anymore, so we need a control channel, which is implemented through ioctls > > on the CUSE device. > > > > Stefan > > If that's the only reason for it, you can package it as part of QEMU > source, run it as a sub-process. I am packaging libtpms in Fedora. Once we have the CUSE interface in QEMU, I would package the swtpm project for Fedora as well. Both projects have at least been prepared for Debian packaging also. https://github.com/stefanberger/libtpms https://github.com/stefanberger/swtpm The 'dist' directory has the spec file. If I would combine things, then on the libvirt layer. Introduce an RPM dependency there. I doubt I will have the possibility to go back to integrating it directly into QEMU directly. Regards, Stefan
