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
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) |
So I think we want to make sure that we don't just fall back to raw
for unknown filename extensions.
> >
> > If we don't want this, we can approach the problem from a different
> > angle: The problem is not probing per se, but that images probed as raw
> > can be written to by guests in a way that the next time they are probed
> > as something else.
> >
> > What if we let the raw driver know that it was probed and then it
> > enables a check that returns -EIO for any write on the first 2k if that
> > write would make the image look like a different format?
>
> Not entirely future-proof - as we add support for more formats over
> time, something that passes today could fail in the future. Worse, a
> guest could exploit an older qemu to write a header that a newer qemu
> would reject. But it does sound like an interesting approach
> (preventing the guest from doing something risky).
>
