From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53354) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLvEA-0006wn-50 for qemu-devel@nongnu.org; Wed, 20 Jan 2016 11:03:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLvE4-0001db-AP for qemu-devel@nongnu.org; Wed, 20 Jan 2016 11:03:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47678) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLvE4-0001dR-57 for qemu-devel@nongnu.org; Wed, 20 Jan 2016 11:03:16 -0500 Date: Wed, 20 Jan 2016 18:03:11 +0200 From: "Michael S. Tsirkin" Message-ID: <20160120175933-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> <20160120150041.GC13215@redhat.com> <201601201532.u0KFW2q2019737@d03av03.boulder.ibm.com> <20160120154657.GF13215@redhat.com> <569FADC7.7060301@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <569FADC7.7060301@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 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. > > Stefan If that's the only reason for it, you can package it as part of QEMU source, run it as a sub-process. > > > > > >Regards, > >Daniel