On 12/22/2011 11:39 AM, Laine Stump wrote: > As a result of CVE-2011-4127 (see: > http://seclists.org/oss-sec/2011/q4/536), qemu (and the kernel) now > disable all SG_IO commands on disks via qemu by default. To continue > providing this capability to those who specifically ask for it (and > hopefully understand the risks), a new libvirt disk type has been > created. > > This new disk type is identical to disk type='block', except that: > > 1) It is only allowed if bus='virtio' and the qemu version is "new > enough" to support it ("new enough" == qemu 0.11 or better), > otherwise the domain will fail to start and a CONFIG_UNSUPPORTED > error will be logged). > > 2) The option "scsi=on" will be added to the -device arg to allow > SG_IO commands (if type!='lun', "scsi=off" will be added to the > -device arg so that SG_IO commands are forbidden). > > Guests which continue to use disk type='block' will no longer be able > to use SG_IO commands on the disk; those that have their disk type > changed to type='lun' will still be able to use SG_IO commands. > <dd>If the disk <code>type</code> is "file", then > the <code>file</code> attribute specifies the fully-qualified > path to the file holding the disk. If the disk > - <code>type</code> is "block", then the <code>dev</code> > + <code>type</code> is "block" or "lun", then the <code>dev</code> > attribute specifies the path to the host device to serve as > - the disk. If the disk <code>type</code> is "dir", then the > - <code>dir</code> attribute specifies the fully-qualified path > - to the directory to use as the disk. If the disk <code>type</code> > - is "network", then the <code>protocol</code> attribute specifies > - the protocol to access to the requested image; possible values > - are "nbd", "rbd", and "sheepdog". If the <code>protocol</code> > - attribute is "rbd" or "sheepdog", an additional > + the disk ("lun" is only valid if the <code>target > + bus="virtio"</code>, and behaves identically to "block", > + except that generic SCSI commands from the guest are accepted > + in the case of "lun" - also note that <b>you should only use > + type='lun' for actual raw devices, never for individual partitions, > + or LVM partitions</b>). If the disk <code>type</code> is s/individual partitions, or/individual partitions or/ > +++ b/docs/schemas/domaincommon.rng > @@ -779,6 +779,22 @@ > </group> > <group> > <attribute name="type"> > + <value>lun</value> > + </attribute> > + <interleave> > + <optional> > + <element name="source"> > + <attribute name="dev"> > + <ref name="absFilePath"/> > + </attribute> > + <empty/> > + </element> > + </optional> > + <ref name="diskspec"/> > + </interleave> > + </group> > + <group> > + <attribute name="type"> > <value>dir</value> Is it worth compressing this? <group> <attribute name='type'> <choice> <value>block</value> <value>lun</value> </choice> </attribute> ... existing block stuff What you have looks reasonable; of course, it all changes if we go with a different XML representation. ACK to this code, if we agree on the approach. -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list