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
