On Tue, Jun 9, 2020 at 5:04 PM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > On Tue, Jun 09, 2020 at 04:23:54PM -0700, Rajat Jain wrote: > > Hi Bjorn, > > > > Thanks for sending out the summary, I was about to send it out but got lazy. > > > > On Tue, Jun 9, 2020 at 2:04 PM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > > > > > On Sun, Jun 07, 2020 at 01:36:32PM +0200, Greg Kroah-Hartman wrote: > > > > > > > Your "problem" I think can be summed up a bit more concise: > > > > - you don't trust kernel drivers to be "secure" for untrusted > > > > devices > > > > - you only want to bind kernel drivers to "internal" devices > > > > automatically as you "trust" drivers in that situation. > > > > - you want to only bind specific kernel drivers that you somehow > > > > feel are "secure" to untrusted devices "outside" of a system > > > > when those devices are added to the system. > > > > > > > > Is that correct? > > > > > > > > If so, fine, you can do that today with the bind/unbind ability of > > > > drivers, right? After boot with your "trusted" drivers bound to > > > > "internal" devices, turn off autobind of drivers to devices and then > > > > manually bind them when you see new devices show up, as those "must" be > > > > from external devices (see the bind/unbind files that all drivers export > > > > for how to do this, and old lwn.net articles, this feature has been > > > > around for a very long time.) > > > > > > > > I know for USB you can do this, odds are PCI you can turn off > > > > autobinding as well, as I think this is a per-bus flag somewhere. If > > > > that's not exported to userspace, should be trivial to do so, should be > > > > somewere in the driver model already... > > > > > > > > Ah, yes, look at the "drivers_autoprobe" and "drivers_probe" files in > > > > sysfs for all busses. Do those not work for you? > > > > > > > > My other points are the fact that you don't want to put policy in the > > > > kernel, and I think that you can do everything you want in userspace > > > > today, except maybe the fact that trying to determine what is "inside" > > > > and "outside" is not always easy given that most hardware does not > > > > export this information properly, if at all. Go work with the firmware > > > > people on that issue please, that would be most helpful for everyone > > > > involved to get that finally straightened out. > > > > > > To sketch this out, my understanding of how this would work is: > > > > > > - Expose the PCI pdev->untrusted bit in sysfs. We don't expose this > > > today, but doing so would be trivial. I think I would prefer a > > > sysfs name like "external" so it's more descriptive and less of a > > > judgment. > > > > Yes. I think we should probably semantically differentiate between > > "external" and "external facing" devices. Root ports and downstream > > ports can be "external facing" but are actually internal devices. > > Anything below an "external facing" device is "external". So the sysfs > > attribute "external" should be set only for devices that are truly > > external. > > Good point; we (maybe you? :)) should fix that edge case. Sure, happy to. I will start a fresh conversation about that (in a separate thread). > > > Just a suggestion: Do you think an enum attribute may be better > > instead, whose values could be "internal" / "external" / > > "external-facing" in case need arises later to distinguish between > > them? > > I don't see the need for an enum yet. Maybe we should add that > if/when we do need it? Sure, no problems. (I just wanted to slip the thought into the conversation as UAPI is hard to change later). > > > > - Early userspace code prevents modular drivers from automatically > > > binding to PCI devices: > > > > > > echo 0 > /sys/bus/pci/drivers_autoprobe > > > > Yes. > > I believe this setting will apply it equally to both modular and > > statically linked drivers? > > Yes. The test is in bus_probe_device(), and it does the same for both > modular and statically linked drivers. > > But for statically linked drivers, it only prevents them from binding > to *hot-added* devices. They will claim devices present at boot even > before userspace code can run. Yes, understood. > > > The one thing that still needs more thought is how about the > > "pcieport" driver that enumerates the PCI bridges. I'm unsure if it > > needs to be whitelisted for further enumeration downstream. What do > > you think? > > The pcieport driver is required for AER, PCIe native hotplug, PME, > etc., and it cannot be a module, so the whitelist wouldn't apply to > it. Not that I see the need, but slight clarification needed just to make sure I understand it clearly: Since pcieport driver is statically compiled in, AER, pciehp, PME, DPC etc will always be enabled for devices plugged in during boot. But I can still choose to choose to allow or deny for devices added *after boot* using the whitelist, right? Also, denying pcieport driver for hot-added PCIe bridges only disables these pcieport services on those bridges, but device enumeration further downstream those bridges is not an issue? > I assume you need hotplug support, so you would have pcieport > enabled and built in statically. > > If you're using ACPI hotplug, that doesn't require pcieport. Thank you, this was indeed a long and useful thread :-) Best Regards, Rajat
