From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47655) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKsAk-0001Zk-F9 for qemu-devel@nongnu.org; Wed, 27 Mar 2013 11:21:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKsAi-0006Um-U7 for qemu-devel@nongnu.org; Wed, 27 Mar 2013 11:21:54 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]:47670) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKsAi-0006Ug-Ms for qemu-devel@nongnu.org; Wed, 27 Mar 2013 11:21:52 -0400 Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 27 Mar 2013 09:21:51 -0600 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id CEDDD3E4007C for ; Wed, 27 Mar 2013 09:20:55 -0600 (MDT) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2RFKrAu066614 for ; Wed, 27 Mar 2013 09:20:54 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2RFKnx3027777 for ; Wed, 27 Mar 2013 09:20:50 -0600 Message-ID: <51530E4B.2010203@linux.vnet.ibm.com> Date: Wed, 27 Mar 2013 11:20:43 -0400 From: Corey Bryant MIME-Version: 1.0 References: <5150C415.9030302@linux.vnet.ibm.com> <87ehf3nnja.fsf@codemonkey.ws> <5150CDA8.3020300@linux.vnet.ibm.com> <51530DA2.2030409@linux.vnet.ibm.com> In-Reply-To: <51530DA2.2030409@linux.vnet.ibm.com> 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 , Kent E Yoder , Stefan Berger , qemu-devel , Michael Roth , Joel Schopp , Kenneth Goldman On 03/27/2013 11:17 AM, Corey Bryant wrote: > > > On 03/25/2013 06:20 PM, Stefan Berger wrote: >> 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? > > The max number of blobs and frequency of usage depends on the usage > scenario and NVRAM size. But that's probably obvious. > > I think we should focus on worst case scenarios where NVRAM is filled up > and used frequently. > > One example is that an application can use TSS APIs to define, undefine, > read, and write to the TPM's NVRAM storage. (The TPM owner password is > required to define NVRAM data.) An application could potentially fill > up NVRAM and frequently store, change, retrieve data in various places > within NVRAM. And the data could have various sizes. > > For an example of total NVRAM size, Infineon's TPM has 16K of NVRAM. > > -- > Regards, > Corey Bryant > I just wanted to add that we could really use some direction on which way the community would prefer we go with this. The 2 options that are on the table at the moment for encoding/decoding the vNVRAM byte stream are BER or JSON visitors. -- Regards, Corey Bryant >> >> 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 >> >