All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Bug 1474263 <1474263@bugs.launchpad.net>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Bug 1474263] Re: "Image format was not specified" warning should be suppressed for the vvfat (and probably nbd) driver
Date: Wed, 15 Jul 2015 10:54:47 -0600	[thread overview]
Message-ID: <55A69057.9080704@redhat.com> (raw)
In-Reply-To: <20150715154236.29903.62706.malone@gac.canonical.com>

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

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2015-07-15 16:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-14  8:57 [Qemu-devel] [Bug 1474263] [NEW] "Image format was not specified" warning should be suppressed for the vvfat (and probably nbd) driver felix
2015-07-15 15:42 ` [Qemu-devel] [Bug 1474263] " Max Reitz
2015-07-15 16:54   ` Eric Blake [this message]
2015-07-16 13:29     ` Stefan Hajnoczi
2016-07-05  7:19 ` felix
2018-07-11  7:10 ` Thomas Huth
2018-07-11 11:18 ` Max Reitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55A69057.9080704@redhat.com \
    --to=eblake@redhat.com \
    --cc=1474263@bugs.launchpad.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.