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
