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: Wed, 20 Jan 2016 20:54:47 +0200

On Wed, Jan 20, 2016 at 11:06:45AM -0500, Stefan Berger wrote:
> "Michael S. Tsirkin" <address@hidden> wrote on 01/20/2016 10:58:02 AM:
> 
> > From: "Michael S. Tsirkin" <address@hidden>
> 
> >
> > On Wed, Jan 20, 2016 at 10:36:41AM -0500, Stefan Berger wrote:
> > > "Michael S. Tsirkin" <address@hidden> wrote on 01/20/2016 10:20:58 AM:
> > >
> > > > From: "Michael S. Tsirkin" <address@hidden>
> > >
> > > > >
> > > > > The CUSE TPM and associated tools can be found here:
> > > > >
> > > > > https://github.com/stefanberger/swtpm
> > > > >
> > > > > (please use the latest version)
> > > > >
> > > > > To use the external CUSE TPM, the CUSE TPM should be started as
> follows:
> > > > >
> > > > > # terminate previously started CUSE TPM
> > > > > /usr/bin/swtpm_ioctl -s /dev/vtpm-test
> > > > >
> > > > > # start CUSE TPM
> > > > > /usr/bin/swtpm_cuse -n vtpm-test
> > > > >
> > > > > QEMU can then be started using the following parameters:
> > > > >
> > > > > qemu-system-x86_64 \
> > > > >    [...] \
> > > > >         -tpmdev cuse-tpm,id=tpm0,cancel-path=/dev/null,path=/
> > dev/vtpm-test
> > > \
> > > > >         -device tpm-tis,id=tpm0,tpmdev=tpm0 \
> > > > >    [...]
> > > > >
> > > > >
> > > > > Signed-off-by: Stefan Berger <address@hidden>
> > > > > Cc: Eric Blake <address@hidden>
> > > >
> > > > Before we add a dependency on this interface,
> > > > I'd rather see this interface supported in kernel
> > > > and not just in CUSE.
> > >
> > > For using the single hardware TPM, we have the passthrough type.
> > It's usage is
> > > limited.
> > >
> > > CUSE extends the TPM character device interface with ioctl's. Behind the
> > > character device we can implement a TPM 1.2 and a TPM 2. Both TPM
> > > implementations require large amounts of code, which I don't thinkshould 
> > > go
> > > into the Linux kernel itself. So I don't know who would implement this
> > > interface inside the Linux kernel.
> > >
> > >   Stefan
> > >
> >
> > BTW I'm not talking about the code - I'm talking about the interfaces here.
> >
> > One way would be to add support for these interface support in the kernel.
> >
> > Maybe others can be replaced with QMP events so management
> > can take the necessary action.
> >
> > As long as this is not the case, I suspect this code will have to stay
> > out of tree :( We can't depend on interfaces provided solely by cuse
> > devices on github.
> 
> Why is that? I know that the existing ioctls cannot be modified anymore once
> QEMU accepts the code. So I don't understand it. Some of the ioctls are only
> useful when emulating a hardware device,

Maybe they can be replaced with QMP events?
These could be emitted unconditionally, and ignored
by management in passthrough case.

> so there's no need for them in a
> kernel interface unless one was to put the vTPM code into the Linux kernel, 
> but
> I don't see that this is happening. What is better about a kernel interface
> versus one implemented by a project on github assuming that the existing 
> ioctls
> are stable? What is the real reason here?
> 
>    Stefan
> 

That someone went to the trouble of reviewing the interface for
long-term maintainability, portability etc. That it obeys some existing
standards for API use, coding style etc and will continue to.

In other words, kernel is already a dependency for QEMU.

> >
> >
> >
> > --
> > MST
> >
> 



reply via email to

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