Hi Dave, I'm just reviewing your patches right now...
On Thu, Sep 23, 2004 at 10:51:58PM -0700, David S. Miller wrote:
>
> This makes all the neigh implementations use jenkins.
> --- a/net/core/neighbour.c 2004-09-23 22:27:14 -07:00
> +++ b/net/core/neighbour.c 2004-09-23 22:27:14 -07:00
> @@ -1316,6 +1317,8 @@
> panic("cannot allocate neighbour cache hashes");
>
> memset(tbl->phash_buckets, 0, phsize);
> +
> + get_random_bytes(&tbl->hash_rnd, sizeof(tbl->hash_rnd));
>
> tbl->lock = RW_LOCK_UNLOCKED;
> init_timer(&tbl->gc_timer);
So this means you put get_random_bytes into the __init function. I
explicitly didn't want to do that (and added that _initted variable),
since at bootup time we might not have sufficient entropy yet.
This is before userspace has had time to reload the random seed saved
before shutdown, so especially on automatic-booting embedded devices
without any user interaction and never-changing flash layout (and thus
similar interrupt patterns) I think this is quite weak.
If we defer get_random_bytes() until the first neighbour is created,
this gives the system some more time to gather entropy...
That's the same reasoning we have for making the conntrack hash work
this way.
Also, wouldn't it make sense to use a new random value if we grow the
hash table? I mean it's cheap, and we make it harder for someone trying
a hash-based attack.
Anyway, maybe I'm just being too paranoid.
--
- Harald Welte <laforge@xxxxxxxxxxxx> http://www.gnumonks.org/
============================================================================
Programming is like sex: One mistake and you have to support it your lifetime
signature.asc
Description: Digital signature
|