Hello Greg, On Wed, Sep 23, 2026 at 11:27:11AM +0200, Greg Kroah-Hartman wrote: > On Tue, Sep 22, 2026 at 11:04:46PM +0200, Armin Wolf wrote: > > Am 22.09.26 um 15:40 schrieb David Lechner: > > > > > On 9/22/26 2:39 AM, Uwe Kleine-König wrote: > > > > On Fri, Sep 18, 2026 at 06:39:02PM +0200, Danilo Krummrich wrote: > > > > > On Mon Sep 14, 2026 at 4:30 PM CEST, Greg Kroah-Hartman wrote: > > > > > > The ability to add and remove devices from a driver through the > > > > > > sysfs > > > > > > "bind" and "unbind" files was created all those decades ago as a way > > > > > > that kernel developers can iterate faster, and provide a debugging > > > > > > way > > > > > > for users to attempt to add a new device to a driver without having > > > > > > to > > > > > > rebuild their kernel. > > > > > > > > > > > > This api over the years has been abused and recently come under a > > > > > > major > > > > > > fuzzing "attack" through tools like syzbot which decided that it > > > > > > would > > > > > > attempt to just randomly bind any driver to any type of device, > > > > > > causing > > > > > > loads of unneeded errors and pointless kernel patches to be > > > > > > generated by > > > > > > unsuspecting new developers. > > > > > > > > > > > > Handle all of this by adding a new taint flag, TAINT_FORCED_BIND, > > > > > > which > > > > > > will be set on the driver if the bind/unbind sysfs files are ever > > > > > > written to. This lets kernel developers "know" that a user is > > > > > > attempting to do something that is not normal, and as such, if the > > > > > > kernel breaks they get to keep the shiny pieces laying around on the > > > > > > floor. > > > > > > > > > > > > The flag is 'Y' which was unused, and can remembered as the user is > > > > > > "yeeting" the device being operated on here (thrown with force > > > > > > without > > > > > > regard for the thing being thrown). > > > > > > > > > > > > Note, the taint flag gets set _BEFORE_ the bind/unbind callback > > > > > > happens, > > > > > > as many times crashes/oops/warnings/failures happen within the > > > > > > callback, > > > > > > and the taint flag needs to be there to show what was being > > > > > > attempted. > > > > > > If it were to be set after the callback happens, the oops report > > > > > > would > > > > > > not properly reflect what foolishness was being attempted. > > > > > > > > > > > > Fuzzing tools like syzbot, that doesn't have hand-crafted rules to > > > > > > keep > > > > > > the tool from hitting bind/unbind, should be run with panic_on_taint > > > > > > enabled so that they fall over and don't continue on, thinking that > > > > > > they > > > > > > actually found a real issue. > > > > > > > > > > > > Userspace operations that rely on the bind/unbind files > > > > > I agree that this should be avoided. > > > > > > > > > > But I also think the biggest offender really is driver_override. > > > > > Specifically, > > > > > on a hot-pluggable bus a driver must be complient with the device > > > > > driver > > > > > lifecycle rules and hence shouldn't break on bind/unbind. I think it > > > > > would be > > > > > nice to not taint the kernel for such busses, and only taint on > > > > > driver_override, > > > > > as I think we'd still want the bug reports for such cases. > > > > > > > > > > But I think this is fine to leave for a follow-up. > > > > I fully agree. I'm fine and support tainting on driver_override, but > > > > bind/unbind are used occasionally in my bubble and I consider drivers > > > > not handling that properly buggy. > > > > I fully agree with this, drivers should correctly implement the lifecycle > > model > > and not just break when being unbound at a improper time. Drivers suffering > > from > > this can easily break this way when unloading the associated kernel module, > > so this > > taint is no solution. > > It's a "solution" in that it tells the developer "hey, the user did > something odd and unsupported". rmmod is also not a normal operation, > there's no requirement that it actually work as it's usually a "best > effort" type of thing. > > > > In the IIO subsystem, unbind/rebind is the de-facto way to reset a wedged > > > chip. > > > > > > A few examples where other reset methods were reject in favor of > > > unbind/bind: > > > > > > https://lore.kernel.org/linux-iio/20240727160216.2488ed29@jic23-huawei/ > > > > > > This needs documenting as it's custom ABI. Note that we don't often > > > accept custom ABI. Particularly not a hook that seems to reset the > > > device. If you want to do that, unbind and rebind the whole drive[r] > > > so we are in a known state etc. > > > > > > https://lore.kernel.org/linux-iio/20240720163440.03c713dc@jic23-huawei/ > > > > > > Firstly as stated below, we don't provide interfaces for this > > > because it's a heavy weight process that is most of the effort of > > > unbinding and rebinding the driver. So if you need to reset, do that. > > > > > > https://lore.kernel.org/linux-iio/20250505200609.54756520@jic23-huawei/ > > > > > > The solution is to run it once at driver bind. Similar to reset > > > below, if the usecase needs to re do it then unbinding and rebinding > > > the driver reflects the fact we are taking it effectively offline > > > for a while. > > > > > I also consider bind/unbind to be an official API to interact with devices, > > so i want to use them in the future with the WMI subsystem. > > Why? > > > AFAIK the underlying reason for this series is that some drivers break when > > being bound to unsupported devices. However IMHO drivers should verify that > > they support a given device inside their .probe callback, and the associated > > bus should only match devices with drivers that explicitly claim support for > > those devices (ignoring driver_override). > > 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. > 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. So yes, theoretically bind/unbind isn't needed, but theory and practise differ in practise. OK, as a compromise: Let's keep the taint (after all that's not destroying any functionality, just adding a hint for bug reports), and make driver_override opt-in, which should close an attack surface (mostly for fuzzers?) and so reduce the amount of bug reports instead of marking a part of them as tainted only. Best regards Uwe
signature.asc
Description: PGP signature
