On 11/04/2014 07:45 PM, Markus Armbruster wrote: > I'll try to explain all solutions fairly. Isn't easy when you're as > biased towards one of them as I am. Please bear with me. >
Thanks for this write-up. I'll probably reply again, but for now I'm focusing on just one thing I think you missed that came up in the related threads: > = How can we better guard the trust boundary in QEMU? = > > The guest can violate the trust boundary only because > > (a) QEMU supports both raw images and image formats, and > > (b) QEMU guesses image format from raw image contents, and > > (c) given a raw image, guests can change its contents and control a > future QEMU's format guess. > > We can attack one ore more of these three conditions: > > (a) Outlaw raw images > > (b) Don't guess format from untrusted image contents > > (c) Prevent "bad" guest writes (d) write metadata that records our guess before releasing data across a trust boundary, so that we no longer need to probe on the next encounter While this won't work for top-level images, it is a possibility for backing store. Any time we open a qcow2 file that has a backing file without a format, we can rewrite the qcow2 metadata to record the type that we ended up settling on, prior to allowing the guest to manipulate the data. The initial open is "safe" (we haven't yet handed the data to the guest - and the trust boundary is not broken until the point that the guest has had a chance to overwrite data) and all subsequent opens are now safe (because we rewrote the metadata, subsequent operations no longer need to probe the backing file, but are guaranteed to use the same format as the first open, whether or not those subsequent operations are performed by a different qemu that would have probed a different type). PRO: Plugs hole for backing files CON: Doesn't help for top-level images. In a chain "base <- mid <- top" where neither mid nor top recorded backing type, it would require mid to be temporarily opened read-write to update the metadata. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
