Re: [Qemu-devel] [PATCH 1/6] libqblock APIs

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2444 bytes --]

On 09/04/2012 12:42 AM, Wenchao Xia wrote:
>>> +/**
>>> + * libqblock_init: Initialize the library
>>> + */
>>> +void libqblock_init(void);
>>
>> Is this function safe to call more than once?  Even tighter, is it safe
>> to call this function simultaneously from multiple threads?
>>
>   No, it should be only called once, any other thread should not call
> it again, will document it. About the multiple thread user case, qemu
> block layer can't support that now, will fix that later.

What a shame.  That makes libraries much harder to use.  It is much
nicer to design a library where the initialization is idempotent and
thread-safe, to be called from multiple threads.  Consider:

app links against liba and libb;
liba links against libqb
libb links against libqb

How am I supposed to write liba and libb to guarantee only one single
race-free call to libqblock_init, unless libqblock_init() is idempotent?

Also, should there be a counterpart function for tearing down the
resources used by the library when it is no longer needed?  If so, then
that implies reference counting - each call to init atomically increases
the refcount, and the library frees resources only when the refcount
atomically goes back to 0.


>>> + * @fmt: format options, how to extract the data, only valid member
>>> now is
>>> +     fmt->fmt_type, set NULL if you want auto discovery the format.
>>
>> set to NULL if you want to auto-discover the format
>>
>> Maybe also add a warning about the inherent security risks of attempting
>> format auto-discovery (any raw image must NOT be probed, as the raw
>> image can emulate any other format and cause qemu to chase down chains
>> where it should not).
>>
>   it seems qemu-img could find out that an image is raw correctly by
> probing, do you mean give a warning saying that this image is probably
> some formats that qemu do not supported, such as virtual box's image?

No, you got it backwards.  For all non-raw images, qemu can correctly
probe the image.  But for raw images, the guest may have set enough
information in the image to make a probe _think_ that the image is
non-raw, and therefore cause qemu to misbehave.  That is, the security
hole is choosing to probe a raw image, because the probe will not always
successfully return raw.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 617 bytes --]