On Thu, Jul 2, 2020 at 4:07 AM Rajat Jain <rajatja@xxxxxxxxxx> wrote: > > *snip* > > > > I guess it would make sense to have an attribute for user space to > > > write to in order to make the kernel reject device plug-in events > > > coming from a given port or connector, but the kernel has no reliable > > > means to determine *which* ports or connectors are "safe", and even if > > > there was a way for it to do that, it still may not agree with user > > > space on which ports or connectors should be regarded as "safe". > > > > Again, we have been doing this for USB devices for a very long time, PCI > > shouldn't be any different. Why people keep ignoring working solutions > > is beyond me, there's nothing "special" about PCI devices here for this > > type of "worry" or reasoning to try to create new solutions. > > > > So, again, I ask, go do what USB does, and to do that, take the logic > > out of the USB core, make it bus-agnositic, and _THEN_ add it to the PCI > > code. Why the original submitter keeps ignoring my request to do this > > is beyond me, I guess they like making patches that will get rejected :( > > IMHO I'm actually trying to precisely do what I think was the > conclusion of our discussion, and then some changes because of the > further feedback I received on those patches. Let's take a step back > and please allow me to explain how I got here (my apologies but this > spans a couple of threads, and I"m trying to tie them all together > here): The previous thread had some suggestions, but no real conclusions. That's probably why we're still arguing about it... > GOAL: To allow user space to control what (PCI) drivers he wants to > allow on external (thunderbolt) ports. There was a lot of debate about > the need for such a policy at > https://lore.kernel.org/linux-pci/CACK8Z6GR7-wseug=TtVyRarVZX_ao2geoLDNBwjtB+5Y7VWNEQ@xxxxxxxxxxxxxx/ > with the final conclusion that it should be OK to implement such a > policy in userspace, as long as the policy is not implemented in the > kernel. The kernel only needs to expose bits & info that is needed by > the userspace to implement such a policy, and it can be used in > conjunction with "drivers_autoprobe" to implement this policy: > -------------------------------------------------------------------- > .... > That's an odd thing, but sure, if you want to write up such a policy for > your systems, great. But that policy does not belong in the kernel, it > belongs in userspace. > .... > -------------------------------------------------------------------- > 1) The post https://lore.kernel.org/linux-pci/20200609210400.GA1461839@bjorn-Precision-5520/ > lists out the approach that was agreed on. Replicating it here: > ----------------------------------------------------------------------- > - 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. > > This comes from either the DT "external-facing" property or the > ACPI "ExternalFacingPort" property. > > - All devices present at boot are enumerated. Any statically built > drivers will bind to them before any userspace code runs. > > If you want to keep statically built drivers from binding, you'd > need to invent some mechanism so pci_driver_init() could clear > drivers_autoprobe after registering pci_bus_type. > > - Early userspace code prevents modular drivers from automatically > binding to PCI devices: > > echo 0 > /sys/bus/pci/drivers_autoprobe > > This prevents modular drivers from binding to all devices, whether > present at boot or hot-added. > > - Userspace code uses the sysfs "bind" file to control which drivers > are loaded and can bind to each device, e.g., > > echo 0000:02:00.0 > /sys/bus/pci/drivers/nvme/bind I think this is a reasonable suggestion. However, as Greg pointed out it's gratuitously different to what USB does for no real reason. > ----------------------------------------------------------------------- > 2) As part of implementing the above agreed approach, when I exposed > PCI "untrusted" attribute to userspace, it ran into discussion that > concluded that instead of this, the device core should be enhanced > with a location attribute. > https://lore.kernel.org/linux-pci/20200618184621.GA446639@xxxxxxxxx/ > ----------------------------------------------------------------------- > ... > The attribute should be called something like "location" or something > like that (naming is hard), as you don't always know if something is > external or not (it could be internal, it could be unknown, it could be > internal to an external device that you trust (think PCI drawers for > "super" computers that are hot pluggable but yet really part of the > internal bus). > .... > "trust" has no direct relation to the location, except in a policy of > what you wish to do with that device, so as long as you keep them > separate that way, I am fine with it. > ... > ----------------------------------------------------------------------- > > And hence this patch. I don't see an attribute in USB comparable to > this new attribute, except for the boolean "removable" may be. Are you > suggesting to pull that into the device core instead of adding this > "physical_location" attribute? He's suggesting you pull the "authorized" attribute into the driver core. That's the mechanism USB uses to block drivers binding unless userspace authorizes them. I don't see any reason why we can't re-use that sysfs interface for PCI devices since the problem being solved is fundamentally the same. The main question is what we should do as a default policy in the kernel. For USB the default comes from the "authorized_default" module param of usbcore: > /* authorized_default behaviour: > * -1 is authorized for all devices except wireless (old behaviour) > * 0 is unauthorized for all devices > * 1 is authorized for all devices > * 2 is authorized for internal devices > */ > #define USB_AUTHORIZE_WIRED -1 > #define USB_AUTHORIZE_NONE 0 > #define USB_AUTHORIZE_ALL 1 > #define USB_AUTHORIZE_INTERNAL 2 > > static int authorized_default = USB_AUTHORIZE_WIRED; > module_param(authorized_default, int, S_IRUGO|S_IWUSR); So the default policy for USB is to authorize any wired USB device and we can optionally restrict that to just integrated devices. Sounding familiar? The internal / external status is still useful to know so we might want to make a sysfs attribute for that too. However, I'd like to point out that internal / external isn't the whole story. As I mentioned in the last thread if I have a BMC device I *really* don't want it to be authorized by default even though it's an internal device. Similarly, if I know all my internal cards support PCIe Component Authentication then I might choose not to trust any PCI devices unless they authenticate successfully. > 3) The one deviation from the agreed approach in (1) is > https://patchwork.kernel.org/patch/11633095/ . The reason is I > realized that contrary to what I earlier believed, we might not be > able to disable the PCI link to all external PCI devices at boot. So > external PCI devices may actually bind to drivers before userspace > comes up and does "echo 0 > /sys/bus/pci/drivers_autoprobe"). Yep, that's a problem. If we want to provide a useful mechanism to userspace then the default behaviour of the kernel can't undermine that mechanism. If that means we need another kernel command line parameter then I guess we just have to live with it. Oliver
