netdev - Re: wireless vs. alignment requirements

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]

Message-ID: <20071125112251.GA10039@gondor.apana.org.au>
Date:	Sun, 25 Nov 2007 19:22:51 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	dsd@...too.org, davem@...emloft.net, netdev@...r.kernel.org,
	linux-wireless@...r.kernel.org
Subject: Re: wireless vs. alignment requirements

On Sun, Nov 25, 2007 at 12:00:28PM +0100, Johannes Berg wrote:
>
> Not sure. On the one hand, yeah, that's something we should probably do,
> on the other hand this will suck because for most drivers either nothing
> needs to be done or the fixup is trivial. I suppose we should do this
> but stick in a WARN_ON_ONCE() or something, at least with mac80211 debug
> enabled.

I don't see how you can get a WARN_ON to work when you're expecting
there to be unaligned packets from time to time as the hardware
header changes.

> Also, we do plan to run these things on rather smallish embedded devices
> like APs that receive a lot of frames from many stations, and with 11n
> we're pushing speeds up by quite a bit. I'm wary of putting more code
> into the generic receive path.

Well you don't have a choice if the hardware header is really
unpredictable.  It's either that or we go and modify the entire
IP stack which penalises all the high-speed Ethernet NICs that
already get the alignment correctly.

> Well, you can receive non-QoS frames even in QoS or WPS frames in any
> other mode etc. so you can't really make any promises as which will be
> more common. Bu in practice all (sane) hardware makes sure things are
> aligned properly.

Here's an idea.  Even if you can't predict the header length of
all packets, can you at least predict the header length of the
majority of data (ones carrying IP etc.) packets?

If so then you can do the skb_reserve based on that and the fix-up
in the wireless core would be minimised.

Since I know next to nothing about the wireless transport layer,
one of you experts will need to tell me whether such a prediction
could work :)

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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