Stefan Hajnoczi <stefa...@gmail.com> writes:
> On Thu, Jun 17, 2010 at 1:49 PM, Markus Armbruster <arm...@redhat.com> wrote:
>> Stefan Hajnoczi <stefa...@gmail.com> writes:
>>
>>> On Wed, Jun 16, 2010 at 6:27 PM, Markus Armbruster <arm...@redhat.com>
>>> wrote:
>>>> blockdev_add
>>>> ------------
>>>>
>>>> Add host block device.
>>>>
>>>> Arguments:
>>>>
>>>> - "id": the host block device's ID, must be unique (json-string)
>>>> - "format": image format (json-string, optional)
>>>> - Possible values: "raw", "qcow2", ...
>>>
>>> What is the default when unset? (I expect we'll auto-detect the
>>> format but this should be documented.)
>>
>> For command line and human monitor, we definitely want a sensible
>> default. I sketched one in section "Command line syntax". I'll quote
>> it for your convenience a few lines down.
>
> Ahem...the part that I skipped over ;). I should have read your
> entire email, thanks for pointing it out.
:)
>> To let users ask for this explicitely, we could have pseudo-format
>> "auto".
>>
>> We also need a pseudo-format "probe", which guesses the format from the
>> image contents. Can't be made the default, because it's insecure.
>
> In which scenario is probing the image format a security issue? I'm
> trying to think up scenarios where a cloud user modifies the guest
> disk image and gets QEMU to re-open the image file as another format,
> perhaps this would make the cloud owner/admin unhappy. I don't see a
> threat except for image format drivers have security bugs (corrupt
> images leading to arbitrary code execution).
User creates a raw image file.
VM starts. Image file gets probed, it's raw. Guest has access to the
complete file.
Guest writes a valid QCOW2 image to it, chosen to include the full
backing file in the resulting image contents. Set the backing file to
/secret/treasure.
Reboot VM. Image file gets probed, it's qcow2. Backing file gets
probed, it's raw. Guest has access to the contents of QCOW2 image.
This includes the backing file. Oops.
>>>> (2) It's possible to list supported disk formats and protocols by
>>>> running QEMU with arguments "-blockdev_add \?".
>>>
>>> Is there an query-block-driver command or something in QMP to
>>> enumerate supported formats and protocols? Not sure how useful this
>>> would be to the management stack - blockdev_add will probably return
>>> an error if an attempt is made to open an unsupported file.
>>
>> QMP should be "self-documenting": a client should be able to list
>> commands, their arguments, and possible argument values. Listing
>> supported formats then becomes "list possible values of command
>> blockdev_add's argument format".
>
> Nice :).
We still need to deliver the niceties...
>>>> blockdev_del
>>>> ------------
>>>>
>>>> Remove a host block device.
>>>>
>>>> Arguments:
>>>>
>>>> - "id": the host block device's ID (json-string)
>>>>
>>>> Example:
>>>>
>>>> -> { "execute": "blockdev_del", "arguments": { "id": "blk1" } }
>>>> <- { "return": {} }
>>>
>>> What about an attached guest device? Will this fail if the virtio-blk
>>> PCI device is still present? For SCSI I imagine we can usually just
>>> remove the host block device. For IDE there isn't hotplug support
>>> AFAIK, what happens?
>>
>> Command fails. You have to device_del the device first. Which is only
>> possible if its bus supports hot-plug.
>
> I think this deserves to be in the documentation.
Yes, QMP documentation should cover errors. It generally doesn't so far.
