On 8/5/21 11:09 AM, Greg Kroah-Hartman wrote:

On Thu, Aug 05, 2021 at 10:58:46AM -0700, Andi Kleen wrote:

quoted

On 8/5/2021 10:51 AM, Greg Kroah-Hartman wrote:

quoted

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.

quoted

quoted

quoted

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