netdev - Re: Endianness problem with u32 classifier hash masks

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:	Fri, 02 Nov 2007 19:23:50 -0400
From:	jamal <hadi@...erus.ca>
To:	Jarek Poplawski <jarkao2@...pl>
Cc:	Radu Rendec <radu.rendec@...s.ro>, netdev@...r.kernel.org
Subject: Re: Endianness problem with u32 classifier hash masks

On Fri, 2007-02-11 at 18:31 +0100, Jarek Poplawski wrote:
> Radu Rendec wrote:
> 
> > Hi,
> > 
> > While trying to implement u32 hashes in my shaping machine I ran into a
> > possible bug in the u32 hash/bucket computing algorithm
> > (net/sched/cls_u32.c).
> > 
> > The problem occurs only with hash masks that extend over the octet
> > boundary, on little endian machines (where htonl() actually does
> > something).
> > 
> > I'm not 100% sure this is a problem with u32 itself, but at least I'm
> > sure u32 with the same configuration would behave differently on little
> > endian and big endian machines. Detailed description of the problem and
> > proposed patch follow.
> 
> 
> I think you are right about this different behavior, so it looks like a bug.
> And since little endian way is uncontrollable in such a case, your proposal
> should be right.
> 
> But, since there is a maintainer for this, let's check what is he not payed
> for?! (Cc: Jamal Hadi Salim)
> 

Thanks for the CC Jarek - and i promise to share the loot with you when
i lay my hands on it;->

I see that given the mask described (the 0 bits bounding the two
nibbles), the same packet in that network will hit two different buckets
depending on endianness. In other words there is lack of consistency. So
good catch.
The patch would certainly resolve it.
The only thing that bothers me with the patch approach is the extra
conversion in the fast path. Radu, since this is not a show stopper -
can you give me a short time to sip on it? I am thinking it is probably
resolvable by using the right tuning at config time - one knob that
looks usable is fshift and that all this can be done at config time; but
i may need more than one coffee to get it right, but if you see it just
send a patch. I will try to use the data you used to see if i am making
any sense.

cheers,
jamal

-
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