[libvirt] [PATCHv3 2/2] qemu: add new disk device='lun' for bus='virtio' & type='block'

[Eric Blake]

On 01/05/2012 11:35 AM, Laine Stump wrote:
> In the past, generic SCSI commands issued from a guest to a virtio
> disk were always passed through to the underlying disk by qemu, and
> the kernel would also pass them on.
> 

> 
> v3 changes:
> 
> 1) Add note to docs that the SCSI commands are not only accepted from
>    the guest, but are passed through to the physical device (I didn't
>    add anything about the SCSI commands being emulated because I still
>    don't understand that situation perfectly, and don't want to add
>    misleading docs about existing behavior.
> 
> 2) Change the logic of qemuDomainSnapshotIsAllowed() to always return
>    false if a device='lun' disk is encountered, regardless of the
>    format. In reality, lun disks are always 'raw', so it would return
>    false anyway, but this makes it clearer.

Looks reasonable.


> +++ b/docs/formatdomain.html.in
> @@ -1001,8 +1001,17 @@
>          "block", "dir", or "network"
>          and refers to the underlying source for the disk. The optional
>          <code>device</code> attribute indicates how the disk is to be exposed
> -        to the guest OS. Possible values for this attribute are "floppy", "disk"
> -        and "cdrom", defaulting to "disk".  The
> +        to the guest OS. Possible values for this attribute are
> +        "floppy", "disk", "cdrom", and "lun", defaulting to
> +        "disk". "lun" (<span class="since">since 0.9.10</span>) is only

Are we targetting 0.9.9 since this is a CVE mitigation?  IIUC, the qemu
default is scsi=on, so it is _only_ after this patch is applied that we
override that default with scsi=off for device='disk'.

If someone upgrades their kernel for the CVE fix, then it doesn't
matter.  But if someone is running with the old kernel and libvirt
0.9.9, then should they get the scsi=off command line parameter by
default to take advantage of the qemu mitigation that prevents SG_IO for
scsi=off?

That is, I'm arguing that this patch is probably worth applying now,
rather than waiting post-release, just so that someone that upgrades
libvirt and qemu but not the kernel is at least less vulnerable to the
CVE that was fixed by the upgraded kernel.  I guess it boils down to how
likely it is that someone can't afford the downtime in their host to
upgrade their kernel right away, but can live with the downtime of
upgrading the user-space libvirt and qemu and reboot guests to take
advantage of the new scsi=off for the guest in the window while they
wait for the next convenient time where the host kernel can be upgraded.

At any rate, I think we have converged; ACK whether we decide this is
0.9.9 material to be pushed now with one tweak, or 0.9.10 material to be
delayed to next week.

-- 
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/20120105/651a419e/attachment-0001.sig>