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

[Laine Stump]

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.