Thread (44 messages) 44 messages, 6 authors, 2021-08-06

Re: [PATCH v1] driver: base: Add driver filter support

From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Date: 2021-08-06 11:16:14
Also in: lkml

On Thu, 5 Aug 2021 12:52:30 -0700
Dan Williams [off-list ref] wrote:
[ add Jonathan ]

On Thu, Aug 5, 2021 at 12:28 PM Greg Kroah-Hartman
[off-list ref] wrote:
quoted
On Thu, Aug 05, 2021 at 12:18:12PM -0700, Dan Williams wrote:  
quoted
On Thu, Aug 5, 2021 at 12:12 PM Greg Kroah-Hartman
[off-list ref] wrote:  
quoted
On Thu, Aug 05, 2021 at 11:53:52AM -0700, Kuppuswamy, Sathyanarayanan wrote:  
quoted
I am not sure how USB and Thunderbolt "authorzied" model works. But I
don't think it prevents built-in driver probes during kernel boot right?  
Yes it does.

Again Intel created this framework well over a decade ago for busses
that it deemed that it did not want to "trust" to instantly probe
drivers for and made it part of the Wireless USB specification.

Then Intel went and added the same framework to Thunderbolt for the same
reason.

To ignore this work is quite odd, you might want to talk to your
coworkers...  
Sometimes we need upstream to connect us wayward drones back into the
hive mind. Forgive me for not immediately recognizing that the
existing 'authorized' mechanisms might be repurposed for this use
case.  
Not your fault, I'm more amazed that Andi doesn't remember this, he's
been around longer :)
 
In the driver core? No, not so much, and I do remember it flying by,
just did not connect the dots. In fact, it had just gone upstream when
you and I had that thread about blocking PCI drivers [1], September
2017 vs June 2017 when the Thunderbolt connection manager was merged.
There was no internal review process back then so I failed to
internalize its implications for this TDX filter. You had taken the
time to review it in a way that I had not.
quoted
But the first instinct should not be "let's go add a new feature", but
rather, "how has this problem been solved by others first" because,
really, this is not a new issue at all.  You should not rely on just me
to point out existing kernel features, we do have documentation you
know...  
I have added, "review driver core attribute proposal for duplication
of bus-local capabilities" to my review checklist.

The good news is I think this generic authorization support in the
core may answer one of Jonathan's questions about how to integrate PCI
SPDM/CMA support [2].
Definitely an interesting discussion, and the SPDM stuff
feeds into Greg's point about establishing trust with hardware.

If anyone is looking at the USB authentication specification (which is
more or less SPDM), would be good to align on that.

My current model is really basic (driver checks and fails probe if
failure occurs). Definitely better to bolt into standard approach.

*Goes off to read up on this topic*

Thanks for highlighting this thread Dan,

Jonathan
[1]: https://lore.kernel.org/lkml/20170928090901.GC12599@kroah.com/ (local)
[2]: https://lore.kernel.org/r/20210804161839.3492053-1-Jonathan.Cameron@huawei.com (local)
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help