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

[Kuppuswamy, Sathyanarayanan]

On 8/5/21 11:09 AM, Greg Kroah-Hartman wrote:
> On Thu, Aug 05, 2021 at 10:58:46AM -0700, Andi Kleen wrote:
> > On 8/5/2021 10:51 AM, Greg Kroah-Hartman wrote:
> > > It's controlled by whatever you want to use in userspace.  usbguard has
> > > been handling this logic in userspace for over a decade now just fine.
> >
> >
> > So how does that work with builtin USB drivers? Do you delay the USB binding
> > until usbguard starts up?
>
> Yes.
>
> > > > This doesn't help us handle builtin drivers that initialize before user
> > > > space is up.
> > > Then have the default setting for your bus be "unauthorized" like we
> > > allow for some busses today.
> >
> > We need some early boot drivers, just not all of them. For example in your
> > scheme we would need to reject all early platform drivers, which would break
> > booting. Or allow all early platform drivers, but then we exactly get into
> > the problem that there are far too many of them to properly harden.
>
> Define "harden" please.  Why not just allow all platform drivers, they
> should all be trusted.  If not, well, you have bigger problems...

This driver filter framework will be mainly (at-least for now) used by
protected guest. "Protected guest" is the term we use define a VM
guest which ensures memory and data isolation when working with
untrusted VMM. You can find some basic introduction to it in following
links.

https://lwn.net/Articles/860352/
https://software.intel.com/content/www/br/pt/develop/articles/intel-trust-domain-extensions.html

In protected guest, since VMM is untrusted, device drivers that deals
with IO-memory and data had to audited and hardened against attack from
malicious VMM.

With this driver filter support, we can ensure only hardened drivers
are allowed to bind with device. This is applicable to built-in and
loadable kernel drivers.

I don't think there is a existing framework which does this right?

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?
I will also check this framework and get back to you.

> Anyway, feel free to build on top of the existing scheme please, but do
> not ignore it and try to create yet-another-way-to-do-this that I have
> to maintain for the next 20+ years.
>
> thanks,
>
> greg k-h

--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer