On 03/01/2017 10:24 AM, Marc-André Lureau wrote:
Hi
On Wed, Mar 1, 2017 at 6:50 PM Stefan Berger
<stef...@linux.vnet.ibm.com <mailto:stef...@linux.vnet.ibm.com>> wrote:
On 03/01/2017 09:17 AM, Marc-André Lureau wrote:
Hi
On Wed, Mar 1, 2017 at 5:26 PM Stefan Berger <stef...@us.ibm.com
<mailto:stef...@us.ibm.com>> wrote:
"Daniel P. Berrange" <berra...@redhat.com
<mailto:berra...@redhat.com>> 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 (stef...@linux.vnet.ibm.com
<mailto:stef...@linux.vnet.ibm.com>) 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)
You could run the data channel as part of the control channel or vice
versa. I think the problem is that TCG hasn't defined anything in this
area and two people in different rooms will come up with two different
designs.
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?
I don't know anything in terms of percentage of code coverage. But I
think in terms of coverage of commands of a TPM 1.2 we were probably
>95%. Now there's also TPM 2 and for that I don't know.
About tests, is there any test for qemu TIS?
For the TIS I had some very limited tests in SeaBIOS, which of course
are not upstreamed. Though the primary goal there was to test live
migration while doing PCR Extends.
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
Some people may want to use simulated TPM with qemu without the need
for security, just to do development/testing.
For that they have a solution with the above tree and the swtpm and
libtpms projects.
Dealing with external processes makes also qemu development and
testing more difficult.
Well, internal didn't fly previously.
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)
