[libvirt] [PATCH] libvirt no longer supports qemu format=host_device
Bug: https://launchpad.net/bugs/665531 The fixes for CVE-2010-2237, CVE-2010-2238 and CVE-2010-2239 broke format=host_device for the qemu driver. Qemu's host_device is used to specify raw files that don't have holes, so we need to treat <driver name='qemu' type='host_device'/> as raw in virDomainDiskDefForeachPath() (like we do for 'aio'). For example, the following xml is no longer valid, but should be: <disk type='file' device='disk'> <driver name='qemu' type='host_device'/> <source file='/tmp/foo.img'/> <target dev='hda' bus='ide'/> </disk> This is confirmed as not working on 0.8.3 and 0.8.5. The attached patch against 0.8.5 fixes the issue and restores host_device support. -- Jamie Strandboge | http://www.canonical.com
On Fri, Nov 05, 2010 at 02:04:50PM -0500, Jamie Strandboge wrote:
Bug: https://launchpad.net/bugs/665531
The fixes for CVE-2010-2237, CVE-2010-2238 and CVE-2010-2239 broke format=host_device for the qemu driver. Qemu's host_device is used to specify raw files that don't have holes, so we need to treat <driver name='qemu' type='host_device'/> as raw in virDomainDiskDefForeachPath() (like we do for 'aio'). For example, the following xml is no longer valid, but should be:
<disk type='file' device='disk'> <driver name='qemu' type='host_device'/> <source file='/tmp/foo.img'/> <target dev='hda' bus='ide'/> </disk>
This is confirmed as not working on 0.8.3 and 0.8.5. The attached patch against 0.8.5 fixes the issue and restores host_device support.
host_device is not a data format type, but rather a qemu driver protocol. As such it is not applicable for the <driver type=XXX> field, because the protocol is already specified at the <disk> element level with a combo of the type+device fields. If it happened to be possible to set it in the <driver> field that is just pure chance & not something that is supported. If we need to setup host_device anywhere, then this needs to be dealt with at the qemu_conf.c where we generate the CLI args. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Mon, 2010-11-08 at 10:02 +0000, Daniel P. Berrange wrote:
On Fri, Nov 05, 2010 at 02:04:50PM -0500, Jamie Strandboge wrote:>
This is confirmed as not working on 0.8.3 and 0.8.5. The attached patch against 0.8.5 fixes the issue and restores host_device support.
host_device is not a data format type, but rather a qemu driver protocol. As such it is not applicable for the <driver type=XXX> field, because the protocol is already specified at the <disk> element level with a combo of the type+device fields. If it happened to be possible to set it in the <driver> field that is just pure chance & not something that is supported. If we need to setup host_device anywhere, then this needs to be dealt with at the qemu_conf.c where we generate the CLI args.
Hmm... that is not clear in the documention IMHO (and the patch was careful to only use this for the qemu driver). Eg from the qemu-img man page: "Supported image file formats: raw ... host_device ... qcow2 ... ... " Ie, the language in the qemu-img man page has 'host_device' at the same level as 'raw', 'qcow2', 'cow', etc as a 'file format'. http://libvirt.org/formatdomain.html#elementsDisks only talks about a 'sub-type' for the qemu driver (but it is easy to infer that it is looking at the qemu-img types after using libvirt for a while) and http://libvirt.org/storage.html does not list 'host_device' as a 'format type', but it does list all of the other ones from the same section of the qemu-img man page (except 'vdi', which is maybe an omission in the libvirt docs?). Finally, 'man virsh' does list 'host_device' as a 'file format' in its 'vol-create-as' command. By all means if this needs to be cleaned up in qemu_conf.c that seems fine, but until then I feel that either host_device should be supported again (preferred based on the qemu-img man page) or the documentation made more consistent, and something probably added in http://libvirt.org/news.html for people upgrading to 0.8.3 or later since libvirt users are hitting this. -- Jamie Strandboge | http://www.canonical.com
On Mon, Nov 08, 2010 at 12:08:26PM -0600, Jamie Strandboge wrote:
On Mon, 2010-11-08 at 10:02 +0000, Daniel P. Berrange wrote:
On Fri, Nov 05, 2010 at 02:04:50PM -0500, Jamie Strandboge wrote:>
This is confirmed as not working on 0.8.3 and 0.8.5. The attached patch against 0.8.5 fixes the issue and restores host_device support.
host_device is not a data format type, but rather a qemu driver protocol. As such it is not applicable for the <driver type=XXX> field, because the protocol is already specified at the <disk> element level with a combo of the type+device fields. If it happened to be possible to set it in the <driver> field that is just pure chance & not something that is supported. If we need to setup host_device anywhere, then this needs to be dealt with at the qemu_conf.c where we generate the CLI args.
Hmm... that is not clear in the documention IMHO (and the patch was careful to only use this for the qemu driver). Eg from the qemu-img man page:
"Supported image file formats: raw ... host_device ... qcow2 ... ... "
Ie, the language in the qemu-img man page has 'host_device' at the same level as 'raw', 'qcow2', 'cow', etc as a 'file format'. http://libvirt.org/formatdomain.html#elementsDisks only talks about a 'sub-type' for the qemu driver (but it is easy to infer that it is looking at the qemu-img types after using libvirt for a while) and http://libvirt.org/storage.html does not list 'host_device' as a 'format type', but it does list all of the other ones from the same section of the qemu-img man page (except 'vdi', which is maybe an omission in the libvirt docs?). Finally, 'man virsh' does list 'host_device' as a 'file format' in its 'vol-create-as' command.
libvirt isn't intended to expose all qemu/qemu-img terminology directly. It isn't listed in the storage.html or formatdomain.html pages, because 'host_device' isn't a data format, rather it is a block driver access method. QEMU itself has been somewhat confused about the distinction of format vs driver access method, due to the fact that they've both implemented with the same code inside QEMU. You basically have two separate sets though formats: raw, cow, qcow, qcow2, vmdk, etc drivers: file, host_device, host_cdrom, host_floppy At the XML level, there is no need to specify the QEMU driver because this is already represented at the main <disk> element by the type+device attributes. The fact that it happened to be possible to indirectly use it via the <driver> format attribute is just a lucky coincidence of the way QEMU parses the command line arg for 'format='. It is not intentionally supported by QEMU in this manner, nor by libvirt. Ultimately libvirt QEMU driver never sets any driver protocol when generating QEMU argv because thus far it has never been required, since QEMU auto chooses the driver protocol correctly. The virsh manpage reference is a bug unfortunately introduced in b28a068b430d430d08b7b72fdc2ffc2deb58fa4c. Anyone who has tried to set host_device in the <driver> can just remove that setting. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (2)
-
Daniel P. Berrange -
Jamie Strandboge