qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Krempa <pkrempa@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: libvir-list@redhat.com, qemu-devel@nongnu.org,
	qemu-block@nongnu.org, mreitz@redhat.com
Subject: Re: [PATCH 0/3] Tighten qemu-img rules on missing backing format
Date: Mon, 24 Feb 2020 12:01:45 +0100	[thread overview]
Message-ID: <20200224110145.GB3296@andariel.pipo.sk> (raw)
In-Reply-To: <20200222112341.4170045-1-eblake@redhat.com>

On Sat, Feb 22, 2020 at 05:23:38 -0600, Eric Blake wrote:
> In the past, we have had CVEs caused by qemu probing one image type
> when an image started out as another but the guest was able to modify
> content.  The solution to those CVEs was to encode backing format
> information into qcow2, to ensure that once we make a decision, we
> don't have to probe any further.  However, we failed to enforce this
> at the time.  And now that libvirt is switching to -blockdev, it has
> come back to bite us: with -block, libvirt had no easy way (other than

s/-block/-drive/ ?

> json:{} pseudoprotocol) to force a backing file, but with -blockdev,

"json:{}" is basically -blockdev with extra steps. Old -drive usage
didn't have any way to do that apart from rewriting the image. Which is
basically the same since json:{} also needs to be recorded in the image
to take effect.

> libvirt HAS to use blockdev-open on the backing chain and supply a
> backing format there, and thus has to probe images.  If libvirt ever
> probes differently than qemu, we are back to the potential
> guest-visible data corruption or potential host CVEs.

As I've elaborated in [1] I disagree with the host CVE part. The
insecure part is not probing the format itself, but probing format AND
using the backing file of the image if we probed format.

I agree that mis-probing format leads to data corruption though.

> It's time to deprecate images without backing formats.  This patch
> series does two things: 1. record an implicit backing format where one
> is learned (although sadly, not all qemu-img commands are able to
> learn a format), 2. warn to the user any time a probe had ambiguous
> results or a backing format is omitted from an image.  All previous
> images without a backing format are still usable, but hopefully the
> warnings (along with libvirt's complaints about images without a
> backing format) help us pinpoint remaining applications that are

It is not a warning in libvirt though. We just refuse it now because we
don't do probing. Previously we allowed qemu to probe the format and the
only thing that prevented host CVEs was if the host used selinux or any
other security approach which would prevent opening the backing file.

> creating images on their own without recording a backing format.



  parent reply	other threads:[~2020-02-24 11:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-22 11:23 [PATCH 0/3] Tighten qemu-img rules on missing backing format Eric Blake
2020-02-22 11:23 ` [PATCH 1/3] iotests: Specify explicit backing format where sensible Eric Blake
2020-02-22 11:23 ` [PATCH 2/3] block: Add support to warn on backing file change without format Eric Blake
2020-02-22 11:23 ` [PATCH 3/3] qemu-img: Deprecate use of -b without -F Eric Blake
2020-02-24 11:38   ` Peter Krempa
2020-02-24 16:08     ` Eric Blake
2020-02-24 17:28       ` Peter Krempa
2020-02-24 11:01 ` Peter Krempa [this message]
2020-02-24 11:43   ` [PATCH 0/3] Tighten qemu-img rules on missing backing format Peter Krempa
2020-02-24 16:14   ` 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=20200224110145.GB3296@andariel.pipo.sk \
    --to=pkrempa@redhat.com \
    --cc=eblake@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).