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

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

[Leon Romanovsky]

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.

Sorry, I was on vacation and missed this change earlier. This change will
affect SR-IOV deployments around the world, which *rely* on being able to
bind a driver manually *after* virtual functions are created but before
they are used.

This is needed for two reasons: to save hardware and software resources
when creating a large number of VFs, and to allow the PCI config space to
be configured *before* the driver starts using it.

There is no in-kernel alternative.

Thanks

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

[Jason Gunthorpe]

On Mon, Oct 26, 2026 at 02:22:43PM +0200, Leon Romanovsky wrote:

> This is needed for two reasons: to save hardware and software resources
> when creating a large number of VFs, and to allow the PCI config space to
> be configured *before* the driver starts using it.
> 
> There is no in-kernel alternative.

Having userspace involved in driver binding has also always been the
plan for confidential computing needs. We cannot have a device driver
bound across some of the HW transitions like TDISP shared/private, so
there has always been an expectation of bind/unbind.

For this case the existing sysf drivers_probe is good enough for bind,
but we must have taint-free unbind for PCI devices too.

I think this patch should be reverted ASAP, it is a pretty major
regression for a lot of users.

Jason

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

[Greg Kroah-Hartman]

On Mon, Oct 26, 2026 at 03:43:12PM -0300, Jason Gunthorpe wrote:
> On Mon, Oct 26, 2026 at 02:22:43PM +0200, Leon Romanovsky wrote:
> 
> > This is needed for two reasons: to save hardware and software resources
> > when creating a large number of VFs, and to allow the PCI config space to
> > be configured *before* the driver starts using it.
> > 
> > There is no in-kernel alternative.
> 
> Having userspace involved in driver binding has also always been the
> plan for confidential computing needs. We cannot have a device driver
> bound across some of the HW transitions like TDISP shared/private, so
> there has always been an expectation of bind/unbind.

What, why?  What forces that decision?  What's wrong with the proper
driver for the hardware being bound automatically to the device?

> For this case the existing sysf drivers_probe is good enough for bind,
> but we must have taint-free unbind for PCI devices too.

Why?

> I think this patch should be reverted ASAP, it is a pretty major
> regression for a lot of users.

But this use case hasn't even happened yet, so what would regress?

I'm not talking about the vfio thing, that's different here...

thanks,

greg k-h

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

[Greg Kroah-Hartman]

On Mon, Oct 26, 2026 at 02:22:43PM +0200, Leon Romanovsky 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.
> 
> Sorry, I was on vacation and missed this change earlier. This change will
> affect SR-IOV deployments around the world, which *rely* on being able to
> bind a driver manually *after* virtual functions are created but before
> they are used.

Why can't a real driver bind to those virtual functions?  Like is
happening in the rust apis?

> This is needed for two reasons: to save hardware and software resources
> when creating a large number of VFs, and to allow the PCI config space to
> be configured *before* the driver starts using it.

How is hardware and software resources an issue here at all?  And you
can write to PCI config space from userspace today, no driver needed
anywhere at all, that's always been allowed.

> There is no in-kernel alternative.

Then just don't have a in-kernel driver for the device and all is good?

thanks,

greg k-h

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

[Jason Gunthorpe]

On Mon, Oct 26, 2026 at 09:05:06PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Oct 26, 2026 at 03:43:12PM -0300, Jason Gunthorpe wrote:
> > On Mon, Oct 26, 2026 at 02:22:43PM +0200, Leon Romanovsky wrote:
> > 
> > > This is needed for two reasons: to save hardware and software resources
> > > when creating a large number of VFs, and to allow the PCI config space to
> > > be configured *before* the driver starts using it.
> > > 
> > > There is no in-kernel alternative.
> > 
> > Having userspace involved in driver binding has also always been the
> > plan for confidential computing needs. We cannot have a device driver
> > bound across some of the HW transitions like TDISP shared/private, so
> > there has always been an expectation of bind/unbind.
> 
> What, why?  What forces that decision?  What's wrong with the proper
> driver for the hardware being bound automatically to the device?

It would be a proper driver, with a real match. I would expect this to
be done with sysfs driver_probe, which is like bind, except it doesn't
override the matches, AFAIK.

There are two sort of related isues. Userspace is in charge of
sequencing the new PCI features like link encryption and TDISP. They
have complex authentication policies tied to them so the kernel can't
reasonably do it. These features change how the CPU does address
translation, effectively it adds/removes the iommu - and that can't be
changed while the DMA API is active or it breaks every translation in
effect.

So.. We need a gap a system boot when the driver is not bound so the
PCI stuff can be done prior to driver_probe, and a gap if there is a
PCIe error of some kind to do error recovery and go back to the start
to reauthenticate and reload.

