Re: [libvirt] [PATCHv3 2/2] qemu: add new disk device='lun' for bus='virtio' & type='block'
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 620 bytes)