netdev - Re: [PATCH] Stochastic Fair Blue queue discipline

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:	Thu, 10 Apr 2008 09:36:52 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Juliusz Chroboczek <Juliusz.Chroboczek@....jussieu.fr>,
	netdev@...r.kernel.org
Subject: Re: [PATCH] Stochastic Fair Blue queue discipline

> Well, if I'm not mistaken net_random() used to be a function
> (in net/core/utils.c) that didn't have this problem. 

Correct it's a regression.

> So these
> problems seem to have been introduced by the conversion to
> srandom().

I think the per CPU ness was generally a mistake, it was a misguided
optimization and hurts

Iff someone really needs per cpu RNDs the better way would have been
to add a rand_r() like interface with explicit state and only do 
that in that particular caller.

Also I think a lot of get_random_bytes() shouldn't really be using it 
because they don't need precious cryptographically strong entropy,
but rather should get their data from another RND which has been
seeded once from the entropy pool only.

-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