> > 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 :) Yeah will do for sure. I don't want to carry a big infra for this on our own! > 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. I think that's inherently platform specific to some extent. We can do it with our coreboot based firmware, but there's no guarantee other vendors will adopt the same approach. But I think at least for the ChromeOS ecosystem we can come up with something that'll work, and allow us to dtrt in userspace wrt driver binding. Thanks, Jesse
