Re: [Qemu-devel] vNVRAM / blobstore design

[mdroth <mdroth@linux.vnet.ibm.com>]

On Wed, Mar 27, 2013 at 05:30:09PM +0200, Michael S. Tsirkin wrote:
> On Wed, Mar 27, 2013 at 11:20:43AM -0400, Corey Bryant wrote:
> > 
> > 
> > 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 <stefanb@linux.vnet.ibm.com> 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
> 
> I think I like BER better. JSON seems like a bad fit for a
> bunch of binary blobs.
> 

I agree, but I also think that if we use visitors it shouldn't matter
what visitor implementation we use on the backend. It might be a good
idea to build the code around a stable, existing visitor implementation
like the JSON visitors, and then plug in a BER visitor prior to merge
(or after, if the encoding is configurable/detectable).

If a BER visitor provides benefits over JSON (and I do see that being the
case here) and is general enough that it's interchangeable with a JSON
visitor, then I don't see any reason that code wouldn't stand on it's own
rather than as a prereq for vTPM/nvram.

> > >>
> > >>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
> > >>
> > >
>