On Thu, Aug 5, 2021 at 2:10 PM Andi Kleen <ak@xxxxxxxxxxxxxxx> wrote: > > > On 8/5/2021 12:01 PM, Dan Williams wrote: > > >> That's why I think the builtin allow list hook is still needed. Thoughts? > > I see nothing that prevents a built-in allow list to augment the > > driver-core default. Is there a gap I'm missing? > > > Okay so you're suggesting to build the builtin allow list on top of the > existing framework? > > I thought Greg's suggestion was to only rely on user space only. > > But if we have a way to change the authorized defaults by device (not > just bus) from inside the kernel at early boot that could well work. The default usb authorization is set at device creation time inherited from controller policy, which is in turn inherited from usbcore policy. So appending a built-in way to augment that policy further seems doable. > Doing it only on the bus level I suspect wouldn't work though. I think /sys/devices/.../$dev/authorized attribute can be used generically as the override interface, not that the TDX use case cares about user overrides, but that was the bulk of the unnecessary reinvention. That also addresses the ABI confusion so tools like usbguard don't need to look in 2 places to find a device is not authorized. That said, per-device authorization is a little bit different than per-driver trust. Driver trust is easy to reason about for a built-in policy, while per-device authorization is easy for userspace to reason about for "why is this device not talking to its driver?". So a strawman (I'm willing to watch go up in flames like driver-filter) is an arch overridable callback in driver_sysfs_add() as a central location where a device could have its authorization state set if it has not been previously changed from its initialization value. That callback could then consider device-name, bus-name, and/or driver-name for the default authorization. driver_sysfs_add() should also catch drivers that are manually bound without a bus.
