netdev - Re: mac80211 truesize bugs

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: <1209866916.6210.39.camel@johannes.berg>
Date:	Sun, 04 May 2008 04:08:36 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	David Miller <davem@...emloft.net>, mb@...sch.de,
	netdev@...r.kernel.org, linux-wireless@...r.kernel.org
Subject: Re: mac80211 truesize bugs

On Sun, 2008-05-04 at 10:02 +0800, Herbert Xu wrote:
> On Sun, May 04, 2008 at 03:42:34AM +0200, Johannes Berg wrote:
> >
> > I'm still not sure about the dependencies between LL_MAX_HEADER,
> > dev->hard_header_len and similar. Why, for example, does ipip set it to
> > LL_MAX_HEADER + sizeof(struct iphdr)? Because it doesn't know better
> > since the packets it creates could be routed anywhere?
> 
> The difference between LL_MAX_HEADER and hard_header_len is that
> the former is a system-wide hint of how big the header can be
> and the latter is a device-specific value.
> 
> In other words, we use the former when we don't know where we
> create a packet since we don't know where it'll end up.  As such
> we allocate a generous amount of header space so that hopefully
> nobody will have to expand the header later.  However, it would
> be OK for someone to expand it but obviously it this happened
> for the majority of your traffic then you've done something wrong
> since expanding it wastes CPU resources by copying the data.
> 
> The value of hard_header_len on the other hand is used for two
> purposes at least.  First of all it is a hint of how much free
> header space there should be in a packet before it goes into a
> device (but don't rely on it).  More importantly it's the length
> of the hardware header in the packet.  The definition of the
> hardware header varies with each type of device.

Ok, thanks for the explanation. The latter probably means that I cannot
use hard_header_len since mac80211 really needs devices to show up as
ethernet devices. However, it wouldn't really help anyway if I cannot
rely on it being available.

So, what is mac80211 supposed to do? It needs up to 54 bytes of
available headroom (for an encrypted mesh packet which currently can't
really happen, but anyway) yet it cannot pskb_expand_head() either.
Cloning each packet seems even more expensive, and just like skb_orphan
subverts the purpose of the socket accounting.

johannes

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)