Re: [PATCH v4 0/3] driver core: add TAINT_FORCED_BIND for when userspace manually messes with devices and drivers

[Alex Williamson <alex@shazbot.org>]

On Sat, 24 Oct 2026 06:56:34 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Fri, Oct 23, 2026 at 06:13:26PM -0600, Alex Williamson wrote:
> > On Wed, 23 Sep 2026 12:29:56 +0200
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >   
> > > On Wed, Sep 23, 2026 at 11:54:50AM +0200, Uwe Kleine-König wrote:  
> > > > > No, drivers should NOT have to do that in their .probe() function,
> > > > > that's what we moved away from decades ago!  The match function should
> > > > > handle all of that for you, otherwise it's contant duplication
> > > > > everywhere that is unneeded.    
> > > > 
> > > > Well then you have to accept that root can provoke a null pointer
> > > > exception (e.g. by forcing the pwm-tegra driver on a device) because at
> > > > least with today's platform bus match function such a match is ok.    
> > > 
> > > Agreed, yes, root can cause a crash and can do tons of horrible things
> > > much worse than this, that's not the issue.
> > > 
> > > That's why this taint is there, to make it obvious that this is not a
> > > "real" bug at all.
> > >   
> > > > > Please, learn from our history, don't make the same mistakes.
> > > > > 
> > > > > Now I might be convinced that driver_override is the way to go here, but
> > > > > it still feels really odd as again, bind/unbind was created as a driver
> > > > > debugging option only, it should NOT be a normal operation that any user
> > > > > should rely on.  The driver should "just work" properly instead, without
> > > > > requiring manual bind work, as that's not a good model at all.    
> > > > 
> > > > I agree in principle, but (in my case wifi) drivers are buggy sometimes
> > > > (due to missing documentation and/or engineering effort) and being able
> > > > to rebind the driver instead of rebooting to get a working device again
> > > > is very useful.    
> > > 
> > > Fine, use it!  Just don't expect that to be "normal".
> > >   
> > > > So yes, theoretically bind/unbind isn't needed, but theory and practise
> > > > differ in practise.    
> > > 
> > > Agreed, but again, don't rely on this as a "real" solution fo ranything.  
> > 
> > Sorry, late to the party, but this isn't a few user scripts that rely
> > on this behavior.  Effectively every use case of vfio relies on this
> > behavior.  We rely on unbinding the default driver from the device
> > before using driver_override and drivers_probe.  That means every
> > hypervisor with device assignment and every userspace driver use case
> > now experiences a tainted kernel. That seems like a significant
> > regression.  
> 
> Or finally, a real bugfix :)
> 
> > There is currently no alternative for this process.  It's not a matter
> > of upgrading to a newer kernel where the drivers claim the device IDs.
> > We can't claim the device ID, vfio drivers represent a secondary use
> > case for the device.  
> 
> How can vfio know that it can properly talk to any device like this?
> Surely you have a list of real device ids that you know will work,
> otherwise all bets are off.

There's not a list of real device IDs.  PCI, in particular, is a
self-describing bus.  Devices are discovered via bus walk, their
resources are probed via standard mechanisms, they support interrupts
and resets as described by capabilities defined in a specification.
The vfio-pci driver just provides a generic way to represent a device
as resources mapped to file offsets with ioctls to discover those
offsets and interact with things like resets and interrupts.  For
example, PCI config space and BAR regions are just defined indexes into
the table of file offsets.  This works with any endpoint device, where
even that distinction is based on the discoverable PCI header type
rather than a table of device IDs.

Even if we could come up with a set of device IDs, it's a policy
decision whether a given device is intended by the admin to be used by
the default in-kernel driver or a userspace driver.  This policy
changes over time, within the same host session.  That means that at
one point we want the default driver bound and at another we want a
vfio driver bound.  Coordinating this is exactly why we have
driver_override and, building on that, match IDs that require
driver_override.  This allows drivers to describe themselves as vfio-pci
compatible drivers via modules.alias while requiring userspace to
enable the match via driver_override.

This is how vfio-pci variant drivers work.  These drivers contain
device specific knowledge, for instance the ability to serialize and
expose device state for migration, but they're still a secondary use
case to the in-kernel drivers.  This is effort and coordination with
subsystems and driver-core over many years and relied on by every
hypervisor, now deemed unsupported through a kernel taint before we can
even bind the driver.
 
> > A production use case of panic_on_taint now results in a hard failure
> > for a scenario that has been allowed and documented as best practice
> > for many years.  
> 
> It was never "best practice", you took a debugging option and somehow
> thought it was a valid use case.  Yes, I'm being harsh but I am sure I
> complained about this in the past and obviously never followed up on it,
> so that's on me.

I won't doubt that you know more about the history and intent of these
interfaces than nearly anyone, but I don't find any documentation or
comments that specifically declare these as debug interfaces.  In fact,
Documentation/ABI/testing/sysfs-bus-pci has documented the bind and
unbind ABI for over 20 years.

You've certainly expressed more than once that users get to keep all
the broken pieces if they bind devices to drivers that don't support
the hardware.  This is the first that it's been formalized in a
taint without warning or an escape hatch for drivers like vfio-pci that
do in fact intend to work with all hardware.  It affects the industries
that depend on this usage model.  It's a regression.

> > What's the solution we can pursue for the scenario where devices have
> > dual use cases between in-kernel drivers and userspace drivers?  Thanks,  
> 
> So what is the real use case here, taking any type of any device and
> thinking you can bind a random kernel driver to it and it will work ok?
> You all have specific platform and pci vfio drivers, why not use the
> proper device ids there instead, or better yet, bake-in this type of
> functionality into the bus-specific logic so that you can have generic
> userspace control of a device (like usbfs and uio does today)?
> 
> We have real problems with random "bind/unbind" attempts that this taint
> is here to help resolve as it was creating hundreds of false-positive
> bug reports on developers all across the tree now that the fuzzers
> decided to think this was a valid action to take.  Without this taint,
> people were being forced to add hacks to all drivers for this which is
> not an acceptable solution.

At its core, vfio is describing the fundamental aspects of a device,
regions and interrupts, without purporting to know anything about the
specific programming model of the hardware.  In the case of PCI, the
vfio-pci driver effectively decomposes the PCI representation of the
device into a set of ioctls and a file descriptor.  A userspace driver,
for example QEMU, recomposes that representation back into a virtual
PCI device to the VM with virtualization, emulation, and direct access
wired through to the physical device.

There are no devices deemed only for vfio use by default.  Often we're
unbinding a device from the host, exporting it to a userspace driver
through vfio, exposing it to a VM, only to bind the same driver to it
in the guest that it was previously using in the host.  Binding to a
vfio driver is always a secondary use case governed by the policy of
the system.  We cannot create scenarios where there are competing
drivers for a device.  The vfio driver is always brought into the
picture via driver_override, and except in the rare case where no host
driver exists, unbind must be used to release the device for
drivers_probe.

Is there some way instead that we can resolve the string written to
driver_override and only taint for non-vfio drivers?  It's a much more
confined problem if vfio drivers filter hardware outside their scope of
support in their .probe function, and I think we largely do that
already.  Thanks,

Alex