From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4BlG-0000Po-5r for qemu-devel@nongnu.org; Thu, 15 Sep 2011 09:13:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4BlE-0002zO-So for qemu-devel@nongnu.org; Thu, 15 Sep 2011 09:13:50 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]:55959) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4BlE-0002z2-7Y for qemu-devel@nongnu.org; Thu, 15 Sep 2011 09:13:48 -0400 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e35.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p8FCr51r027358 for ; Thu, 15 Sep 2011 06:53:05 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p8FDDRiY095912 for ; Thu, 15 Sep 2011 07:13:29 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p8FDDBPQ012170 for ; Thu, 15 Sep 2011 07:13:11 -0600 Message-ID: <4E71F9F5.9060005@linux.vnet.ibm.com> Date: Thu, 15 Sep 2011 09:13:25 -0400 From: Stefan Berger MIME-Version: 1.0 References: <4E70DEE8.8090908@linux.vnet.ibm.com> <20110915130514.GQ29309@redhat.com> In-Reply-To: <20110915130514.GQ29309@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Design of the blobstore List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Markus Armbruster , Anthony Liguori , QEMU Developers , "Michael S. Tsirkin" On 09/15/2011 09:05 AM, Daniel P. Berrange wrote: > On Wed, Sep 14, 2011 at 01:05:44PM -0400, Stefan Berger wrote: >> Hello! >> >> Over the last few days primarily Michael Tsirkin and I have >> discussed the design of the 'blobstore' via IRC (#virtualization). >> The intention of the blobstore is to provide storage to persist >> blobs that devices create. Along with these blobs possibly some >> metadata should be storable in this blobstore. >> >> An initial client for the blobstore would be the TPM emulation. >> The TPM's persistent state needs to be stored once it changes so it >> can be restored at any point in time later on, i.e., after a cold >> reboot of the VM. In effect the blobstore simulates the NVRAM of a >> device where it would typically store such persistent data onto. > While I can see the appeal of a general 'blobstore' for NVRAM > tunables related to device, wrt the TPM emulation, should we > be considering use of something like the PKCS#11 standard for > storing/retrieving crypto data for the TPM ? > > https://secure.wikimedia.org/wikipedia/en/wiki/PKCS11 We should regard the blobs the TPM produces as crypto data as a whole, allowing for encryption of each one. QCoW2 encryption is good for that since it uses per-sector encryption but we loose all that in case of RAW image being use for NVRAM storage. FYI: The TPM writes its data in a custom format and produces a blob that should be stored without knowing the organization of its content. This blob doesn't only contain keys but many other data in the 3 different types of blobs that the TPM can produce under certain cirumstances : values of counters, values of the PCRs (20 byte long registers), keys, owner and SRK (storage root key) password, TPM's NVRAM areas, flags etc. It produces the following blobs: - permanent data blob: Whenever it writes data to peristent storage - save state blob: Upon a S3 Suspend (kicked by the TPM TIS driver sending a command to the TPM) - volatile data: Upon migration / suspend that contains the volatile data that after a reboot of the VM typically are initialized by the TPM but of course need to be restored on the migration target / resume. Stefan > This is a industry standard for interfacing to cryptographic > storage mechanisms, widely supported by all SSL libraries& more > or less all programming languages. IIUC it lets the application > avoid hardcoding a specification storage backend impl, so it can > be made to work with anything from local files, to smartcards, > to HSMs, to remote network services. > > Regards, > Daniel