[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/6] libqblock APIs
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH 1/6] libqblock APIs |
Date: |
Tue, 04 Sep 2012 05:35:41 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 |
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 address@hidden +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
- Re: [Qemu-devel] [PATCH 1/6] libqblock APIs, (continued)
Re: [Qemu-devel] [PATCH 1/6] libqblock APIs, Eric Blake, 2012/09/03
Re: [Qemu-devel] [PATCH 1/6] libqblock APIs, Wenchao Xia, 2012/09/04
Re: [Qemu-devel] [PATCH 1/6] libqblock APIs,
Eric Blake <=
Re: [Qemu-devel] [PATCH 1/6] libqblock APIs, Paolo Bonzini, 2012/09/04
Re: [Qemu-devel] [PATCH 1/6] libqblock APIs, Blue Swirl, 2012/09/03
[Qemu-devel] [PATCH 3/6] libqblock error handling, Wenchao Xia, 2012/09/03
[Qemu-devel] [PATCH 5/6] libqblock test example, Wenchao Xia, 2012/09/03
[Qemu-devel] [PATCH 4/6] libqblock internal used functions, Wenchao Xia, 2012/09/03