netdev - Re: d80211-drivers pull request (week-48)

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

Date:	Mon, 11 Dec 2006 22:51:16 -0500
From:	Daniel Drake <dsd@...too.org>
To:	Michael Wu <flamingice@...rmilk.net>
CC:	John Linville <linville@...driver.com>, netdev@...r.kernel.org,
	Ulrich Kunitz <kune@...ne-taler.de>
Subject: Re: d80211-drivers pull request (week-48)

Michael Wu wrote:
> I don't think this race is such a big deal. It will only happen when someone 
> is really trying to mess with the link, and would cause the rate control to 
> jump to the highest speed. However, if someone is really trying to mess with 
> the link this way, the stability of the link is in trouble anyways. Wait for 
> stations to send frames, and send an ack for every unicast frame - everyone 
> will get confused. To actually mess with this code, the attacker would have 
> to transmit acks nearly continuously as it can't tell exactly when is a good 
> time to screw things up, and the driver recovers as soon as the queue is 
> emptied. Someone transmitting all the time is a problem for all wireless 
> cards. :)

It's ugly, in my mind not necessary, and it will kill performance. We 
haven't had to make such compromises in a long time. We got a large TX 
speed boost when the driver was modified to queue up multiple transmit 
URBs (i.e. don't wait for URB completion of the first) at the same time 
early during driver development. And even with that we're still a fair 
distance from the performance of the vendor driver.

While the stack isn't so well suited for this device I'd much prefer to 
see a more simplistic workaround. For example, assume all packets were 
successful but then report a failure when an interrupt comes in. Or, if 
the stack won't accept out-of-the-blue notifications like that, then 
maintain a counter which is incremented when a failure is reported, and 
when transmitting the next few frames report them as failed and 
decrement the counter (while counter > 0). Maybe disable rate control 
until we can come up with a nicer solution.

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