Re: [Qemu-devel] Design of the blobstore

[Stefan Berger]

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