qemu-devel
[Top][All Lists]
Advanced

[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 10:00:30 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.11

On 09/15/2011 09:27 AM, Daniel P. Berrange wrote:
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 ?
There's no absolute definition of how a TPM writes all its data into NVRAM. Some structures are defined and we used them where we could, others were defined by 'us' -- so they are manufacturer-specific. Suspend operations for example were not envisioned for the hardware TPM but we needed to write more data out than what the standard defines so we could resume properly. What is defined is persistent storage and S3 suspend (save state) as described in the previous mail.

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


v8 (and before) of my TPM patch postings had something like this, but nicely layered though, and I was doing it on a per-blob basis, so no 'slots'. The vTPM dev was passing its raw blobs down to the 'NVRAM' layer and that NVRAM either had a key for encryption or not. In case it didn't have a key it just wrote the data at a certain offset, noting the actual blob size in a directory at in the 1st sector. In case the NVRAM layer had a key it encrypted the blob (which enlarged to the next 16 byte boundary due to AES encryption) and wrote that AES-CBC encrypted blob at a certain offset, noting the actual unencrypted blob size in the directory. The header of the directory contained a flag that all data were encrypted -- so this flag was a property of each blob on the disk.

Now with Michael's ASN1 encoding and the additional metadata, I think the encryption should come after encoding the blob and metadata into ASN1 . Again a directory would need a flag for whether the blobs or a single blob is encrypted. I guess this again goes back to command line parameters as well. Where do we pass the key, Is it a per-device property (-tpmdev ...,key=...,) where the device registers a key to use on its blob or a per-blobstore/nvram (-nvram drive=...,key=...) property?

   Stefan
Regards,
Daniel




reply via email to

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