From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46769) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKFkq-0001na-UU for qemu-devel@nongnu.org; Mon, 25 Mar 2013 18:20:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKFkl-0004jA-OZ for qemu-devel@nongnu.org; Mon, 25 Mar 2013 18:20:36 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:36459) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKFkl-0004ig-JL for qemu-devel@nongnu.org; Mon, 25 Mar 2013 18:20:31 -0400 Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 25 Mar 2013 18:20:31 -0400 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 15881C9001D for ; Mon, 25 Mar 2013 18:20:27 -0400 (EDT) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2PMKQNM341294 for ; Mon, 25 Mar 2013 18:20:26 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2PMKPnO005648 for ; Mon, 25 Mar 2013 19:20:26 -0300 Message-ID: <5150CDA8.3020300@linux.vnet.ibm.com> Date: Mon, 25 Mar 2013 18:20:24 -0400 From: Stefan Berger MIME-Version: 1.0 References: <5150C415.9030302@linux.vnet.ibm.com> <87ehf3nnja.fsf@codemonkey.ws> In-Reply-To: <87ehf3nnja.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] vNVRAM / blobstore design List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "Michael S. Tsirkin" , Stefan Hajnoczi , Corey Bryant , qemu-devel , Michael Roth , Joel Schopp On 03/25/2013 06:05 PM, Anthony Liguori wrote: > Stefan Berger writes: > >> [argh, just posted this to qemu-trivial -- it's not trivial] >> >> >> Hello! >> >> I am posting this message to revive the previous discussions about the >> design of vNVRAM / blobstore cc'ing (at least) those that participated >> in this discussion 'back then'. >> >> The first goal of the implementation is to provide an vNVRAM storage for >> a software implementation of a TPM to store its different blobs into. >> Some of the data that the TPM writes into persistent memory needs to >> survive a power down / power up cycle of a virtual machine, therefore >> this type of persistent storage is needed. For the vNVRAM not to become >> a road-block for VM migration, we would make use of block device >> migration and layer the vNVRAM on top of the block device, therefore >> using virtual machine images for storing the vNVRAM data. >> >> Besides the TPM blobs the vNVRAM should of course also be able able to >> accommodate other use cases where persistent data is stored into >> NVRAM, > Well let's focus more on the "blob store". What are the semantics of > this? Is there a max number of blobs? Are the sizes fixed or variable? > How often are new blobs added/removed? In case of TPM 1.2 there are 3 blobs that can be written at different times for different reasons. Examples: As with a real-world TPM users loading an owner-evict key into the TPM will cause the TPM to write that owner-evict key into is own NVRAM. This key survives a power-off of the machine. Further, the TPM models its own NVRAM slots. Someone writing into this type of memory will cause data to be written into the NVRAM. There are other commands that the TPM offers that will cause data to be written into NVRAM which users can invoke at any time. The sizes of the NVRAM blobs of the TPM at least vary in size but I handle this in the TPM emulation to pad them to fixed size. Depending on how many such owner-evict keys are loaded into the TPM its permanent state blob size may vary. Other devices may act differently. We have a-priori knowledge about the 3 different types of blobs the TPM device produces. They are 'registered' once at the beginning (see API) and are not 'removed' as such. Regards, Stefan