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]

Message-ID: <f03b4330c7e9d131d9ad198900a3370de4508304.camel@gmail.com>
Date:   Thu, 04 Aug 2022 12:49:01 -0700
From:   James Prestwood <prestwoj@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, johannes@...solutions.net
Subject: Re: [RFC 1/1] net: move IFF_LIVE_ADDR_CHANGE to public flag

Forgot to CC Johannes.

Thanks

On Thu, 2022-08-04 at 12:23 -0700, James Prestwood wrote:
> On Thu, 2022-08-04 at 11:43 -0700, Jakub Kicinski wrote:
> > On Thu,  4 Aug 2022 10:43:07 -0700 James Prestwood wrote:
> > > By exposing IFF_LIVE_ADDR_CHANGE to userspace it at least gives
> > > an
> > > indication that we can successfully randomize the address and
> > > connect. In the worst case address randomization can be avoided
> > > ahead of time. A secondary win is also time, since userspace can
> > > avoid a power down unless its required which saves some time.
> > 
> > It's not a generic thing tho, it's most of an implicit argument 
> > to eth_mac_addr(). Not all netdevs are Ethernet.
> > 
> > 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.
> 
> > 
> > Perhaps we should wait for Johannes to return form vacation but my
> > immediate reaction would be to add a knob (in wireless?) that
> > controls
> > whether the reset dance is allowed.
> 
> Ok sounds good. Lets see what Johannes has to say.
>