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

[Xu, Quan]

> On January 21, 2016 at 1:08pm, <address@hidden> wrote:
> 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.


IIUC, the major root issue is that CUSE TPM is based on soft defined TPM, 
instead of hardware TPM.
This may bring in more security/stability issues.. 
As I know, some trusted cloud products must base on upstream code. TPM passthru 
is just for limited VM.
As I mentioned, I think CUSE TPM is a good solution for trusted cloud.

Hagen, could you share more user cases for CUSE TPM?
MST, is it possible for CUSE TPM upstream? or much more ARs for Stefan Berger?


Quan