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

[Stefan Berger]

On 03/01/2017 09:17 AM, Marc-André Lureau wrote:
> Hi
>
> On Wed, Mar 1, 2017 at 5:26 PM Stefan Berger <address@hidden 
> <mailto:address@hidden>> wrote:
>
>     "Daniel P. Berrange" <address@hidden
>     <mailto:address@hidden>> wrote on 03/01/2017 07:54:14
>     AM:
>     >
>     > On Wed, Mar 01, 2017 at 07:25:28AM -0500, Stefan Berger wrote:
>     > > On 06/16/2016 04:25 AM, Daniel P. Berrange wrote:
>     > > > On Thu, Jun 16, 2016 at 09:05:20AM +0100, Dr. David Alan Gilbert
>     wrote:
>     > > > > * Stefan Berger (address@hidden
>     <mailto:address@hidden>) wrote:
>     > > > > > On 06/15/2016 03:30 PM, Dr. David Alan Gilbert wrote:
>     > > > > <snip>
>     > > > >
>     > > > > > > So what was the multi-instance vTPM proxy driver patch set
>     about?
>     > > > > > That's for containers.
>     > > > > Why have the two mechanisms? Can you explain how the
>     multi-instance
>     > > > > proxy works; my brief reading when I saw your patch series
>     seemed
>     > > > > to suggest it could be used instead of CUSE for the
>     non-container
>     case.
>     > > > One of the key things that was/is not appealing about this CUSE
>     approach
>     > > > is that it basically invents a new ioctl() mechanism for
>     talking to
>     > > > a TPM chardev. With in-kernel vTPM support, QEMU probably
>     doesn't
>     need
>     > > > to have any changes at all - its existing driver for talking
>     to TPM
>     > >
>     > > We still need the control channel with the vTPM to reset it
>     upon VM
>     reset,
>     > > for getting and setting the state of the vTPM upon
>     snapshot/suspend/resume,
>     > > changing locality, etc.
>     >
>     > You ultimately need the same mechanisms if using in-kernel vTPM with
>     > containers as containers can support snapshot/suspend/resume/etc
>     too.
>
>     The vTPM running on the backend side of the vTPM proxy driver is
>     essentially the same as the CUSE TPM used for QEMU. I has the same
>     control
>     channel through sockets. So on that level we would have support
>     for the
>     operations but not integrated with anything that would support
>     container
>     migration.
>
>
> Ah that might explain why you added the socket control channel, but 
> there is no user yet? (or some private product perhaps). Could you 
> tell if control and data channels need to be synchronized in any ways?


In the general case, synchronization would have to happen, yes. So a 
lock that is held while the TPM processes data would have to lock out 
control channel commands that operate on the TPM data. That may be 
missing. In case of QEMU being the client, not much concurrency would be 
expected there just by the way QEMU interacts with it.

A detail: A corner case is live-migration with the TPM emulation being 
busy processing a command, like creation of a key. In that case QEMU 
would keep on running and only start streaming device state to the 
recipient side after the TPM command processing finishes and has 
returned the result. QEMU wouldn't want to get stuck in a lock between 
data and control channel, so would have other means of determining when 
the backend processing is done.

> Getting back to the original out-of-process design: qemu links with 
> many libraries already, perhaps a less controversial approach would be 
> to have a linked in solution before proposing out-of-process? This 
> would be easier to deal with for

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.

> management layers etc. This wouldn't be the most robust solution, but 
> could get us somewhere at least for easier testing and development.

Hm. In terms of external process it's basically 'there', so I don't 
related to the 'easier testing and development.' The various versions 
with QEMU + CUSE TPM driver patches applied are here.

https://github.com/stefanberger/qemu-tpm/tree/v2.8.0+tpm

I have an older version of libvirt that has the necessary patches 
applied to start QEMU with the external TPM. There's also virt-manager 
support.

If CUSE is the wrong interface, then there's a discussion about this 
here. Alternatively UnixIO for data and control channel could be used.

https://github.com/stefanberger/swtpm/issues/4

   Stefan


> thanks
>
>
> --
> Marc-André Lureau