Re: [Qemu-devel] [Bug 1474263] Re: "Image format was not specified" warning should be suppressed for the vvfat (and probably nbd) driver

[Stefan Hajnoczi <stefanha@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]