Hi! > Yes such drivers should be fixed, no doubt. But without lots of > fuzzing (we're working on this) and testing we'd like to avoid > exposing that attack surface at all. > > I think your suggestion to disable driver binding once the initial > bus/slot devices have been bound will probably work for this > situation. I just wanted to be clear that without some auditing, > fuzzing, and additional testing, we simply have to assume that drivers > are *not* secure and avoid using them on untrusted devices until we're > fairly confident they can handle them (whether just misbehaving or > malicious), in combination with other approaches like IOMMUs of > course. And this isn't because we don't trust driver authors or > kernel developers to dtrt, it's just that for many devices (maybe USB > is an exception) I think driver authors haven't had to consider this > case much, and so I think it's prudent to expect bugs in this area > that we need to find & fix. We normally trust the hardware NOT to be malicious. (Because if hacker has physical access to hardware and lot of resources, you lost). This is still true today, but maybe trusting USB devices is bad idea, so drivers are being cleaned up. PCI drivers will be WORSE in this regard. And you can't really protect against malicious CPU, and it is very very hard to protect against malicous RAM (probably not practical without explicit CPU support). Linux was designed with "don't let hackers near your hardware" threat model in mind. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: PGP signature
