Disclaimer: I'm not a security expert or a QEMU expert so it'd be nice to hear opinion from someone more familiar with these
My understanding that the image format CVE we are mainly discussing here is caused by the way how QEMU (specifically qemu-img) handles image format.
However for kernel image and ramdisk image these are treated as pure "raw" image without any conversion or parsing method in both nova layer as well as QEMU layer (when these are associated with kernel/ramdisk_id, not by AMI), so it may have relatively lower risks to keep the current handling of these images
My current view after quick dig into the QEMU implementation is that the direct kernel boot implementation in QEMU extract kernel data and ram data into guest memory area without any format parsing so I expect impact of malformed images may be limited to the instances which are launched with these images basically.
Yeah, there's not any concern (that I know of) around interpreting kernel and ramdisk images with qemu. What I meant was the special casing we have in *nova* around AMI itself, which qemu knows nothing about and requires us to coerce the disk part of that to raw (but which *could* be a different format qemu does support) is the biggest problem for us. So if we decide we need to keep the "allow an image to specify a kernel/ramdisk" for the moment, then so be it. But that's separate from the more pressing concern of just removing nova support for AMI as a format and all the hacks we have in place for it. --Dan