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