On Wed, Jul 15, 2015 at 10:54:47AM -0600, Eric Blake wrote: > 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.
I agree that it's perfectly okay to use non-raw on top of NBD. We allow image formats on host block devices and iSCSI LUNs. Why shouldn't they be allowed on NBD exports? Stefan
pgp8CmTZLbvHt.pgp
Description: PGP signature
