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. > >>> > >>> > >>>-- > >>>MST > >>>
