On Fri, May 24, 2013 at 4:13 PM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: >> The same filtering table being applied to different classes of >> hardware is a software bug, but my point is that the practive >> essentially entrusts non-insignificant part of security enforcement to >> the hardware itself. The variety of hardware in question is very wide >> and significant portion has historically been known to be flaky. > > Unproven theory, and contradicted by actual practice. Bugs are more > common in the handling of borderline conditions, not in the handling of > unimplemented commands. > > If you want to be secure aginst buggy firmware, the commands you have to > block are READ and WRITE. Check out the list of existing USB quirks. Well, I'd actually much prefer disabling CDB whitelisting for all !MMC devices if at all possible. You're basically arguing that because what we have is already broken, it should be okay to break it further. Also, RW commands having more quirks doesn't necessarily indicate that they tend to be more broken. They just get hammered on a lot in various ways so problems on those commands tend to be more noticeable. > You need to allow more commands. > The count-me-out knob allows all commands. > You cannot always allow all commands. > Ergo, you cannot always use the count-me-out knob. The thing is that both approaches aren't perfect here so you can make similar type of argument from the other side. If the system wants to give out raw hardware access to VMs, requiring it to delegate the device fully could be reasonable. Not ideal but widening direct command access by default is pretty nasty too. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
