From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58873) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDHpw-0002RO-2h for qemu-devel@nongnu.org; Wed, 15 Jun 2016 16:54:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bDHps-0002wM-1q for qemu-devel@nongnu.org; Wed, 15 Jun 2016 16:54:56 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:29547) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDHpr-0002v0-PL for qemu-devel@nongnu.org; Wed, 15 Jun 2016 16:54:51 -0400 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u5FKn0ei057678 for ; Wed, 15 Jun 2016 16:54:49 -0400 Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by mx0a-001b2d01.pphosted.com with ESMTP id 23jch63rc2-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 15 Jun 2016 16:54:49 -0400 Received: from localhost by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 15 Jun 2016 14:54:48 -0600 References: <1451921002-8263-2-git-send-email-stefanb@us.ibm.com> <20160120150041.GC13215@redhat.com> <201601201532.u0KFW2q2019737@d03av03.boulder.ibm.com> <20160120154657.GF13215@redhat.com> <569FADC7.7060301@linux.vnet.ibm.com> <20160120162220.GH13215@redhat.com> <20160121113632.GC2446@work-vm> <57FA3A002D66E049AA7792D931B894C7060F5494@MOKSCY3MSGUSRGB.ITServices.sbc.com> <945CA011AD5F084CBEA3E851C0AB28894B8C3A14@SHSMSX101.ccr.corp.intel.com> <575E92DB.3080904@linux.vnet.ibm.com> <20160615193019.GB7300@work-vm> From: Stefan Berger Date: Wed, 15 Jun 2016 16:54:42 -0400 MIME-Version: 1.0 In-Reply-To: <20160615193019.GB7300@work-vm> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <5761C092.5070702@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: "Dr. David Alan Gilbert" Cc: Stefan Berger , "mst@redhat.com" , "qemu-devel@nongnu.org" , "SERBAN, CRISTINA" , "BICKFORD, JEFFREY E" , "Xu, Quan" , "silviu.vlasceanu@gmail.com" , "hagen.lauer@huawei.com" , "SHIH, CHING C" On 06/15/2016 03:30 PM, Dr. David Alan Gilbert wrote: > * Stefan Berger (stefanb@linux.vnet.ibm.com) wrote: >> On 05/31/2016 09:58 PM, Xu, Quan wrote: >>> On Wednesday, June 01, 2016 2:59 AM, BICKFORD, JEFFREY E wrote: >>>>> * Daniel P. Berrange (berrange@redhat.com) wrote: >>>>>> On Wed, Jan 20, 2016 at 10:54:47AM -0500, Stefan Berger wrote: >>>>>>> On 01/20/2016 10:46 AM, Daniel P. Berrange wrote: >>>>>>>> On Wed, Jan 20, 2016 at 10:31:56AM -0500, Stefan Berger wrote: >>>>>>>>> "Daniel P. Berrange" wrote on 01/20/2016 >>>>>>>>> 10:00:41 >>>>>>>>> AM: >>>>>>>>> >>>>>>>>> >>>>>>>>>> process at all - it would make sense if there was a single >>>>>>>>>> swtpm_cuse 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. >>>>>>>> I remember an impl you did many years(?) ago now, but don't >>>>>>>> recall the results of the discussion. Can you elaborate on why it >>>>>>>> was rejected as an approach ? It just doesn't make much sense to >>>>>>>> me to have to create an external daemon, a CUSE device and comms >>>>>>>> protocol, simply to be able to read/write a plain file containing >>>>>>>> the TPM state. Its massive over engineering IMHO and adding way >>>>>>>> more complexity and thus scope for failure >>>>>>> The TPM 1.2 implementation adds 10s of thousands of lines of code. >>>>>>> The TPM 2 implementation is in the same range. The concern was >>>>>>> having this code right in the QEMU address space. It's big, it can >>>>>>> have bugs, so we don't want it to harm QEMU. So we now put this >>>>>>> into an external process implemented by the swtpm project that >>>>>>> builds on libtpms which provides TPM 1.2 functionality (to be >>>>>>> extended with TPM 2). We cannot call APIs of libtpms directly >>>>>>> anymore, so we need a control channel, which is implemented through >>>> ioctls on the CUSE device. >>>>>> Ok, the security separation concern does make some sense. The use of >>>>>> CUSE still seems fairly questionable to me. CUSE makes sense if you >>>>>> want to provide a drop-in replacement for the kernel TPM device >>>>>> driver, which would avoid ned for a new QEMU backend. If you're not >>>>>> emulating an existing kernel driver ABI though, CUSE + ioctl is >>>>>> feels like a really awful RPC transport between 2 userspace processes. >>>>> While I don't really like CUSE; I can see some of the reasoning here. >>>>> By providing the existing TPM ioctl interface I think it means you can >>>>> use existing host-side TPM tools to initialise/query the soft-tpm, and >>>>> those should be independent of the soft-tpm implementation. >>>>> As for the extra interfaces you need because it's a soft-tpm to set it >>>>> up, once you've already got that ioctl interface as above, then it >>>>> seems to make sense to extend that to add the extra interfaces needed. >>>>> The only thing you have to watch for there are that the extra >>>>> interfaces don't clash with any future kernel ioctl extensions, and >>>>> that the interface defined is generic enough for different soft-tpm >>>> implementations. >>>> >>>>> Dave >>>>> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK >>>> Over the past several months, AT&T Security Research has been testing the >>>> Virtual TPM software from IBM on the Power (ppc64) platform. >>> What about x86 platform? >>> >>>> Based on our >>>> testing results, the vTPM software works well and as expected. Support for >>>> libvirt and the CUSE TPM allows us to create VMs with the vTPM functionality >>>> and was tested in a full-fledged OpenStack environment. >>>> >>> Cool.. >>> >>>> We believe the vTPM functionality will improve various aspects of VM security >>>> in our enterprise-grade cloud environment. AT&T would like to see these >>>> patches accepted into the QEMU community as the default-standard build so >>>> this technology can be easily adopted in various open source cloud >>>> deployments. >>> Stefan: could you update status about this patch set? I'd really appreciate your patch.. >> What do you mean by 'update status'. It's pretty much still the same as >> before. >> >> https://github.com/stefanberger/qemu-tpm/tree/v2.6.0+tpm >> >> >> The implementation of the swtpm that I use for connecting QEMU to now has >> more interface choices. There's the existing CUSE + ioctl for data and >> control channel or any combination of TCP and Unix sockets for data and >> control channel. The libvirt based management stack I built on top of QEMU >> with vTPM assumes QEMU using the CUSE interface. > So what was the multi-instance vTPM proxy driver patch set about? That's for containers. Stefan