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
