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

From: Andi Kleen <ak@linux.intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kuppuswamy Sathyanarayanan 
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Dan Williams <dan.j.williams@intel.com>,
	Kuppuswamy Sathyanarayanan <knsathya@kernel.org>,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v1] driver: base: Add driver filter support
Date: Thu, 5 Aug 2021 10:58:46 -0700	[thread overview]
Message-ID: <21db8884-5aa1-3971-79ef-f173a0a95bef@linux.intel.com> (raw)
In-Reply-To: <YQwlHrJBw79xhTSI@kroah.com>

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?

>
>> 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.

> There is a platform bus, it's just a fake one.  The platform bus code
> does the binding just like any other bus does, why is platform somehow
> "special"?  Except for how it is abused...

For once it's usually all initialized early, so there's no way for user 
space to do anything.

-andi