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

[Marc-André Lureau]

Hi

On Wed, Mar 1, 2017 at 6:50 PM Stefan Berger <address@hidden>
wrote:

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

"Daniel P. Berrange" <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) 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.


Could the data channel be muxed in with the control channel? )that is only
use one control socket)

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.


I think Anthony argument is valid for anything running in qemu :) So I
don't see why TPM would be an exception now.

Could you say how much is covered by the public test suite?

About tests, is there any test for qemu TIS?


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/stefanbergToo bader/qemu-tpm/tree/v2.8.0+tpm
<https://github.com/stefanberger/qemu-tpm/tree/v2.8.0+tpm>



Some people may want to use simulated TPM with qemu without the need for
security, just to do development/testing.

Dealing with external processes makes also qemu development and testing
more difficult.

Changing the IPC interface is more complicated  than having linked in
solution. Testing is easier if you can just start/kill one qemu process.

I can't say if it's really needed to ease progress, but at least it would
avoid that CUSE/IPC discussion for now.

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.


Ok, I think it would be worth to list all the up to date trees in
http://www.qemu-project.org/Features/TPM (btw, that page is 5y old, would
be nice if you could refresh it, I bet some changed happened)


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


If there is no strong argument for CUSE, I would go without it

(I'd also suggest a similar approach to vhost-user backend I proposed in
http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg01014.html,
it spawns a backend and pass an extra socketpair fd to it)

   Stefan



thanks


-- 
Marc-André Lureau


-- 
Marc-André Lureau