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

[Dr. David Alan Gilbert]

* Daniel P. Berrange (address@hidden) wrote:
> On Wed, Mar 01, 2017 at 06:22:45PM +0200, Michael S. Tsirkin wrote:
> > On Wed, Mar 01, 2017 at 09:50:38AM -0500, Stefan Berger wrote:
> > > I had already proposed a linked-in version before I went to the 
> > > out-of-process
> > > design. Anthony's concerns back then were related to the code not being 
> > > trusted
> > > and a segfault in the code could bring down all of QEMU. That we have test
> > > suites running over it didn't work as an argument. Some of the test suite 
> > > are
> > > private, though.
> > 
> > Given how bad the alternative is maybe we should go back to that one.
> > Same argument can be made for any device and we aren't making
> > them out of process right now.
> > 
> > IIMO it's less the in-process question (modularization
> > of QEMU has been on the agenda since years and I don't
> > think anyone is against it) it's more a code control/community question.
> 
> I rather disagree. Modularization of QEMU has seen few results
> because it is generally a hard problem to solve when you have a
> complex pre-existing codebase.  I don't think code control has
> been a factor in this - as long as QEMU can clearly define its
> ABI/API between core & the modular pieces, it doesn't matter
> who owns the module. We've seen this with vhost-user which is
> essentially outsourcing network device backend impls to a 3rd
> party project. QEMU's defined the vhost-user ABI/API and delegated
> impl to something else.
> 
> With the vTPM stuff here, we've not got a pre-existing feature
> we need to deal with, so the biggest blocker wrt modularization does
> not exist. Given that I think having the vTPM impl modularized is
> highly desirable, as long as we can define a sane ABI/API between
> QEMU and the external piece.  So I think anthony's point about not
> putting a vTPM impl in-process is still valid, and since Stefan's
> already done much of the work to achieve a modular design we should
> not go back to an in-process design now.

Yes, I agree.  Also it means there's potential to do things like only
allow the vTPM process to access the underlying key storage using SELinux.

Dave

> > It doesn't look like userspace swtpm bits have a large community of
> > developers around it, and the only user appears to be QEMU, so depending
> > on that externally does not make sense, we should just have them
> > in-tree. This way we don't need to worry about versioning etc.
> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK