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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 8 Aug 2020 21:18:27 +0200 From: Florian Westphal <fw@...len.de> To: Willy Tarreau <w@....eu> Cc: George Spelvin <lkml@....org>, netdev@...r.kernel.org, aksecurity@...il.com, torvalds@...ux-foundation.org, edumazet@...gle.com, Jason@...c4.com, luto@...nel.org, keescook@...omium.org, tglx@...utronix.de, peterz@...radead.org, tytso@....edu, lkml.mplumb@...il.com, stephen@...workplumber.org Subject: Re: Flaw in "random32: update the net random state on interrupt and activity" Willy Tarreau <w@....eu> wrote: > diff --git a/include/linux/random.h b/include/linux/random.h > index 9ab7443bd91b..9e22973b207c 100644 > --- a/include/linux/random.h > +++ b/include/linux/random.h > @@ -12,6 +12,7 @@ > #include <linux/list.h> > #include <linux/once.h> > #include <asm/percpu.h> > +#include <linux/siphash.h> > > #include <uapi/linux/random.h> > > @@ -117,7 +118,8 @@ void prandom_seed(u32 seed); > void prandom_reseed_late(void); > > struct rnd_state { > - __u32 s1, s2, s3, s4; > + siphash_key_t key; > + uint64_t counter; > }; Does the siphash_key really need to be percpu? The counter is different of course. Alternative would be to siphash a few prandom_u32 results if the extra u64 is too much storage. > DECLARE_PER_CPU(struct rnd_state, net_rand_state); > @@ -161,12 +163,14 @@ static inline u32 __seed(u32 x, u32 m) > */ > static inline void prandom_seed_state(struct rnd_state *state, u64 seed) > { > +#if 0 > u32 i = (seed >> 32) ^ (seed << 10) ^ seed; > > state->s1 = __seed(i, 2U); > state->s2 = __seed(i, 8U); > state->s3 = __seed(i, 16U); > state->s4 = __seed(i, 128U); > +#endif > } [..] Can't we keep prandom_u32 as-is...? Most of the usage, esp. in the packet schedulers, is fine. I'd much rather have a prandom_u32_hashed() or whatever for those cases where some bits might leak to the outside and then convert those prandom_u32 users over to the siphashed version.
Powered by blists - more mailing lists