Re: [Qemu-devel] [PATCH v5 1/4] Provide support for the CUSE TPM

[Daniel P. Berrange]

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" <address@hidden> 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.

Ok, the security separation concern does make some sense. The use of CUSE
still seems fairly questionable to me. CUSE makes sense if you want to
provide a drop-in replacement for the kernel TPM device driver, which
would avoid ned for a new QEMU backend. If you're not emulating an existing
kernel driver ABI though, CUSE + ioctl is feels like a really awful RPC
transport between 2 userspace processes.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|