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: Wed, 29 Oct 2014 08:22:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Eric Blake <address@hidden> writes:

> On 10/28/2014 12:29 PM, Jeff Cody wrote:
[...]
>>> What happens if more than one format tends to pick the same extension?
>>> For example, would you consider '.qcow' a typical extension for qcow2
>>> files, even though it would probably match the older qcow driver first?...
>>>
>> 
>> I think this could arguably end up being the case for VHD and VHDX
>> (i.e., both using .vhd).
>> 
>> I guess the question is, in the case of common extensions, should the
>> priority be on the probe, or on the extension?  With the way the code
>> is written, the priority is all going to depend on the order the
>> driver is registered, so it may or may not warn.
>
> Technically, don't we correctly probe both VHD and VHDX files?  It is
> only files that start out raw and later get mis-probed as non-raw where
> we have an issue, so I'd rather treat the probe as accurate if it
> matches a common extension for that format, and NOT treat the extension
> as dictating a single required format.
>
>> 
>> Currently, the code does a format probe, does an independent extension
>> lookup, and checks if the two agree.  Instead, would it be sufficient
>> to do the format probe, and then just verify the detected driver has a
>> compatible extension name?
>
> Yes, that was what I was thinking as well.

I designed the code with the eventual removal of probing in mind:

    This should steer users away from insecure format probing.  After a
    suitable grace period, we can hopefully drop format probing
    alltogether.

The warning triggers on insecure probing.  That's one view of it.  The
other view is it triggers when potentially insecure probing and our new
secure guessing come up with different answers.  It serves as warning of
future behavioral change.

If we only check the extension matches the probing, we gain support for
ambiguous file name extensions, but make the future change warning
incomplete.  That's bad.

If .vhd can really be two formats so different we actually want to
separate block drivers for them, we want something more sophisticated
than my patch.  Need to think.



reply via email to

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