archive mirror
 help / color / mirror / Atom feed
From: "Oliver O'Halloran" <>
To: Rajat Jain <>
Cc: Todd Broch <>,
	linux-pci <>,
	Lalithambika" <>,
	Diego Rivas <>,
	Jean-Philippe Brucker <>,
	Furquan Shaikh <>,
	Raj Ashok <>,,
	Christian Kellner <>,
	Mattias Nissler <>,
	Jesse Barnes <>, Len Brown <>,
	Rajat Jain <>,
	Prashant Malani <>,
	Aaron Durbin <>,
	Alex Williamson <>,
	Bjorn Helgaas <>,
	Mika Westerberg <>,
	Bernie Keany <>,
	Duncan Laurie <>,
	Greg Kroah-Hartman <>,
	"Rafael J. Wysocki" <>,
	Linux Kernel Mailing List <>,,
	Benson Leung <>,
	David Woodhouse <>,
	Alex Levin <>
Subject: Re: [PATCH 2/2] pci: Add parameter to disable attaching untrusted devices
Date: Fri, 26 Jun 2020 17:52:57 +1000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Jun 26, 2020 at 10:27 AM Rajat Jain <> wrote:
> Introduce a PCI parameter that disables the automatic attachment of
> untrusted devices to their drivers.
> Signed-off-by: Rajat Jain <>
> ---
> Context:
>   I set out to implement the approach outlined in
>   But to my surprise, I found that the new hotplugged PCI devices
>   were getting automatically attached to drivers even though
>   /sys/bus/pci/drivers_autoprobe was set to 0.
>   I realized that the device core's "drivers_autoprobe":
>   * only disables the *initial* probe of the device (i.e. from
>     device_add()). If a subsystem calls device_attach() explicitly
>     for its devices like PCI subsystem does, the drivers_autoprobe
>     setting does not matter. The core will attach device to the driver.
>     This looks like correct semantic behavior to me because PCI is
>     explicitly calling device_attach(), which is a way to explicitly
>     ask the core to find and attach a driver for a device.

Right, but we're doing using device_attach() largely because the
driver core doesn't provide any mechanism for deferring the initial
probe. I didn't think there was any deeper reason for it, but while
looking I noticed that the initial probe can be async and
device_attach() forces probing to be synchronous. That has the side
effect of serialising all PCI device probing which might be
intentional to avoid device renaming due to the change in probe order.
Userspace is better at dealing with device names changing now days,
but you might still get some people mad at you for changing it.

>   2) Make the drivers_autoprobe property available to PCI to use
>      (currently it is private to device core). The PCI could use this
>      to determine whether or not to call device_attach(). This still
>      leaves the other problem (of not being able to set
>      drivers_autoprobe via command line open).
>   3) I found the pci_dev->match_driver, which seemed similar to what I
>      am trying to do, but can't be controlled from userspace. I considered
>      populating that field based on drivers_autoprobe (still need (2)).
>      But the problem is that there is the AMD IOMMU driver which is setting
>      this independently, so setting the match_driver based on
>      drivers_autoprobe may not be a good idea.

Huh, that's pretty weird. Even with that hack you should be able
trigger the bug they're working around by removing the IOMMU device in
sysfs and doing a rescan. I wouldn't worry much about making
match_device user controllable since you would need to work pretty
hard for it to be an issue.

iommu mailing list

  parent reply	other threads:[~2020-06-26  8:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-26  0:27 [PATCH 1/2] pci: Add pci device even if the driver failed to attach Rajat Jain via iommu
2020-06-26  0:27 ` [PATCH 2/2] pci: Add parameter to disable attaching untrusted devices Rajat Jain via iommu
2020-06-26  4:46   ` Greg Kroah-Hartman
2020-06-26  7:52   ` Oliver O'Halloran [this message]
2020-06-26 14:17   ` Greg Kroah-Hartman
2020-06-26 18:53     ` Rajat Jain via iommu
2020-06-27  5:02       ` Greg Kroah-Hartman
2020-06-26 14:14 ` [PATCH 1/2] pci: Add pci device even if the driver failed to attach Greg Kroah-Hartman
2020-06-26 15:39 ` Bjorn Helgaas
2020-06-26 19:01   ` Rajat Jain via iommu

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

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