Re: [PATCH v2 05/19] device core: Autoprobe considered harmful?

[Jonathan Cameron <jonathan.cameron@huawei.com>]

On Mon,  2 Mar 2026 16:01:53 -0800
Dan Williams <dan.j.williams@intel.com> wrote:

> The threat model of PCI Trusted Execution Environment Device Interface
> Security Protocol (TDISP), is that an adversary may be impersonating the
> device's identity, redirecting the device's MMIO interface, and/or
> snooping/manipulating the physical link. Outside of PCI TDISP, PCI ATS
> (that allows IOMMU bypass) comes to mind as another threat vector that
> warrants additional device verification beyond whether ACPI enumerates the
> device as "internal" [1].
> 
> The process of verifying a device ranges from the traditional default
> "accept everything" to gathering signed evidence from a locked device,
> shipping it to a relying party and acting on that disposition. That policy
> belongs in userspace. A natural way for userspace to get a control point
> for verifying a device before use is when the driver for the device comes
> from a module.
> 
> For deployments that are concerned about adversarial devices, introduce a
> mechanism to disable autoprobe. When a driver originates from a module,
> consult that driver's autoprobe policy at initial device or driver attach.
> 
> Note that with TDISP, unaccepted devices do not have access to private
> memory (so called "T=0" mode). However, a deployment may still not want to
> operate more than a handful of boot devices until confirming the system
> device topology with a verifier.
> 
> Yes, this is a security vs convenience tradeoff. Yes, devices with
> non-modular drivers are out of scope. Yes, there are known regression cases
> for subsystems where device objects are expected to auto-attach outside of
> fatal probe failure. For navigating regressions, a per-module "autoprobe"
> option is included to allow fine grained policy.
> 
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Jason Gunthorpe <jgg@nvidia.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Roman Kisel <romank@linux.microsoft.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Samuel Ortiz <sameo@rivosinc.com>
> Cc: Alexey Kardashevskiy <aik@amd.com>
> Cc: Xu Yilun <yilun.xu@linux.intel.com>
> Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Danilo Krummrich <dakr@kernel.org>
> Link: http://lore.kernel.org/6971b9406d069_1d33100df@dwillia2-mobl4.notmuch [1]
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Approach seems reasonable to me.
A few trivial things inline.

Jonathan

> ---
>  drivers/base/Kconfig                  | 24 ++++++++++++++++++++++++
>  Documentation/ABI/stable/sysfs-module | 10 ++++++++++
>  drivers/base/base.h                   |  1 +
>  include/linux/module.h                | 14 ++++++++++++++
>  drivers/base/bus.c                    |  7 ++++++-
>  drivers/base/dd.c                     | 26 +++++++++++++++++++++++---
>  kernel/module/main.c                  | 13 +++++++++++++
>  7 files changed, 91 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index d4743bf978ec..7c1da5df9745 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -253,4 +253,28 @@ config CONFIDENTIAL_DEVICES
>  	depends on ARCH_HAS_CC_PLATFORM
>  	bool
>  
> +config MODULES_AUTOPROBE
> +	bool "Automatic probe of drivers from modules"
> +	default y
> +	help
> +	  Say Y for the typical and traditional Linux behavior of automatically
> +	  attaching devices to drivers when a module is loaded.
> +
> +	  Say N to opt into a threat model where userspace verification of a
> +	  device is required before driver attach. This includes Confidential
> +	  Computing use cases where the device needs to have its configuration
> +	  locked and verified by a relying party. It also includes use cases
> +	  like leaving devices with Address Translation (IOMMU protection
> +	  bypass) capability disabled until userspace attests the device and
> +	  binds a driver.
> +
> +	  This default value can be overridden by the "autoprobe" module option.
> +	  Note that some subsystems may not be prepared for autoprobe to be
> +	  disabled, take care to test your selected drivers.  Built-in drivers are

Stray extra space.

> +	  unaffected by this policy and will autoprobe unless the bus itself has
> +	  disabled autoprobe.
> +
> +	  If in doubt, say Y. The N case is only for expert configurations, and
> +	  selective "autoprobe=0" in modprobe policy is the common expectation.
> +
>  endmenu


> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 349f31bedfa1..926e120b3cc4 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -917,6 +917,12 @@ struct device_attach_data {
>  	 * driver, we'll encounter one that requests asynchronous probing.
>  	 */
>  	bool have_async;
> +
> +	/*
> +	 * On initial device arrival driver attach is subject to
> +	 * driver_autoprobe() policy.
> +	 */
> +	bool initial_probe;

I'm not sure 'initial' naming works.  How does that work with drivers that
have not autobound anyway?  E.g. VFIO.
Seems they'll be fine even if it is their initial probe.  Also the
deferred cases remain 'initial' for repeated probing.

Why not stick to the auto probing terminology here?

There is clearly history of this naming though in device_initial_probe()
So maybe that name is fine...


>  };
>  
>