On 07/15/2015 09:42 AM, Max Reitz wrote: > Hi, > > Indeed using non-raw images should not be used over NBD. The warning > however is not superfluous, since qemu does indeed probe the image > format, so a malicious guest might write a qcow2 header into the raw > image, thus making qemu probe a qcow2 image the next time the same > configuration is used. The problem would be solved by not making qemu > probe the image format over NBD, but always assume raw; but I guess this > will break existing use cases, even though they were wrong from the > start. Anyway, this is solved by explicitly specifying the image format > to be raw, which is what the warning says.
I could actually see the use of non-raw over NBD. We support nested protocols (where you can use qcow2->qcow2->file), that is, where a file contains a qcow2 file whose contents are themselves a qcow2 image. (Perhaps useful in nested guests, where the outer qcow2 layer serves a disk to an L0 guest, which in turn uses the inner layer to present a disk to an L1 guest). In such a case, opening just one layer of qcow2 for service over NBD will expose the inner qcow2 image, and connecting qemu as an NBD client with format=raw will directly manipulate the qcow2 data seen by the L0 guest, while connecting as an NBD client with format=qcow2 will see the raw data seen by the L1 guest. But it's more likely to encounter this scenario with NBD, and not with vvfat. > > When it comes to vvfat, we might actually put up another warning saying > that vvfat is deprecated, but anyway: Here, too, the warning is > suppressed by doing what the warning says. Use -drive > format=raw,file.driver=vvfat,file.dir=. and the warning disappears (or > driver=raw instead of format=raw, it's the same). > > Concluding: Doing what the warning says makes it disappear (-drive > format=raw,…), which is, not coincidentally, the warning's purpose, > actually. If we want to do something about this, we would have to allow > protocols like NBD and vvfat be able to force the default image format > used on top of them (i.e. raw). But this may break existing use cases, > at least for NBD, so I'd be wary about that. Yeah, I don't have any objections to vvfat forcing raw, but I'm very reluctant to have NBD force raw. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
