From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33748) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLvm4-00042k-PZ for qemu-devel@nongnu.org; Wed, 20 Jan 2016 11:38:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLvm1-00018p-FU for qemu-devel@nongnu.org; Wed, 20 Jan 2016 11:38:24 -0500 Received: from e38.co.us.ibm.com ([32.97.110.159]:58717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLvm0-00018d-UK for qemu-devel@nongnu.org; Wed, 20 Jan 2016 11:38:21 -0500 Received: from localhost by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 20 Jan 2016 09:34:38 -0700 Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 073F2C41143 for ; Wed, 20 Jan 2016 09:15:49 -0700 (MST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by b03cxnp08025.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u0KGRcQm17498364 for ; Wed, 20 Jan 2016 09:27:38 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u0KGGG9i007280 for ; Wed, 20 Jan 2016 09:27:38 -0700 Received: from e39.co.us.ibm.com (e39.boulder.ibm.com [9.17.249.49]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u0KFW6gC004422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 20 Jan 2016 08:32:06 -0700 Message-Id: <201601201532.u0KFW6gC004422@d03av04.boulder.ibm.com> Received: from localhost by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 20 Jan 2016 08:32:03 -0700 Received: from /spool/local by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for from ; Wed, 20 Jan 2016 15:31:59 -0000 In-Reply-To: <20160120150041.GC13215@redhat.com> From: "Stefan Berger" Date: Wed, 20 Jan 2016 10:31:56 -0500 References: <1451921002-8263-1-git-send-email-stefanb@us.ibm.com> <1451921002-8263-2-git-send-email-stefanb@us.ibm.com> <20160120150041.GC13215@redhat.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0055536285257F40_=" 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: "Daniel P. Berrange" Cc: mst@redhat.com, Stefan Berger , qemu-devel@nongnu.org, jb613w@att.com, quan.xu@intel.com, silviu.vlasceanu@gmail.com, hagen.lauer@huawei.com --=_alternative 0055536285257F40_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="US-ASCII" "Daniel P. Berrange" wrote on 01/20/2016 10:00:41=20 AM: > Subject: Re: [Qemu-devel] [PATCH v5 1/4] Provide support for the CUSE=20 TPM >=20 > On Mon, Jan 04, 2016 at 10:23:19AM -0500, Stefan Berger wrote: > > From: Stefan Berger > >=20 > > Rather than integrating TPM functionality into QEMU directly > > using the TPM emulation of libtpms, we now integrate an external > > emulated TPM device. This device is expected to implement a Linux > > CUSE interface (CUSE =3D character device in userspace). > >=20 > > QEMU talks to the CUSE TPM using much functionality of the > > passthrough driver. For example, the TPM commands and responses > > are sent to the CUSE TPM using the read()/write() interface. > > However, some out-of-band control needs to be done using the CUSE > > TPM's ioctls. The CUSE TPM currently defines and implements 15 > > different ioctls for controlling certain life-cycle aspects of > > the emulated TPM. The ioctls can be regarded as a replacement for > > direct function calls to a TPM emulator if the TPM were to be > > directly integrated into QEMU. > >=20 > > One of the ioctls allows to get a bitmask of supported capabilities. > > Each returned bit indicates which capabilities have been implemented. > > An include file defining the various ioctls is added to QEMU. > >=20 > > The CUSE TPM and associated tools can be found here: > >=20 > > https://github.com/stefanberger/swtpm > >=20 > > (please use the latest version) > >=20 > > To use the external CUSE TPM, the CUSE TPM should be started as=20 follows: > >=20 > > # terminate previously started CUSE TPM > > /usr/bin/swtpm=5Fioctl -s /dev/vtpm-test > >=20 > > # start CUSE TPM > > /usr/bin/swtpm=5Fcuse -n vtpm-test >=20 > IIUC, there needs to be one swtpm=5Fcuse process running per QEMU > TPM device ? This makes my wonder why we need this separate Correct. See reason in answer to previous email. > process at all - it would make sense if there was a single > swtpm=5Fcuse shared across all QEMU's, but if there's one per > QEMU device, it feels like it'd be much simpler to just have > the functionality linked in QEMU. That avoids the problem I tried having it linked in QEMU before. It was basically rejected. > of having to manage all these extra processes alongside QEMU > which can add a fair bit of mgmt overhead. For libvirt, yes, there is mgmt. overhead but it's quite transparent. So=20 libvirt is involved in the creation of the directory for the vTPMs, the=20 command line creation for the external process as well as the startup of=20 the process, but otherwise it's not a big issue (anymore). I have the=20 patches that do just for an older libvirt version that along with setting=20 up SELinux labels, cgroups etc. for each VM that wants an attached vTPM. Regards, Stefan >=20 > >=20 > > QEMU can then be started using the following parameters: > >=20 > > qemu-system-x86=5F64 \ > > [...] \ > > -tpmdev=20 cuse-tpm,id=3Dtpm0,cancel-path=3D/dev/null,path=3D/dev/vtpm-test \ > > -device tpm-tis,id=3Dtpm0,tpmdev=3Dtpm0 \ > > [...] >=20 > Regards, > Daniel > --=20 > |: http://berrange.com -o- =20 http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- =20 http://virt-manager.org :| > |: http://autobuild.org -o- =20 http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- =20 http://live.gnome.org/gtk-vnc :| >=20 --=_alternative 0055536285257F40_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="US-ASCII" "Daniel P. Berrange" <berrange@redhat.com&g= t; wrote on 01/20/2016 10:00:41 AM:

> Subject: Re: [Qemu-devel] [PAT= CH v5 1/4] Provide support for the CUSE TPM
>
> On Mon, Jan 04, 2016 at= 10:23:19AM -0500, Stefan Berger wrote:
> > From: Stefan Berger &l= t;stefanb@linux.vnet.ibm.com>
> >
> > Rather than int= egrating TPM functionality into QEMU directly
> > using the TPM em= ulation of libtpms, we now integrate an external
> > emulated TPM = device. This device is expected to implement a Linux
> > CUSE inte= rface (CUSE =3D character device in userspace).
> >
> > = QEMU talks to the CUSE TPM using much functionality of the
> > pas= sthrough driver. For example, the TPM commands and responses
> > a= re sent to the CUSE TPM using the read()/write() interface.
> > Ho= wever, some out-of-band control needs to be done using the CUSE
> > TPM's ioctls. The CUSE TPM currently defines and implemen= ts 15
> > different ioctls for controlling certain life-cycle aspe= cts of
> > the emulated TPM. The ioctls can be regarded as a repla= cement for
> > direct function calls to a TPM emulator if the TPM were to= be
> > directly integrated into QEMU.
> >
> > = One of the ioctls allows to get a bitmask of supported capabilities.
>= ; > Each returned bit indicates which capabilities have been implemented= .
> > An include file defining the various ioctls is added to QEMU= .
> >
> > 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=5Fioctl -s /dev/vtpm-test
> >
= > > # start CUSE TPM
> > /usr/bin/swtpm=5Fcuse -n vtpm-test<= br>>
> IIUC, there needs to be one swtpm=5Fcuse process running p= er QEMU
> TPM device ?  This makes my wonder why we need this se= parate

Correct. See reason in answer = to previous email.

> process at al= l - it would make sense if there was a single
> swtpm=5Fcuse shared a= cross all QEMU's, but if there's one per
> QEMU device, it feels like= it'd be much simpler to just have
> the functionality linked in QEMU= .  That avoids the problem

I tri= ed having it linked in QEMU before. It was basically rejected.

> of having to manage al= l these extra processes alongside QEMU
> which can add a fair bit of = mgmt overhead.

For libvirt, yes, ther= e is mgmt. overhead but it's quite transparent. So libvirt is involved in the creation of the directory for the vTPMs, the command line creation for the external process as well as the startup of the process, but otherwise it's not a big issue (anymore). I have the patches that do just for an older libvirt version that along with setting up SELinux labels, cgroups etc. for each VM that wants an attached vTPM.

Regards,   Stefan
=
>
> >
> > QEMU can then be started using the fol= lowing parameters:
> >
> > qemu-system-x86=5F64 \
>= ; >    [...] \
> >         -tpmde= v cuse-tpm,id=3Dtpm0,cancel-path=3D/dev/null,path=3D/dev/vtpm-test \
> >         -device tpm-tis,id=3Dtpm0,tpmdev= =3Dtpm0 \
> >    [...]
>
> Regards,
> Daniel<= br>> --
> |: http://berrange.com  &nbs= p;  -o-    http://www.flickr.com/photos/dberrange/:|
> |: http://libvirt.org             -o-     =         <= font size=3D2>http://virt-manager.org:|<= br>> |: h= ttp://autobuild.org      = -o-         http://search.cpan.org/~danberr/= :|
> |: http://entangle-photo.org      -o-       = http://live.gn= ome.org/gtk-vnc:|
>

--=_alternative 0055536285257F40_=--