qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v5 1/4] Provide support for the CUSE TPM
Date: Thu, 2 Mar 2017 00:22:54 +0200

On Wed, Mar 01, 2017 at 06:56:17PM +0000, Daniel P. Berrange wrote:
> On Wed, Mar 01, 2017 at 06:32:19PM +0000, Marc-André Lureau wrote:
> > Hi
> > 
> > On Wed, Mar 1, 2017 at 10:20 PM Michael S. Tsirkin <address@hidden> wrote:
> > 
> > >
> > > > You're also tieing the code
> > > > into the QEMU release cycle, again for no tangible benefit.
> > >
> > > No need for ABI stability would be the benefit.
> > >
> > 
> > We are talking about the control channel ABI (the data channel is using TCG
> > defined command streams afaict - don't remember what it is called)
> > 
> > 
> > >
> > > > Conceptually
> > > > swtpm does not depend on, or require, QEMU to be useful - it can have
> > > > other non-QEMU consumers - bundling with QEMU is not helpful there.
> > >
> > > Maybe it could but it isn't.
> > >
> > 
> > Right, it would be reasonable to have qemu provide it's own private "swtpm"
> > (linking with libtpms, doing most of the job), that way it wouldn't have to
> > rely on a stable ABI (as long as the process isn't shared across different
> > qemu versions, which should be quite easy to achieve)
> 
> I think we need to expect to have a stable ABI no matter what. During
> upgrade cycles, it is desirable to be able to upgrade the swtpm process
> assocatied with a running VM.

Why? It should be part of the same rpm as QEMU,
upgrading QEMU requires VM restart and so should this.

We really really do not want a stable ABI if we can get
away with not having one.

> Whether this is done by restarting the
> process & having QEMU reconnect, or by re-exec'ing swtpm and keeping the
> FD open, you still end up with newer swtpm talking to an older QEMU. Or
> conversely you might have setup swtpm processes to populate a number of
> CUSE devices, and then later launch QEMU binaries to connect to them - at
> which point there's no guarantee the QEMU version hasn't been upgraded -
> or the user could have requested a custom QEMU binary to virt-install,
> etc.

Sounds like feature creep to me. A separate processes for parts of QEMU
for extra security make sense. Stable ABI between parts does not.

> 
> 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/ :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]