On Mon, Jun 08, 2020 at 10:03:38AM -0700, Jesse Barnes wrote: > > > 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. For USB, yes, we have now had to deal with "untrusted devices" lieing about their ids and sending us horrible data. That's all due to the fuzzing tools that have been written over the past few years, and now we have some of those in the kernel tree itself to help with that testing. For PCI, heh, good luck, those assumptions about "devices sending valid data" are everywhere, if our experience with USB is any indication. But, to take USB as an example, this is exactly what the USB "authorized" flag is there for, it's a "trust" setting that userspace has control over. This came from the wireless USB spec, where it was determined that you could not trust devices. So just use that same model here, move it to the driver core for all busses to use and you should be fine. If that doesn't meet your needs, please let me know the specifics of why, with patches :) Now, as to you all getting some sort of "Hardware flag" to determine "inside" vs. "outside" devices, hah, good luck! It took us a long time to get that for USB, and even then, BIOSes lie and get it wrong all the time. So you will have to also deal with that in some way, for your userspace policy. good luck! greg k-h
