From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47111) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XIIDi-0003uo-Jl for qemu-devel@nongnu.org; Fri, 15 Aug 2014 10:11:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XIIDc-0000yY-F0 for qemu-devel@nongnu.org; Fri, 15 Aug 2014 10:11:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6087) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XIIDc-0000yU-4v for qemu-devel@nongnu.org; Fri, 15 Aug 2014 10:11:00 -0400 Date: Fri, 15 Aug 2014 10:10:56 -0400 From: Jeff Cody Message-ID: <20140815141056.GA20938@localhost.localdomain> References: <1406900401-19550-1-git-send-email-lkurusa@redhat.com> <20140812132034.GM20490@stefanha-thinkpad.redhat.com> <20140812133542.GA6876@localhost.localdomain> <1643597569.19303034.1408027347194.JavaMail.zimbra@redhat.com> <20140814145733.GA2399@localhost.localdomain> <20140815105519.GC3770@noname.redhat.com> <20140815121402.GB2399@localhost.localdomain> <20140815133756.GF3770@noname.redhat.com> <53EE1273.7020303@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53EE1273.7020303@redhat.com> Subject: Re: [Qemu-devel] [PATCH 0/3] vpc: support probing of fixed size images List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Kevin Wolf , Levente Kurusa , Fam Zheng , Stefan Weil , Andrew Jones , QEMU Developers , Stefan Hajnoczi 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). >