Re: [Qemu-devel] Design of the blobstore

["Daniel P. Berrange" <berrange@redhat.com>]

On Thu, Sep 15, 2011 at 09:13:25AM -0400, Stefan Berger wrote:
> 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.

Is this description of storage inherant in the impl of TPMs in general,
or just the way you've chosen to implement the QEMU vTPM ?

IIUC, you are describing a layering like

   +----------------+
   | Guest App      |
   +----------------+
     ^ ^ ^ ^ ^ ^ ^
     | | | | | | |    Data slots
     V V V V V V V
   +----------------+
   | QEMU vTPM Dev  |
   +----------------+
      ^
      |               Data blob
      V
   +----------------+
   | Storage device |  (File/block dev)
   +----------------+

I was thinking about whether we could delegate the encoding
of data slots -> blobs, to outside the vTPM device emulation
by using PKCS ?

   +----------------+
   | Guest App      |
   +----------------+
     ^ ^ ^ ^ ^ ^ ^
     | | | | | | |    Data slots
     V V V V V V V
   +----------------+
   | QEMU vTPM Dev  |
   +----------------+
     ^ ^ ^ ^ ^ ^ ^
     | | | | | | |    Data slots
     V V V V V V V
   +----------------+
   | PKCS#11 Driver |
   +----------------+
      ^
      |               Data blob
      V
   +----------------+
   | Storage device | (File/blockdev/HSM/Smartcard)
   +----------------+


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|