[Top][All Lists]

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

Re: [Qemu-devel] [PATCH V8 10/14] Encrypt state blobs using AES CBC encr

From: Stefan Berger
Subject: Re: [Qemu-devel] [PATCH V8 10/14] Encrypt state blobs using AES CBC encryption
Date: Wed, 07 Sep 2011 20:16:27 -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/07/2011 02:55 PM, Michael S. Tsirkin wrote:
On Thu, Sep 01, 2011 at 10:23:51PM -0400, Stefan Berger wrote:
An additional 'layer' for reading and writing the blobs to the underlying
block storage is added. This layer encrypts the blobs for writing if a key is
available. Similarly it decrypts the blobs after reading.
So a couple of further thoughts:
1. Raw storage should work too, and with e.g. NFS migration will be fine, right?
    So I'd say it's worth supporting.
NFS via shared storage, yes, but not migration via Qemu's block migration mechanism. If snapshotting was supposed to be a feature to support then that's only possible via block storage (QCoW2 in particular).

Adding plain file support to the TPM code so it can store its 3 blobs into adds quite a bit of complexity to the code. The command line parameter that previously pointed to QCoW2 image file would probably have to point to a directory where files for the 3 blobs can be written into. Besides that, snapshotting would actually have to be prevented maybe through registering a (fake) file of other than QCoW2 type since the plain TPM files won't handle snapshotting correctly, either, and QEMU pretty much would have to be prevented from doing snapshotting at all. Maybe there's an API for this, but I don't know. Though why create this additional complexity? I don't mind relaxing the requirement of using a QCoW2 image and allowing for example RAW images (that then automatically prevent the snapshotting from happening) but the same code I now have would work for writing the blobs into it the single file.

2. File backed nvram is interesting outside tpm.
    For example,vpd and chassis number for pci, eeprom emulation for network 
    Using a file per device might be inconvenient though.
    So please think of a format and API that will allow sections
    for use by different devices.
Also here 'snapshotting' is the most 'demanding' feature of QEMU I would say. Snapshotting isn't easily supported outside of the block layer from what I understand. Once you are tied to the block layer you end up having to use images and those don't grow quite well. So other devices wanting to use those type of devices would need to know what the worst case sizes are for writing their state into -- unless an image format is created that can grow.

As for the format: Ideally all devices could write into one file, right? That would at least prevent too many files besides the VM's image file from floating around which presumably makes image management easier. Following the above, you add up all the worst case sizes the individual devices may need for their blobs and create an image with that capacity. Then you need some form of a (primitive?) directory that lets you write blobs into that storage. Assuming there were well defined names for those devices one could say for example store this blobs under the name 'tpm-permanent-state' and later on load it under that name. The possible size of the directory would have to be considered as well... I do something like that for the TPM where I have up to 3 such blobs that I store.

The bad thing about the above is of course the need to know what the sum of all the worst case sizes is. So a growable image format would be quite good to have. I haven't followed the conversations much, but is that something QCoW3 would support?

Crazy idea: Is there a filesystem that one could use and mount a filesystem onto (some) sectors of an image? Again, the best format right now is QCoW2 for this (due to snapshotting suport) where one would have to be able to mount a filesystem onto the current snapshot's available sectors. Then at least the handling of blobs would become a lot easier. Though I doubt this would be possible without custom code and lots of development.

3. Home-grown file formats give us enough trouble in migration.
    Could this use one of the variants of ASN.1?
    There are portable libraries to read/write that, even.

I am not sure what 'this' refers to. What I am doing with the TPM is writing 3 independent blobs at certain offset into the QCoW2 block file. A directory in the first sector holds the offsets, sizes and crc32's of these (unencrypted) blobs. I am not that familiar with ASN.1 except that from what I have seen it looks like a fairly terrible format needing an object language to create a parser from etc. not to mention the problems I had with snacc trying to compile the ASN.1 object language of an RFC...


reply via email to

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