From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, pkrempa@redhat.com,
mreitz@redhat.com, libvir-list@redhat.com,
Liu Yuan <namei.unix@gmail.com>, Fam Zheng <fam@euphon.net>,
Michael Tokarev <mjt@tls.msk.ru>,
Laurent Vivier <laurent@vivier.eu>,
"open list:Sheepdog" <sheepdog@lists.wpkg.org>,
"open list:Trivial patches" <qemu-trivial@nongnu.org>
Subject: Re: [PATCH v3 1/4] block: Add trivial backing_fmt support to qcow, sheepdog, vmdk
Date: Mon, 9 Mar 2020 16:21:12 +0100 [thread overview]
Message-ID: <20200309152112.GC6478@linux.fritz.box> (raw)
In-Reply-To: <20200306225121.3199279-2-eblake@redhat.com>
Am 06.03.2020 um 23:51 hat Eric Blake geschrieben:
> For qcow2 and qed, we want to encourage the use of -F always, as these
> formats can suffer from data corruption or security holes if backing
> format is probed. But for other formats, the backing format cannot be
> recorded. Making the user decide on a per-format basis whether to
> supply a backing format string is awkward, better is to just blindly
> accept a backing format argument even if it is ignored by the
> contraints of the format at hand.
>
> Signed-off-by: Eric Blake <eblake@redhat.com>
I'm not sure if I agree with this reasoning. Accepting and silently
ignoring -F could give users a false sense of security. If I specify a
-F raw and QEMU later probes qcow2, that would be very surprising.
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Fam Zheng <fam@euphon.net>,
pkrempa@redhat.com,
"open list:Sheepdog" <sheepdog@lists.wpkg.org>,
qemu-block@nongnu.org, libvir-list@redhat.com,
Michael Tokarev <mjt@tls.msk.ru>,
qemu-devel@nongnu.org, mreitz@redhat.com,
"open list:Trivial patches" <qemu-trivial@nongnu.org>,
Liu Yuan <namei.unix@gmail.com>,
Laurent Vivier <laurent@vivier.eu>
Subject: Re: [PATCH v3 1/4] block: Add trivial backing_fmt support to qcow, sheepdog, vmdk
Date: Mon, 9 Mar 2020 16:21:12 +0100 [thread overview]
Message-ID: <20200309152112.GC6478@linux.fritz.box> (raw)
In-Reply-To: <20200306225121.3199279-2-eblake@redhat.com>
Am 06.03.2020 um 23:51 hat Eric Blake geschrieben:
> For qcow2 and qed, we want to encourage the use of -F always, as these
> formats can suffer from data corruption or security holes if backing
> format is probed. But for other formats, the backing format cannot be
> recorded. Making the user decide on a per-format basis whether to
> supply a backing format string is awkward, better is to just blindly
> accept a backing format argument even if it is ignored by the
> contraints of the format at hand.
>
> Signed-off-by: Eric Blake <eblake@redhat.com>
I'm not sure if I agree with this reasoning. Accepting and silently
ignoring -F could give users a false sense of security. If I specify a
-F raw and QEMU later probes qcow2, that would be very surprising.
Kevin
next prev parent reply other threads:[~2020-03-09 15:21 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-06 22:51 [PATCH v3 0/4] Tighten qemu-img rules on missing backing format Eric Blake
2020-03-06 22:51 ` [PATCH v3 1/4] block: Add trivial backing_fmt support to qcow, sheepdog, vmdk Eric Blake
2020-03-06 22:51 ` Eric Blake
2020-03-09 15:21 ` Kevin Wolf [this message]
2020-03-09 15:21 ` Kevin Wolf
2020-03-09 15:32 ` Eric Blake
2020-03-09 15:32 ` Eric Blake
2020-03-09 15:44 ` Daniel P. Berrangé
2020-03-09 15:52 ` Eric Blake
2020-03-09 15:57 ` Kevin Wolf
2020-03-09 15:57 ` Kevin Wolf
2020-03-09 15:48 ` Kevin Wolf
2020-03-09 15:48 ` Kevin Wolf
2020-03-09 15:55 ` Eric Blake
2020-03-09 15:55 ` Eric Blake
2020-03-09 15:36 ` Daniel P. Berrangé
2020-03-09 15:36 ` Daniel P. Berrangé
2020-03-09 15:50 ` Eric Blake
2020-03-06 22:51 ` [PATCH v3 2/4] iotests: Specify explicit backing format where sensible Eric Blake
2020-03-06 22:51 ` [PATCH v3 3/4] block: Add support to warn on backing file change without format Eric Blake
2020-03-06 22:51 ` [PATCH v3 4/4] qemu-img: Deprecate use of -b without -F Eric Blake
2020-03-09 15:31 ` Kashyap Chamarthy
2020-03-09 15:42 ` Eric Blake
2020-03-10 9:47 ` Kashyap Chamarthy
2020-03-10 12:15 ` Eric Blake
2020-03-10 14:53 ` Kashyap Chamarthy
2020-03-10 10:57 ` Kashyap Chamarthy
2020-03-10 12:17 ` Eric Blake
2020-03-10 12:19 ` Eric Blake
2020-03-10 14:50 ` Kashyap Chamarthy
2020-03-13 18:20 ` Eric Blake
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=20200309152112.GC6478@linux.fritz.box \
--to=kwolf@redhat.com \
--cc=eblake@redhat.com \
--cc=fam@euphon.net \
--cc=laurent@vivier.eu \
--cc=libvir-list@redhat.com \
--cc=mjt@tls.msk.ru \
--cc=mreitz@redhat.com \
--cc=namei.unix@gmail.com \
--cc=pkrempa@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.org \
--cc=sheepdog@lists.wpkg.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.