On Wed, Aug 11, 2010 at 04:43:56PM -0700, Greg KH wrote: > Ok, I see the argument is valid for both sides. > > What do others think? Mathew, any thoughts? My only thought is that we've tried extensive command filtering in the past. It seemed like every 6 months we were back, tweaking things that had already been fixed. I don't like fixing the same bug multiple times. My general theory is that "you shouldn't send a command to a device that it can't handle". I recognize that this puts the burden on the SCSI drivers and the userspace application folks. I also think that a userspace app, with sufficient privlidges, *should* be able to send any command it wants to the hardware. It is the app's power, privlidge, and responsibility to get it right or deal with the consequences. If we filter at the usb-storage level, we take away that power. For example, suppose 6 months from now someone discovers that Windows does, in fact, use the offending command, but this time with a set of parameters which seems to work. Why should we prevent a userspace app from using that knowledge? And before you say "that will never happen," recognize that it already did -- we spent quite a bit of time making sd_mod generate MODE_SENSE commands (to check for write-protect status) the way the Redmond OS does (for maximum compatibility). That was a long time ago, but it is worth noting that since doing that, write-protect detection has *stayed*fixed* (i.e. devices no longer crash wholesale during detection). In general, I take the stance that we should allow userspace to do whatever it wants. The kernel-level drivers should generally avoid doing things which are likely to send devices over-the-edge (c.f. MODE_SENSE mentioned above), but the drivers should not intervene in a userspace-generated command. For example, does any HBA filter out the SCSI low-level format command? It's really never needed now (hasn't been for what, 15 years?). Should we filter that, because issuing it to a device will cause irreversable data loss, and the HBA can identify devices (i.e. disks) which will react badly to the command? Yes, that last paragraph is a hyperbolic straw-man. But the point is that, to my knowledge, every "pass-through" driver (i.e. drivers that move commands/data from one driver above to another driver below) in the kernel does as *little* filtering as necessary, if any at all. Finally, I want to address one point of clarification: With the exception of INQUIRY, usb-storage does not intercept and cancel any commands. Usb-storage does re-write the results of a few commands (auto-sense, read capacity) in an attempt to translate the data coming back from the device into the format that SCSI expects it to be in. But, we do not have a command filtering infrastructure. Matt -- Matthew Dharm Home: mdharm-usb@xxxxxxxxxxxxxxxxxx Maintainer, Linux USB Mass Storage Driver A: The most ironic oxymoron wins ... DP: "Microsoft Works" A: Uh, okay, you win. -- A.J. & Dust Puppy User Friendly, 1/18/1998
Attachment:
pgpJJVCdKrsTD.pgp
Description: PGP signature
