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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 13 Dec 2006 00:39:55 +0100
From:	Ulrich Kunitz <kune@...ne-taler.de>
To:	Michael Wu <flamingice@...rmilk.net>
Cc:	Daniel Drake <dsd@...too.org>,
	John Linville <linville@...driver.com>, netdev@...r.kernel.org
Subject: Re: d80211-drivers pull request (week-48)

On 06-12-11 21:20 Michael Wu wrote:

> On Monday 11 December 2006 20:07, Daniel Drake wrote:
> > Michael Wu wrote:
> > >       zd1211rw-d80211: Use ieee80211_tx_status
> >
> > I've thought some more about this and I'm not so sure that this is the
> > right approach.
> >
> > Can't devicescape be taught that the ZD1211 handles retries in hardware
> > and the stack doesn't need to worry about it?
> >
> All 802.11 devices have to be able to handle retries in hardware to do random 
> backoff properly. Still, the stack wants to know what happened.
> 
> > I think I remember reading that devicescape uses failed transmission
> > rate in the rate adjustment calculations. Even without this racy ack
> > system we can still achieve that - the device tells us every time it
> > retries a transmit, and then it sends a special interrupt at the end
> > saying that all retries failed.
> >
> Yes, but it also uses successful transmissions in rate adjustment.
> 
> 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. :)

Just two observations:

1) The retry-failed-interrupt message contains the destination
   MAC address of the transmitted message. 
2) We could get easily two acks for the same transmission.
3) We could get ACKs or retry-failed-interrupts for packets, for
   which no status has been requested by the upper layers.

I suggest that the skbs as buffer for the URB transmissions. Check
ACK/NAK for all packets, but still prepare the status only for
packets, which requested it. We could add a timeout value to each
packet to make sure, that we don't ACK or NAK packets, which have
been overdue.

-- 
Uli Kunitz
-
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