Re: [Qemu-devel] RFC v3: blockdev_add & friends, brief rationale, QMP docs

[Markus Armbruster <armbru@redhat.com>]

Stefan Hajnoczi <stefanha@gmail.com> writes:

> On Thu, Jun 17, 2010 at 1:49 PM, Markus Armbruster <armbru@redhat.com> wrote:
>> Stefan Hajnoczi <stefanha@gmail.com> writes:
>>
>>> On Wed, Jun 16, 2010 at 6:27 PM, Markus Armbruster <armbru@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.