[Qemu-devel] [Bug 1474263] Re: "Image format was not specified" warning should be suppressed for the vvfat (and probably nbd) driver
Yes, it does appear, you just need to make vvfat rw:
$ qemu-system-x86_64 -drive file.driver=vvfat,file.dir=foo,file.rw=on
vvfat foo chs 1024,16,63
WARNING: Image format was not specified for 'json:{"dir": "foo", "driver":
"vvfat", "rw": "on"}' and probing guessed raw.
Automatically detecting the format is dangerous for raw images, write
operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
(The warning is not shown with R/O devices because they don’t have the
security issue.)
My point hasn’t changed, though, I fundamentally agree with the points
in this report, but I don‘t think “fixing” this is worth it.
For NBD, “fixing” it would mean potentially breaking existing use cases
(which I still don’t see the point of, but there’s no point in breaking
them just to make a warning disappear).
For vvfat, there are three things: First of all, I don’t like it very much, so
as I said, I’d rather deprecate it altogether (though this BZ shows we
shouldn’t do that).
Secondly, in order for the warning to disappear, a protocol driver would need
to enforce a certain format on top when probing. That would require a bit of
new infrastructure, although I have to admit it wouldn’t be impossible.
Thirdly, I suppose most people use vvfat with block device options like done in
the bug report? In that case, it is trivial to add a format=raw (or
driver=raw), exactly like the warning suggests.
(Though you can use vvfat with a plain filename, too:
$ qemu-system-x86_64 fat:32:rw:foo
qemu-system-x86_64: warning: FAT32 has not been tested. You are welcome to do
so!
vvfat foo chs 1024,16,63
WARNING: Image format was not specified for 'json:{"fat-type": 32, "dir":
"foo", "driver": "vvfat", "floppy": false, "rw": true}' and probing guessed raw.
Automatically detecting the format is dangerous for raw images, write
operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
)
So all in all I think this is indeed kind of a bug (at least it’s a
nuisance that could be better), fixing it would not be impossible, but
it’s just very low on at least my priority list (probably somewhere
around “implement bdrv_refresh_filename() for vvfat so you don't get the
json:{} filenames you can see above”).
Max
** Changed in: qemu
Status: Incomplete => Opinion
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1474263
Title:
"Image format was not specified" warning should be suppressed for the
vvfat (and probably nbd) driver
Status in QEMU:
Opinion
Bug description:
Running
qemu -drive file.driver=vvfat,file.dir=.
displays
WARNING: Image format was not specified for 'json:{"dir": ".", "driver":
"vvfat"}' and probing guessed raw.
Automatically detecting the format is dangerous for raw images,
write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
However, since "images" provided by the vvfat driver are always raw
(and the first sector isn't writeable in any case), this warning is
superfluous and should not be displayed.
A similar warning is displayed for NBD devices; I suspect it should be
also disabled for similar reasons, but I'm not sure if serving non-raw
images is actually a violation of the protocol. qemu-nbd translates
them to raw images, for what it's worth, even if it may be suppressed
with -f raw.
Noticed on 2.3.0; the code that causes this behaviour is still
apparently present in today's git master
(f3a1b5068cea303a55e2a21a97e66d057eaae638). Speaking of versions: you
may want to update the copyright notice that qemu -version displays.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1474263/+subscriptions
[Qemu-devel] [Bug 1474263] Re: "Image format was not specified" warning should be suppressed for the vvfat (and probably nbd) driver
Looking through old bug tickets... can you still reproduce this bug
with the latest version of QEMU? At least for vvfat, the warning message
does not seem to occur anymore.
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1474263
Title:
"Image format was not specified" warning should be suppressed for the
vvfat (and probably nbd) driver
Status in QEMU:
Incomplete
Bug description:
Running
qemu -drive file.driver=vvfat,file.dir=.
displays
WARNING: Image format was not specified for 'json:{"dir": ".", "driver":
"vvfat"}' and probing guessed raw.
Automatically detecting the format is dangerous for raw images,
write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
However, since "images" provided by the vvfat driver are always raw
(and the first sector isn't writeable in any case), this warning is
superfluous and should not be displayed.
A similar warning is displayed for NBD devices; I suspect it should be
also disabled for similar reasons, but I'm not sure if serving non-raw
images is actually a violation of the protocol. qemu-nbd translates
them to raw images, for what it's worth, even if it may be suppressed
with -f raw.
Noticed on 2.3.0; the code that causes this behaviour is still
apparently present in today's git master
(f3a1b5068cea303a55e2a21a97e66d057eaae638). Speaking of versions: you
may want to update the copyright notice that qemu -version displays.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1474263/+subscriptions
[Qemu-devel] [Bug 1474263] Re: "Image format was not specified" warning should be suppressed for the vvfat (and probably nbd) driver
> 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.
Seems like an academic exercise, really. But if this use case is
practical, I believe three levels of wrapping is just as useful, and the
only way to work with that one is to run two or three instances of qemu-
nbd. With more layers, the set-up quickly becomes tangled and
unmanageable.
And I still doubt anyone would actually want to create a set-up like
this. It seems incredibly wasteful (but then, so is virtualisation in
general, so maybe that isn't an issue) and doesn't seem to accomplish
anything that couldn't be done with just one layer of wrapping.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1474263
Title:
"Image format was not specified" warning should be suppressed for the
vvfat (and probably nbd) driver
Status in QEMU:
New
Bug description:
Running
qemu -drive file.driver=vvfat,file.dir=.
displays
WARNING: Image format was not specified for 'json:{"dir": ".", "driver":
"vvfat"}' and probing guessed raw.
Automatically detecting the format is dangerous for raw images,
write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
However, since "images" provided by the vvfat driver are always raw
(and the first sector isn't writeable in any case), this warning is
superfluous and should not be displayed.
A similar warning is displayed for NBD devices; I suspect it should be
also disabled for similar reasons, but I'm not sure if serving non-raw
images is actually a violation of the protocol. qemu-nbd translates
them to raw images, for what it's worth, even if it may be suppressed
with -f raw.
Noticed on 2.3.0; the code that causes this behaviour is still
apparently present in today's git master
(f3a1b5068cea303a55e2a21a97e66d057eaae638). Speaking of versions: you
may want to update the copyright notice that qemu -version displays.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1474263/+subscriptions
Re: [Qemu-devel] [Bug 1474263] Re: Image format was not specified warning should be suppressed for the vvfat (and probably nbd) driver
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
Re: [Qemu-devel] [Bug 1474263] Re: Image format was not specified warning should be suppressed for the vvfat (and probably nbd) driver
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
[Qemu-devel] [Bug 1474263] Re: Image format was not specified warning should be suppressed for the vvfat (and probably nbd) driver
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.
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.
Max
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1474263
Title:
Image format was not specified warning should be suppressed for the
vvfat (and probably nbd) driver
Status in QEMU:
New
Bug description:
Running
qemu -drive file.driver=vvfat,file.dir=.
displays
WARNING: Image format was not specified for 'json:{dir: ., driver:
vvfat}' and probing guessed raw.
Automatically detecting the format is dangerous for raw images,
write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
However, since images provided by the vvfat driver are always raw
(and the first sector isn't writeable in any case), this warning is
superfluous and should not be displayed.
A similar warning is displayed for NBD devices; I suspect it should be
also disabled for similar reasons, but I'm not sure if serving non-raw
images is actually a violation of the protocol. qemu-nbd translates
them to raw images, for what it's worth, even if it may be suppressed
with -f raw.
Noticed on 2.3.0; the code that causes this behaviour is still
apparently present in today's git master
(f3a1b5068cea303a55e2a21a97e66d057eaae638). Speaking of versions: you
may want to update the copyright notice that qemu -version displays.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1474263/+subscriptions
