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: Jeff Cody
Subject: Re: [Qemu-devel] [PATCH 0/3] vpc: support probing of fixed size images
Date: Fri, 15 Aug 2014 10:51:08 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Aug 15, 2014 at 08:22:12AM -0600, Eric Blake wrote:
> On 08/15/2014 08:10 AM, Jeff Cody wrote:
> > On Fri, Aug 15, 2014 at 08:00:19AM -0600, Eric Blake wrote:
> >> On 08/15/2014 07:37 AM, Kevin Wolf wrote:
> >>
> >>> We can choose Markus's suggestion of using the file name to guess the
> >>> format. I don't really like it much, but it seems like a fair compromise
> >>> that doesn't hurt usability as much.
> >>
> >> In other words, if a user gives a file a "known suffix", then it is
> >> their own fault if they made that file raw and the guest then happened
> >> to convert the file to the format matching the suffix?  Or would this
> >> start giving warnings if the known suffix doesn't match the probed 
> >> contents?
> >>
> > 
> > (Eric, I should have cc'ed you on my last email, sorry)
> > 
> > Image this scenario:
> > 
> >     existing chain created a while ago, via:
> > 
> >         qemu-img create -f qcow2 foo.img 1G
> >         qemu-img create -f qcow2 -b foo.img bar.img 1G
> > 
> 
> Libvirt refuses to create files without backing format encoded; but is
> still stuck dealing with files created externally (such as qemu-img
> create) where it was forgotten.
> 
> > 
> > User launches qemu by this commandline:
> > 
> >     qemu-kvm -drive file=bar.img,format=qcow2
> > 
> > 
> > Old behavior:
> > 
> >   | foo.img | <--- | bar.img |
> >   | (qcow2) |      | (qcow2) |
> > 
> > New behavior:
> > 
> >   | foo.img | <--- | bar.img |
> >   | (raw)   |      | (qcow2) |
> 
> Libvirt already assumed raw for any image where encoding was not
> specified, so this scenario is already a risky one for the user.
>

Right, but not all QEMU users are libvirt users.  And for standalone
QEMU users, it would be a behavior change, and one that leads to data
corruption.

> > 
> > 
> > So I think we want to make sure that we don't just fall back to raw
> > for unknown filename extensions.
> 
> Remember, if a probe determines a file is raw, it is safe to use as raw.
>  Falling back to raw is IDEAL.

I agree that, from the perspective of host security, assuming raw is
always safer.  However, that does NOT mean the ideal solution is to
parse filenames, and create fallbacks to raw that didn't happen
before.  I think the better scenario there is to decide we don't know
what we can do, and exit.

Option 1: Probe as usual, detect format.  Host UNSAFE.
Option 2: Probe differently, fall back to raw more aggressively. 
          Host SAFE, Guest may have data loss.  Requires rebase
          of backing chain to prevent data loss.
Option 3: Exit, and demand to be told the image format type.
          Host SAFE, Guest has no data loss.  Inconvenient; requires
          rebasing backing chain to open.
Option 4: Kevin's raw write prevent.  Not sure all the ramifications
          of this.

> 
> What _might_ be nice is teaching qemu-img to auto-encode the backing
> format during 'qemu-img create' (it can be assumed that _at creation
> time_, the backing file hasn't had a chance to be corrupted by the guest
> yet) rather than the current behavior of only encoding an explicit
> format given by the user.  

I agree qemu-img could use some change. When you look at the commandline 
'qemu-img create -f qcow2 bar.img -b foo.img', it is not
immediately intuitive that you should also have specified '-F qcow2'.
But I am not sure that it safe to assume that the backing file has not
been corrupted by the guest at this point!  The file foo.img may have
been around and in use for a while.  I think qemu-img should warn
loudly the backing format was not specified, and that this may be
unsafe.

>Furthermore, an explicit encoding from the
> user should ALWAYS be trusted, and the user can override any place where
> automatic heuristics would have guessed differently (whether those
> heuristics were based on probing, file extension, or otherwise).
> 

Definitely agree here.





reply via email to

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