> > For this case the existing sysf drivers_probe is good enough for bind,
> > but we must have taint-free unbind for PCI devices too.
>
> Why?

See above. That should be the easiest thing to ask for! PCI is hot
plug, disabling unbind makes zero sense from any way you look at it.

> > I think this patch should be reverted ASAP, it is a pretty major
> > regression for a lot of users.
> 
> But this use case hasn't even happened yet, so what would regress?

I'm reflecting the other commentators, I care about VFIO too. I think
tainting every hypervisor is unacceptable.

But for CC I find myself one of the maintainers for that now and many
people have been diligently working on this bind/unbind direction for
a long time now. If it goes away I have no idea what could replace it.

Jason

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

[Jason Gunthorpe]

On Mon, Oct 26, 2026 at 09:27:25PM +0100, Greg Kroah-Hartman wrote:
> > > 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.
> > 
> > Sorry, I was on vacation and missed this change earlier. This change will
> > affect SR-IOV deployments around the world, which *rely* on being able to
> > bind a driver manually *after* virtual functions are created but before
> > they are used.
> 
> Why can't a real driver bind to those virtual functions?  Like is
> happening in the rust apis?

Most people using SRIOV will bind the VFs to the VFIO driver.

The rest, it is the same as the CC case, there needs to be a gap after
creating the PCI VF functions and before binding a real driver, with a
proper match and a correct id.

This is usually managed by clearing drivers_autoprobe

Ie look at commit b8c5cec23d5c ("Driver core: udev triggered
device-<>driver binding") from 2007 explaining this workflow.

The taint on sysfs unbind makes zero sense here because we can trigger
unbind of those VFs just by disabling SRIOV through sysfs. Should we
taint that too?

> > This is needed for two reasons: to save hardware and software resources
> > when creating a large number of VFs, and to allow the PCI config space to
> > be configured *before* the driver starts using it.
> 
> How is hardware and software resources an issue here at all? 

If you create a 1024 VFs, which is what people on big servers seem to
do, then that can use 1024 x megabytes of resources to load all those
drivers which will memory exhaust a hypervisor.

This is a real case actual users run into, I saw the support requests
go by :|

> And you can write to PCI config space from userspace today, 

Not allowed in lockdown, triggered by secure boot, which pretty much
every server uses.

> > There is no in-kernel alternative.
> 
> Then just don't have a in-kernel driver for the device and all is good?

What? How do you use the HW then? Is this a serious reply?

Jason

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

[Leon Romanovsky]

On Mon, Oct 26, 2026 at 09:27:25PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Oct 26, 2026 at 02:22:43PM +0200, Leon Romanovsky 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.
> > 
> > Sorry, I was on vacation and missed this change earlier. This change will
> > affect SR-IOV deployments around the world, which *rely* on being able to
> > bind a driver manually *after* virtual functions are created but before
> > they are used.
> 
> Why can't a real driver bind to those virtual functions?  Like is
> happening in the rust apis?

The actual driver is also bound, but at a later stage. I'm not sure what you
mean by “Rust APIs.”

> 
> > This is needed for two reasons: to save hardware and software resources
> > when creating a large number of VFs, and to allow the PCI config space to
> > be configured *before* the driver starts using it.
> 
> How is hardware and software resources an issue here at all?  And you
> can write to PCI config space from userspace today, no driver needed
> anywhere at all, that's always been allowed.

According to the PCI spec—or, at least, the common interpretation of it—
newly created VFs should have equivalent hardware-resource partitions.
For most hardware resources, this is not an issue. One resource, however,
is critical to partition correctly: the number of MSI-X vectors per VF.
These vectors are backed by physical resources and directly affect
performance and utilization.

In a correctly configured system, the number of MSI-X vectors should
match the number of CPUs assigned to the VM. More vectors can leave
hardware underutilized; fewer can degrade performance.

The workflow for cloud operators is therefore:

1. Create a large number of VFs, but do not assign them yet.
2. Lease a VM to a user and determine how many CPUs they requested.
3. Repartition the internal MSI-X table allocation.
4. Assign the VF to the user.
5. Check how many MSI-X vectors remain available, then return to step 2.

The MSI-X table size is read near the beginning of driver initialization
and cannot be changed afterward.

So, no—you cannot change those PCI values without breaking the driver
and OS that are already running.

> 
> > There is no in-kernel alternative.
> 
> Then just don't have a in-kernel driver for the device and all is good?

In addition to Jason's comments, the PF and VF share the same driver because
they are nearly identical, apart from a few differences in PCI
configuration space.

Please revert the series ASAP, you are clearly breaking existing deployments.

Thanks

> 
> thanks,
> 
> greg k-h
>