netdev - Re: [PATCH] Make simple TX hash little endian safe.

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] [day] [month] [year] [list]

Date:	Mon, 21 Jul 2008 19:20:01 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	David Miller <davem@...emloft.net>
Cc:	andi@...stfloor.org, netdev@...r.kernel.org
Subject: Re: [PATCH] Make simple TX hash little endian safe.

On Mon, Jul 21, 2008 at 09:44:33AM -0700, David Miller wrote:
> From: Andi Kleen <andi@...stfloor.org>
> Date: Mon, 21 Jul 2008 10:48:07 +0200
> 
> > Currently it will not use the lower
> > bits at all on big endian system, mapping e.g. all connections to a single
> > queue on a local network which only differs in the low bits.
> > 
> > Also fold the upper 16 bits always in the lower 16bits.
> > 
> > Signed-off-by: Andi Kleen <ak@...ux.intel.com>
> 
> I plan to make this use jhash plus a reciprocol multiply
> to fix the hash effectiveness as well as get rid of the
> modulus and make the hash not attackable.

Ok makes sense to use jhash and also the multiplication.

Hmm but randomizations means it won't be stable on benchmarks, will it?
Is attacking such a hash really a problem? Having stable performance
on benchmarks might be preferable.

The other thing (one of my favourite pet peeves) is that
get_random_bytes() on reasonably early kernel boot
is not very random because there will be hardly any entropy in the pool.
So I'm not sure it is actually particularly non predictible,
at least on systems who transmit packets early.

-Andi

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