From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49552) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlDFc-0002nD-Vx for qemu-devel@nongnu.org; Mon, 03 Nov 2014 03:44:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlDFW-0008Ny-QJ for qemu-devel@nongnu.org; Mon, 03 Nov 2014 03:44:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48603) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlDFW-0008Nt-He for qemu-devel@nongnu.org; Mon, 03 Nov 2014 03:44:30 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA38iTej024935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 3 Nov 2014 03:44:29 -0500 Message-ID: <5457406A.9090605@redhat.com> Date: Mon, 03 Nov 2014 09:44:26 +0100 From: Max Reitz MIME-Version: 1.0 References: <1414512220-19058-1-git-send-email-armbru@redhat.com> <1414512220-19058-3-git-send-email-armbru@redhat.com> <5452001E.9070907@redhat.com> <87egtpzp5m.fsf@blackfin.pond.sub.org> In-Reply-To: <87egtpzp5m.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC 2/2] block: Warn on insecure format probing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, jcody@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com On 2014-10-30 at 14:02, Markus Armbruster wrote: > Max Reitz writes: > >> So I guess it's my turn to give yet another opinion (or just something >> in between of what has been already said). >> >> First, I'm fine with this patch, or at least the idea as there were >> yet some quirks. > Yes, the patch has (fixable) issues. It's really just a sketch that > happens to work in common cases :) > >> But I oppose turning the warning into an error eventually. I want to >> be able to use -hda $filename and it should work. As Kevin said, a >> warning alone will not help a lot, though. I don't know about that, I >> think it should work. This warning should only appear when you're >> using qemu directly because management tools should already use -drive >> with format= or driver=; and if you're using qemu directly you should >> be watching stderr. >> >> The only way I'd be fine with turning this into an error would be to >> make an exception for -hda and the like. There were already plans of >> introducing pseudo block drivers for format and protocol probing; if >> we do that we can use those block drivers for -hda. We should still >> emit the warning, but in my opinion it should never be an error with >> -hda, -cdrom etc.. For me, this is not about backwards compatibility >> but because I'm using -hda myself. > Examples of usage that is just fine (no warning): > > * -hda test.qcow2 > > Fine as long as test.qcow2 is really qcow2 (as it should!), and > either specifies a backing format (as it arguably should), or the > backing file name is sane. > > * -hda disk.img > > Fine as long as disk.img is really a disk image (as it should). > > * -hda /dev/mapper/vg0-virtdisk > > Fine as long as the logical volume is raw. Not actually implemented > in my patch, but it's easy enough to do. > > Can you give me a few examples from your usage that triggers the > warning? You're right, I mistook making it an error if extension and probed format do not match for disabling probing completely. In that case I'm withdrawing my objection, though I still don't object Kevin's proposal either. Max