netdev - ethtool physical identify vs netlink locking?

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20110329135252.116bf5e0@s6510>
Date:	Tue, 29 Mar 2011 13:52:52 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: ethtool physical identify vs netlink locking?

Right now if an administrator uses the ethtool function to identify network
interface, the netlink lock can be held indefinitely. In other words, doing
"ethtool -p eth1" will stop all other netlink activity. This is bad, imagine
the case of an operator doing that to find a NIC in a rack, and because of
the netlink lockout all routing daemon activity stops.

There are several possible solutions but most involve fixing all the device
drivers (24). Options:

1. Have device driver drop and reacquire rtnl() while blinking
2. Have ethtool core drop rtnl before calling device driver
3. Add per-device ethtool rtnl lock

#1 is the least disruption
#2 means additional locking maybe required for each device driver
#3 seems like excessive overhead.

Comments?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html