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

[Michael S. Tsirkin]

On Wed, Jan 20, 2016 at 04:25:15PM -0500, Stefan Berger wrote:
> On 01/20/2016 01:54 PM, Michael S. Tsirkin wrote:
> >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.
> 
> The same applies to the libtpms and swtpm projects as well, I suppose. If
> someone wants to join them, let me know.
> 
> As stated, we will keep the existing ioctl stables once integrated but will
> adapt where necessary before that.
> >
> >In other words, kernel is already a dependency for QEMU.
> 
> I don't see vTPM going into the kernel, at least I don't know of anyone
> trying to do that.
> 
>    Stefan
> 

Well that was just one idea, it's up to you guys.
But while modular multi-process QEMU for security
might happen in future, I don't see us doing this
by moving large parts of QEMU into cuse devices,
and talking to these through ioctls.

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