linux-kernel - Re: [PATCH] allow setting wiphy.perm

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-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <37210DB5-2911-4FA3-9299-7701C5003945@holtmann.org>
Date:	Mon, 11 Aug 2014 13:56:26 -0700
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Daniel Gimpelevich <daniel@...pelevich.san-francisco.ca.us>
Cc:	"John W. Linville" <linville@...driver.com>,
	"linux-wireless@...r.kernel.org Wireless" 
	<linux-wireless@...r.kernel.org>,
	Johannes Berg <johannes@...solutions.net>,
	"David S. Miller" <davem@...emloft.net>,
	Network Development <netdev@...r.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] allow setting wiphy.perm_addr after driver probe

Hi Daniel,

>> isn't this dangerous to just allow writing to wiphy.perm_addr via
>> sysfs. We ran into the same issue with Bluetooth and ROM only devices
>> that have to unique address. Doing this via sysfs seems the wrong
>> approach. It is messy and full of potential race conditions. I clearly
>> opted against the sysfs solution for Bluetooth. Instead we build an
>> infrastructure that allowed doing it cleanly via the Bluetooth mgmt
>> API. Controllers that have no unique address are brought up as
>> unconfigured and userspace clearly knows that it has to take steps to
>> get an address programmed into the controller.
> 
> My inclination is to agree; however, this does not exist for WiFi and
> implementing it would require modifying every single driver.

so what? That is not a reason to just hack something into sysfs. If it means every driver needs to be modified, then that has to be done.

>> And I think something similar should be done for WiFi. It might be
>> better to not create the initial wlan0 netdev interface if the
>> hardware has not a single unique address available. That way the
>> supplicant can just either get one from the flash filesystem or make
>> up a proper random one before creating the netdev interface.
>> 
> The initial wlan0 netdev interface is *not* created, but the PHY records
> a MAC address that cannot be overriden at the level that this sysfs node
> reads. Perhaps a compromise would be to create a single new syscall to
> write to it?

The initial wlan0 can be removed as every other netdev attached to the wiphy. It can also be as easily re-created.

Since the wiphy does not have a valid MAC address, my proposal here would be to just not create the wlan0 in the first place. This means that the wiphy can be still discovered via nl80211.

It also means that the wlan0 netdev needs to be created by userspace now. And a valid NL80211_ATTR_MAC be provided. Similar to what is already done for P2P devices at the moment. That should just solve the problem.

We really do not want to announce a netdev when registering the wiphy device and then having to mess with its MAC address via sysfs somehow. This all needs to be properly reflected over RTNL.

Regards

Marcel

--
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/