[libvirt] [PATCH 2/2] qemu: add new disk type='lun' for bus='virtio'

[Eric Blake]

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 at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120102/b1ecb7a5/attachment-0001.sig>