[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Design of the blobstore

From: Stefan Berger
Subject: Re: [Qemu-devel] Design of the blobstore
Date: Thu, 15 Sep 2011 09:13:25 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.11

On 09/15/2011 09:05 AM, Daniel P. Berrange wrote:
On Wed, Sep 14, 2011 at 01:05:44PM -0400, Stefan Berger wrote:

   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 ?

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.


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]