On Mon, Jun 08, 2020 at 11:41:19AM -0700, Rajat Jain wrote: > Hi Jesse and Greg, > > On Mon, Jun 8, 2020 at 11:30 AM Jesse Barnes <jsbarnes@xxxxxxxxxx> wrote: > > > > > > 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. > > This is great to hear! I tried to look up but didn't find anything > else in-kernel, except the kcov support to export coverage info for > userspace fuzzers. Can you please give us some pointers for in-kernel > fuzzing tools? For USB, it's a combination of using syzbot with the "raw gadget" driver and the loopback gadget/host controller. See many posts from Andrey Konovalov <andreyknvl@xxxxxxxxxx> on the linux-usb@xxxxxxxxxxxxxxx list for details as to how he does this. > > > 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. > > Agree, we can work with our firmware teams to get that right, and then > expose it from kernel to userspace to help it implement the policy we > want. This is already in the spec for USB, I suggest working to get this added to the other bus type specs that you care about as well (UEFI, PCI, etc.) thanks, greg k-h
