From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4566D4C8FFF; Fri, 2 Oct 2026 14:40:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790952046; cv=none; b=q6MgogrJEL6IgnXikg4dnMei1OJoEpS2HqnudEqMiooTbneA36pZ9Tb5wXf8fnQ9hc7Pm5KOVd8m25msrFjvyl9FxAXZya95nOCF6YWYv+Y0BleN3hH3DjJ9E+fxawtISSEjIVZpwGs5FXttiFJH6fSlSVgI7GMpRv7dCM/jTQk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790952046; c=relaxed/simple; bh=uRVzb4q9OnjD7ysKCgL73yda96KR80dS+yOvFv+JzNY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bUJh9f/eohYKWbDMHvx8u8GXhXASpbHTqF/i5EQRYb1wXTHn31C3hMpSFQUQXjDPPqRIzAhAYrtPUOuRkCELlIy8FBj+wanlx8kR+rIxfwVT6aN7Qado0hQ4G9ikHkhqecd91Dpol9igM0l6qvWDo5MKG4w2Bdi6hatynMi83rE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=J+Y7btEI; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="J+Y7btEI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 70BCA1F000FF; Fri, 2 Oct 2026 14:40:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790952041; bh=dcnYXBA3CEuai0qXprr2+qcXQPtBfgGrYCuvMwsvpIU=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=J+Y7btEI6wVH8SHpWF1hvukTyWhiFXJzzVeJkL7+bJGU19zujfqJ/unjYCWogXMTo aR9J8tb2IzpQO9Nb4ks1OtNadABO6C9qhhlrQHafo/jjjY5Iwc87tuv9QkTZJSBcfh vuzJ7tVkEN1RnisC829oVeGHm8bywCGfw2N2JGNHhprrqcLBllUy4wG7Z0h/JvbHjx ldxLi67QqiIzfBNBc1SYRN9+r4lN4aHwLdRxtRRrqG/rPjwJl5nkxsnIVg+7uAFZQR 06TR50wzBjO9S3VxX83nEhVID8nzGTuPE7ytLOnDW6Ow0OPXOTC1dJ+u9+A8Wnrs3+ s2mpJcE2gB+rw== Received: from johan by xi.lan with local (Exim 4.99.5) (envelope-from ) id 1xCeRC-00000009jua-3wyb; Fri, 02 Oct 2026 16:40:38 +0200 Date: Fri, 2 Oct 2026 16:40:38 +0200 From: Johan Hovold To: Dmitry Torokhov Cc: Greg Kroah-Hartman , Luis Chamberlain , Petr Pavlu , Daniel Gomez , Sami Tolvanen , Aaron Tomlin , Jonathan Corbet , Shuah Khan , Randy Dunlap , "Rafael J. Wysocki" , Danilo Krummrich , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-usb@vger.kernel.org, driver-core@lists.linux.dev, linux-trace-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] driver core: add TAINT_FORCED_BIND for when userspace manually messes with devices and drivers Message-ID: References: <20260826-bind_taint-v1-0-52b05f4a965c@linuxfoundation.org> <20260826-bind_taint-v1-2-52b05f4a965c@linuxfoundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Sep 25, 2026 at 02:19:25PM -0700, Dmitry Torokhov wrote: > On Thu, Aug 27, 2026 at 03:33:19PM +0200, Johan Hovold wrote: > > On Wed, Aug 26, 2026 at 11:19:33AM +0200, 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 > > > successfully 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. > > > > > > 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. > > > > > > Signed-off-by: Greg Kroah-Hartman > > > > This makes it clear that this is a development tool, and it is a good > > compromise preferable to adding unnecessary complexity or suppressing > > the attributes completely just to prevent root from shooting themselves > > in the foot: > > > > Reviewed-by: Johan Hovold > > Tested-by: Johan Hovold > > bind/unbind without overrides should not necessarily be treated as a > development tool. For example with I2C devices you may want to unbind > the functional driver, perform firmware update from userspace, and bind > the device again. This will ensure that driver is not confused and at > the same time you do not need to put into the kernel code that is > dormant 99.9999 percent of the time. Yeah, there are some other uses of these attributes that essentially involves switching to a user space driver (vfio, i2c-dev, libusb, ...). This is still a bit of a foot gun as many subsystems do not expect their devices to live on hotpluggable buses and will break in various ways unless you know what you are doing or happen to be lucky. So I think tainting the kernel is still warranted. This should probably have been highlighted in the commit message, though. Note that unloading the driver module in question is generally safer as the chardev implementation provides some safeguards against unloading drivers for devices that are currently in use (even if some subsystems also manages to get that wrong). Johan