linux-kernel - Unbinding drivers for resources that are in use

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 13 Jun 2011 11:10:57 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Greg KH <greg@...ah.com>,
	Kernel development list <linux-kernel@...r.kernel.org>
cc:	Hans de Goede <hdegoede@...hat.com>
Subject: Unbinding drivers for resources that are in use

The kernel prevents modules from being unloaded if they are being used.  
But it doesn't have any analogous mechanism for preventing a driver 
being unbound from a device that's in use.

For example, suppose a SATA disk contains a mounted filesystem.  If the
user writes the corresponding device name to
/sys/bus/scsi/drivers/sd/unbind without unmounting the filesystem, the
drive will become inaccessible and data may be lost.  The same problem
arises with USB devices and programs using usbfs to unbind a device
from its kernel driver.

It's true that the "unbind" attribute has mode 0200 and therefore can 
be written only by the superuser.  Still, this puts the onus on 
userspace to determine whether or not a device is being used.  The 
kernel could easily keep track of this automatically and atomically 
-- userspace can't do this without races.

Therefore I'm asking if the driver core should add a refcount to every
struct device for keeping track of the number of open file references
(or other types of resource) using this device.  If this number is
nonzero, the kernel should prevent the device from being unbound from
its driver -- except of course in cases where the device has been
hot-unplugged; there's nothing we can do to prevent errors when this
happens.

Changes to the refcount would have to propagate up the device tree: If 
a device holds an important resource then we don't want any of the 
device's ancestors to become inaccessible either.  This would be easy 
to implement.

Should we do it?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/