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

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Jan 21, 2016 at 05:41:32AM +0000, Xu, Quan wrote:
> > On January 21, 2016 at 1:08pm, <mst@redhat.com> 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" <mst@redhat.com> wrote on 01/20/2016 10:58:02 AM:
> > > >>
> > > >>>From: "Michael S. Tsirkin" <mst@redhat.com> On Wed, Jan 20, 2016 at
> > > >>>10:36:41AM -0500, Stefan Berger wrote:
> > > >>>>"Michael S. Tsirkin" <mst@redhat.com> wrote on 01/20/2016 10:20:58
> > AM:
> > > >>>>
> > > >>>>>From: "Michael S. Tsirkin" <mst@redhat.com>
> > > >>>>>>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 <stefanb@linux.vnet.ibm.com>
> > > >>>>>>Cc: Eric Blake <eblake@redhat.com>
> > > >>>>>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.

No, the major issue is in how it's put together.

> 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

Nothing's wrong with a software TPM.  My advice is to stop using CUSE
for it, and to put it in an existing source tree (QEMU,kernel, something
else QEMU depends on).

-- 
MST