> > I feel a lot of resistance to the proposal, however, I'm not hearing > > any realistic solutions that may help us to move forward. We want to > > go with a solution that is acceptable upstream as that is our mission, > > and also helps the community, however the behemoth task of "inspect > > all drivers and fix them" before launching a product is really an > > unfair ask I feel :-(. Can you help us by suggesting a proposal that > > does not require us to trust a driver equally for internal / external > > devices? > > I have no idea why you feel you have to "inspect all drivers" other than > the fact that for some reason _you_ do not feel they are secure today. > > What type of "assurance" are you, or anyone else going to be able to > provide for any kernel driver that would meet such a "I feel good now" > level? Have you done that work for any specific driver already so that > you can show us what you mean by this effort? Perhaps it's as simple as > "oh look, this tool over here runs 'clean' on the source code, all is > good!", or not, I really have no idea. I think there's a disconnect somewhere in this discussion... maybe we're just approaching this with different assumptions? I think you recognize the potential for driver vulnerabilities when binding to new or potentially hostile devices that may be spoofing DID/VID/class/etc than then go on to abuse driver trust or the driver using unvalidated inputs from the device to crash or run arbitrary code on the target system. 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. Thanks, Jesse
