qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH RFC 2/2] block: Warn on insecure format probing


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH RFC 2/2] block: Warn on insecure format probing
Date: Thu, 30 Oct 2014 14:02:29 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Max Reitz <address@hidden> 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?

[...]



reply via email to

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