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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/05/2012 01:49 PM, Eric Blake wrote:
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.


Thanks for the reviews, Eric!

Because any libvirt change would be pointless without also updating qemu (old qemu would just ignore "scsi=off" and pass through the commands anyway), I waited until after 0.9.9 was released in order to avoid any last-minute breakage. These two patches are now pushed, though.

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]