From: Dan Williams <dan.j.williams@intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andi Kleen <ak@linux.intel.com>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Kuppuswamy Sathyanarayanan <knsathya@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Doc Mailing List <linux-doc@vger.kernel.org>
Subject: Re: [PATCH v1] driver: base: Add driver filter support
Date: Thu, 5 Aug 2021 09:37:28 -0700 [thread overview]
Message-ID: <CAPcyv4iCBknhGyw-YjO7_Tua9Vkw_UCSHVj3prL3mVfz4nj-_g@mail.gmail.com> (raw)
In-Reply-To: <YQuaJ78y8j1UmBoz@kroah.com>
On Thu, Aug 5, 2021 at 12:58 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Thu, Aug 05, 2021 at 09:55:33AM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Aug 05, 2021 at 09:49:29AM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, Aug 04, 2021 at 12:50:24PM -0700, Andi Kleen wrote:
> > > > > And what's wrong with the current method of removing drivers from
> > > > > devices that you do not want them to be bound to? We offer that support
> > > > > for all busses now that want to do it, what driver types are you needing
> > > > > to "control" here that does not take advantage of the existing
> > > > > infrastructure that we currently have for this type of thing?
> > > >
> > > > I'm not sure what mechanism you're referring to here, but in general don't
> > > > want the drivers to initialize at all because they might get exploited in
> > > > any code that they execute.
> > >
> > > That is exactly the mechanism we have today in the kernel for all busses
> > > if they wish to take advantage of it. We have had this for all USB
> > > drivers for well over a decade now, this is not a new feature. Please
> > > use that instead.
> >
> > Hm, wait, maybe that didn't get merged yet, let me dig...
> >
>
> Ok, my fault, I was thinking of the generic "removable" support that
> recently got added.
>
> Both thunderbolt and USB have the idea of "authorized" devices, that is
> the logic that should be made generic and available for all busses to
> use, by moving it to the driver core, just like the "removable" logic
> got moved to the driver core recently (see 70f400d4d957 ("driver core:
> Move the "removable" attribute from USB to core")
>
> Please use that type of interface, as we already have userspace tools
> using it, and expand it for all busses in the system to use if they
> want. Otherwise with this proposal you will end up with multiple ways
> to control the same bus type with different types of "filtering",
> ensuring a mess.
I overlooked the "authorized" attribute in usb and thunderbolt. The
collision problem makes sense. Are you open to a core "authorized"
attribute that buses like usb and thunderbolt would override in favor
of their local implementation? I.e. similar to suppress_bind_attrs:
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index daeb9b5763ae..d1780f026d1a 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -511,6 +511,10 @@ static int call_driver_probe(struct device *dev,
struct device_driver *drv)
{
int ret = 0;
+ if (driver_core_auth_enabled && !dev->bus->suppress_authorized_attrs &&
+ !driver_core_authorized(dev))
+ return -ENODEV;
+
if (dev->bus->probe)
ret = dev->bus->probe(dev);
else if (drv->probe)
diff --git a/drivers/thunderbolt/domain.c b/drivers/thunderbolt/domain.c
index a062befcb3b2..e835be9bee4f 100644
--- a/drivers/thunderbolt/domain.c
+++ b/drivers/thunderbolt/domain.c
@@ -323,6 +323,7 @@ struct bus_type tb_bus_type = {
.probe = tb_service_probe,
.remove = tb_service_remove,
.shutdown = tb_service_shutdown,
+ .suppress_authorized_attrs = true,
};
static void tb_domain_release(struct device *dev)
diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index 072968c40ade..2cf9c3cc12b4 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -2028,4 +2028,5 @@ struct bus_type usb_bus_type = {
.match = usb_device_match,
.uevent = usb_uevent,
.need_parent_lock = true,
+ .suppress_authorized_attrs = true,
};
next prev parent reply other threads:[~2021-08-05 16:37 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-04 17:43 [PATCH v1] driver: base: Add driver filter support Kuppuswamy Sathyanarayanan
2021-08-04 18:08 ` Matthew Wilcox
2021-08-04 18:29 ` Kuppuswamy, Sathyanarayanan
2021-08-04 18:33 ` Matthew Wilcox
2021-08-04 19:27 ` Andi Kleen
2021-08-04 18:45 ` Dan Williams
2021-08-04 19:29 ` Greg Kroah-Hartman
2021-08-04 19:50 ` Andi Kleen
2021-08-04 20:09 ` Kuppuswamy, Sathyanarayanan
2021-08-05 7:50 ` Greg Kroah-Hartman
2021-08-05 7:49 ` Greg Kroah-Hartman
2021-08-05 7:55 ` Greg Kroah-Hartman
2021-08-05 7:58 ` Greg Kroah-Hartman
2021-08-05 13:52 ` Andi Kleen
2021-08-05 17:51 ` Greg Kroah-Hartman
2021-08-05 17:58 ` Andi Kleen
2021-08-05 18:09 ` Greg Kroah-Hartman
2021-08-05 18:44 ` Andi Kleen
2021-08-05 19:01 ` Dan Williams
2021-08-05 19:08 ` Kuppuswamy, Sathyanarayanan
2021-08-05 19:28 ` Greg Kroah-Hartman
2021-08-05 21:10 ` Andi Kleen
2021-08-06 1:00 ` Dan Williams
2021-08-06 5:17 ` Greg Kroah-Hartman
2021-08-06 14:36 ` Dan Williams
2021-08-06 5:07 ` Greg Kroah-Hartman
2021-08-05 18:53 ` Kuppuswamy, Sathyanarayanan
2021-08-05 19:12 ` Greg Kroah-Hartman
2021-08-05 19:18 ` Dan Williams
2021-08-05 19:28 ` Greg Kroah-Hartman
2021-08-05 19:52 ` Dan Williams
2021-08-06 11:15 ` Jonathan Cameron
2021-08-05 16:37 ` Dan Williams [this message]
2021-08-05 17:25 ` Kuppuswamy, Sathyanarayanan
2021-08-05 17:48 ` Greg Kroah-Hartman
2021-08-05 17:52 ` Andi Kleen
2021-08-05 18:11 ` Greg Kroah-Hartman
2021-08-05 17:49 ` Greg Kroah-Hartman
2021-08-04 20:11 ` Dan Williams
2021-08-04 20:29 ` Kuppuswamy, Sathyanarayanan
2021-08-04 21:07 ` Matthew Wilcox
2021-08-04 21:28 ` Dan Williams
2021-08-05 4:45 ` Andi Kleen
2021-08-05 7:59 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPcyv4iCBknhGyw-YjO7_Tua9Vkw_UCSHVj3prL3mVfz4nj-_g@mail.gmail.com \
--to=dan.j.williams@intel.com \
--cc=ak@linux.intel.com \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=knsathya@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).