On Fri, Oct 12, 2018 at 01:17:42PM +0100, Daniel P. Berrangé wrote: > On Fri, Oct 12, 2018 at 01:14:51PM +0200, Michal Privoznik wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=1632833 > > > > When doing a SCSI passthrough we don't put format= onto the > > command line. This causes qemu to probe the format automatically > > which ends up in a warning in the domain log and possible qemu > > disabling writes to the first block (according to the warning > > message). > > If the warning message is correct, this should have been reported > as a security bug to libvirt and given a CVE. > > On the other hand if the warning from QEMU isn't correct, then > QEMU shouldn't have printed the warning about it being dangerous. > > So something is missing here either way. I used 'modprobe scsi_debug' to create a fake SCSI device which appears as "scsi_host6" in my host OS, and has a /dev/sg3 and /dev/sdd device nodes. When I use this XML: <hostdev mode='subsystem' type='scsi' managed='no' sgio='filtered' rawio='yes'> <source> <adapter name='scsi_host6'/> <address bus='0' target='0' unit='0'/> </source> <alias name='hostdev0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </hostdev> libvirt spawns QEMU pointing to /dev/sg3 -drive file=/dev/sg3,if=none,id=drive-hostdev0 Inside the guest, I can successfully run qemu-img create -f qcow2 /dev/sda 4M and on the host OS this now appears visible in the host # qemu-img info /dev/sdd image: /dev/sdd file format: qcow2 virtual size: 6.0M (6291456 bytes) disk size: 0 cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false this will *not* have an effect on this QEMU binary if it reboots, however, because QEMU does not appear to actually trigger format probing when used via the "scsi-generic" device type. Attempting to run qemu-img info against the /dev/sg3 device in the host fails as you can't read from an sg device directly. Presumably this is why QEMU won't do format probing either. Thus I don't think there is any security flaw here. The QEMU warning appears bogus. So to shut QEMU up: Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx> Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
