netdev - Re: [PATCH 10/13]: net: Implement simple sw TX hashing.

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:	Tue, 15 Jul 2008 03:45:57 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	dada1@...mosbay.com
Cc:	herbert@...dor.apana.org.au, netdev@...r.kernel.org
Subject: Re: [PATCH 10/13]: net: Implement simple sw TX hashing.

From: Eric Dumazet <dada1@...mosbay.com>
Date: Tue, 15 Jul 2008 08:49:32 +0200

> f2(X) = X % N ;
> ->g2(X) = ((u64)X * N) >> 32;
> 
> But g2() is quite similar to g1() :)
> 
> f2() & g2() functions are different of course, but should give 
> same hash spreading if X has an uniform distribution in 32bits space.

I thought about this some more and I'm having my doubts about
this.

Let's say N is 8, this means that all values of X smaller than
0x20000000 will hash to zero.

It means that all of your entropy comes from the top 3 bits of
the X.

So like hashlimit we'd need to use jhash or something like that
to spread the bits around some more.

I also wonder if we should add hash randomization like the ipv4
routing cache.  I wonder if the performance hit is bad enough
to warrant protection against that.  After all, if you "exploit"
this hash you just end up with the performance we have today.

For now I'm leaving the modulus in there until we understand this
better.

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