qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/3] vpc: support probing of fixed size images


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 0/3] vpc: support probing of fixed size images
Date: Fri, 15 Aug 2014 12:55:19 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 14.08.2014 um 16:57 hat Jeff Cody geschrieben:
> On Thu, Aug 14, 2014 at 10:42:27AM -0400, Levente Kurusa wrote:
> > On Tuesday, 12 August, 2014 3:35:42 PM, Jeff Cody wrote:
> > > On Tue, Aug 12, 2014 at 02:20:34PM +0100, Stefan Hajnoczi wrote:
> > > > On Fri, Aug 01, 2014 at 03:39:58PM +0200, Levente Kurusa wrote:
> > > > > Fixed size VPC images do not have a footer, hence the current probe
> > > > > function will fail and QEMU will fall back to the raw_bsd driver, 
> > > > > which
> > > > > is
> > > > > not the correct behaviour. The specification of the format says that
> > > > > fixed
> > > > > size images have a footer as the last 512 bytes of the file. The 
> > > > > footer
> > > > > is
> > > > > exactly the same as the header would be in the case of dynamically
> > > > > growing
> > > > > images.
> > > > > 
> > > > > For this, we need to read the last 512 bytes of the image, however the
> > > > > current mechanics predominantly read the first 2048 bytes and pass 
> > > > > that
> > > > > as a buffer to the probe functions. Solve this by passing the
> > > > > BlockDriverState to the probe functions, hence giving them a chance to
> > > > > read
> > > > > the extra bytes they might need.
> > > > 
> > > > I hesitate to add patches that extend image format probing.  For the
> > > > past few years we have always recommended that image files should not be
> > > > probed.
> > > > 
> > > > Image probing is prone to security issues because a malicious guest can
> > > > modify a raw or vpc image by putting another image format header at
> > > > sector 0.  The next time QEMU opens the image it will detect a different
> > > > format.  One evil trick is to refer to a file on the host file system as
> > > > the backing file, now you can read any file that the QEMU process has
> > > > access to.
> > 
> > Yea, good point. The current state of probing is actually quite bad,
> > just take a look at dmg_probe in block/dmg.c :-(
> > 
> > > > 
> > > > Probing also complicates live migration.  The source host still has the
> > > > image file open and may write to it.  The destination host shouldn't
> > > > even read from the image file before handover to avoid file cache
> > > > coherency issues.
> > > > 
> > > > Probing is broken.  It shouldn't be used.  We shouldn't extend it
> > > > (especially by adding more I/Os).
> > 
> > Even though, my series would have only added one extra I/O in the case
> > of failing VPC images, I have to admit you are right.
> > 
> > > 
> > > For 2.2, maybe we should limit probing to only certain operations (e.g.
> > > qemu-img info) - or perhaps just remove the capability altogether, or
> > > at least start phasing it out with a warning message that automatic
> > > format detection is deprecated and may be unsafe.
> > > 
> > 
> > Considering the fact that most open functions already check the magic
> > numbers, and they do a lot better/safer job at it, we could just swap
> > the probe functions with the open ones and just insert an fprintf
> > when format is not specified doing what Jeff suggested.
> > 
> > Any objections to this?
> > 
> > (This would also solve the VPC-fixed-size bug, since vpc_open already
> > checks the footer if the header is not found)
> >
> 
> I was proposing actually going a bit further than this, and not
> allowing automatic format detection at all, with an exception for
> 'qemu-img info'. In the interim, until that is in place and it is
> removed, warn with a deprecation message.

No, we can't do this. It would immediately destroy -hda and similar
convenience options and make the command line really hard to use even
for simple cases. I usually call qemu manually and I specify format
basically _never_, because it would like double the length of my command
line (okay, not quite, but my command lines are usually very short) and
I know what I'm doing and I'm running trusted guests.

Plus, there are probably many scripts out there that rely on it.

A more reasonable approach would be to just forbid probing raw and
raw-like formats like VHD fixed (the rest should be safe), but I think
the impact of this would still be too bad.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]