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

[Jonathan Cameron]

On Thu, 5 Aug 2021 12:52:30 -0700
Dan Williams <dan.j.williams@xxxxxxxxx> wrote:

> [ add Jonathan ]
> 
> On Thu, Aug 5, 2021 at 12:28 PM Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Thu, Aug 05, 2021 at 12:18:12PM -0700, Dan Williams wrote:  
> > > On Thu, Aug 5, 2021 at 12:12 PM Greg Kroah-Hartman
> > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:  
> > > >
> > > > On Thu, Aug 05, 2021 at 11:53:52AM -0700, Kuppuswamy, Sathyanarayanan wrote:  
> > > > > 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.
> 
> > 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@xxxxxxxxx/
> [2]: https://lore.kernel.org/r/20210804161839.3492053-1-Jonathan.Cameron@xxxxxxxxxx