Re: PING^7 (was Re: [PATCH v2 00/14] Corrections and customization of the SG_IO command whitelist (CVE-2012-4542))

["Martin K. Petersen" <martin.petersen@oracle.com>]

>>>>> "Paolo" == Paolo Bonzini <pbonzini@redhat.com> writes:

Paolo> First of all, I'll note that SG_IO and block-device-specific
Paolo> ioctls both have their place.  My usecase for SG_IO is
Paolo> virtualization, where I need to pass information from the LUN to
Paolo> the virtual machine with as much fidelity as possible if I choose
Paolo> to virtualize at the SCSI level.  

Now there's your problem! Several people told you way back that the SCSI
virt approach was a really poor choice. The SG_IO permissions problem is
a classic "Doctor, it hurts when I do this".

The kernel's fundamental task is to provide abstraction between
applications and intricacies of hardware. The right way to solve the
problem would have been to provide a better device abstraction built on
top of the block/SCSI infrastructure we already have in place. If you
need more fidelity, add fidelity to the block layer instead of punching
a giant hole through it.

I seem to recall that reservations were part of your motivation for
going the SCSI route in the first place. A better approach would have
been to create a generic reservations mechanism that could be exposed to
the guest. And then let the baremetal kernel worry about the appropriate
way to communicate with the physical hardware. Just like we've done with
reads and writes, discard, write same, etc.

The fact that burning CDs requires SG_IO in the first place is just a
symptom that we got that interface totally wrong. cat iso.img > /dev/sr0
would have been much more in line with how Unix works...

-- 
Martin K. Petersen	Oracle Linux Engineering