netdev - Re: [RFC 1/1] net: move IFF_LIVE_ADDR

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]

Date:   Tue, 09 Aug 2022 21:04:20 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     James Prestwood <prestwoj@...il.com>,
        Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org
Subject: Re: [RFC 1/1] net: move IFF_LIVE_ADDR_CHANGE to public flag

On Thu, 2022-08-04 at 12:49 -0700, James Prestwood wrote:
> > > 
> > > The semantics in wireless are also a little stretched because
> > > normally
> > > if the flag is not set the netdev will _refuse_ (-EBUSY) to change
> > > the
> > > address while running, not do some crazy fw reset.
> > 
> > Sorry if I wasn't clear, but its not nl80211 doing the fw reset
> > automatically. The wireless subsystem actually completely disallows a
> > MAC change if the device is running, this flag isn't even checked.
> > This
> > means userspace has to bring the device down itself, then change the
> > MAC.
> > 
> > I plan on also modifying mac80211 to first check this flag and allow
> > a
> > live MAC change if possible. But ultimately userspace still needs to
> > be
> > aware of the support.
> > 

I'm not sure this is the right approach.

For the stated purpose (not powering down the NIC), with most mac80211
drivers the following would work:

 - add a new virtual interface of any supported type, and bring it up
 - bring down the other interface, change MAC address, bring it up again
 - remove the interface added in step 1

though obviously that's not a good way to do it!

But internally in mac80211, there's a distinction between

 ->stop() to turn off the NIC, and
 ->remove_interface() to remove the interface.

Changing the MAC address should always be possible when the interface
doesn't exist in the driver (remove_interface), but without stop()ing
the NIC.

However, obviously remove_interface() implies that you break the
connection first, and obviously you cannot change the MAC address
without breaking the connection (stopping AP, etc.)

Therefore, the semantics of this flag don't make sense - you cannot
change the MAC address in a "live" way while there's a connection, and
at least internally you need not stop the NIC to change it. Since
ethernet has no concept of a "connection" in the same way, things are
different there.

Not sure how to really solve this - perhaps a wireless-specific way of
changing the MAC address could be added, though that's quite ugly, or we
might be able to permit changing the MAC address while not active in any
way (connected, scanning etc.) by removing from/re-adding to the driver
at least as far as mac80211 is concerned.

johannes