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

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

flat view

From: Dan Williams <hidden>
Date: 2021-08-05 19:01:45
Also in: lkml

On Thu, Aug 5, 2021 at 11:44 AM Andi Kleen [off-list ref] wrote:

On 8/5/2021 11:09 AM, Greg Kroah-Hartman wrote:
quoted
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.
That won't work for confidential guests, e.g. we need a virtio driver
for the console and some other things.

quoted
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...
Trusted here means someone audited them and also fuzzed them. That's all
a lot of work and also needs to be maintained forever so we're trying to
do only a minimum set. There are actually quite a few platform drivers,
it's difficult to audit them all.
What's wrong with the generic authorized proposal? The core can
default to deauthorizing devices on the platform bus, or any bus,
unless on an allow list. It's a bit more work to uplevel the local
"authorized" implementations from USB and Thunderbolt to the core, but
it's functionally identical to the "filter" approach in terms of
protection, i.e. avoiding probe of unnecessary unvetted drivers.

[..]
That's why I think the builtin allow list hook is still needed. Thoughts?
I see nothing that prevents a built-in allow list to augment the
driver-core default. Is there a gap I'm missing?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help