From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37739) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aM7Tx-0002Ww-A0 for qemu-devel@nongnu.org; Thu, 21 Jan 2016 00:08:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aM7Tu-0001hF-3T for qemu-devel@nongnu.org; Thu, 21 Jan 2016 00:08:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47582) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aM7Tt-0001hB-SK for qemu-devel@nongnu.org; Thu, 21 Jan 2016 00:08:26 -0500 Date: Thu, 21 Jan 2016 07:08:20 +0200 From: "Michael S. Tsirkin" Message-ID: <20160121002441-mutt-send-email-mst@redhat.com> References: <1451921002-8263-1-git-send-email-stefanb@us.ibm.com> <1451921002-8263-2-git-send-email-stefanb@us.ibm.com> <20160120171258-mutt-send-email-mst@redhat.com> <201601201536.u0KFanwG004844@d01av04.pok.ibm.com> <20160120155802.GA32541@redhat.com> <201601201607.u0KG7NtZ004518@d03av03.boulder.ibm.com> <20160120185328-mutt-send-email-mst@redhat.com> <569FFB3B.7090600@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <569FFB3B.7090600@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH v5 1/4] Provide support for the CUSE TPM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Berger Cc: Stefan Berger , qemu-devel@nongnu.org, jb613w@att.com, quan.xu@intel.com, silviu.vlasceanu@gmail.com, hagen.lauer@huawei.com 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" wrote on 01/20/2016 10:58:02 AM: > >> > >>>From: "Michael S. Tsirkin" > >>>On Wed, Jan 20, 2016 at 10:36:41AM -0500, Stefan Berger wrote: > >>>>"Michael S. Tsirkin" wrote on 01/20/2016 10:20:58 AM: > >>>> > >>>>>From: "Michael S. Tsirkin" > >>>>>>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 > >>>>>>Cc: Eric Blake > >>>>>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 > >>>