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

[Michael S. Tsirkin]

On Wed, Sep 07, 2011 at 08:16:27PM -0400, Stefan Berger wrote:
> 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).

As disk has the same limitation, that sounds fine.
Let the user decide whether snapshoting is needed,
same as disk.

> 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.

Right. Write all blobs into a single files at different
offsets, or something.

> >2. File backed nvram is interesting outside tpm.
> >    For example,vpd and chassis number for pci, eeprom emulation for network 
> > cards.
> >    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.

A typical usecase I know about has prepared vpd/eeprom content.
We'll typically need a tool to get binary blobs and put that into the
file image.  That tool can do the necessary math.
We could also integrate this into qemu-img if we like.

> 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?

I don't follow - does TPM need a growable image format? Why?
Hardware typically has fixed amount of memory :)

> 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.

Hmm, libguestfs can do all kind of smart stuff.
But we don't want qemu to depend on that.

> >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.

Right. It's the encoding of the directory that is custom,
and that bothers me. I'd prefer a format that is self-describing and
self-delimiting, give a way to inspect the data using external tools.

> 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...
> 
>    Stefan

Sorry about the confusion, we don't need the notation, I don't mean that.
I mean use a subset of the ASN.1 basic encoding
http://homepages.dcc.ufmg.br/~coelho/nm/asn.1.intro.pdf

So we could have a set of sequences, with an ascii string (a tag)
followed by an octet string (content).


-- 
MST