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]
Message-ID: <20230814140110.0b35eb8b@hermes.local>
Date: Mon, 14 Aug 2023 14:01:10 -0700
From: Stephen Hemminger <stephen@...workplumber.org>
To: François Michel <francois.michel@...ouvain.be>
Cc: Jamal Hadi Salim <jhs@...atatu.com>, Cong Wang
 <xiyou.wangcong@...il.com>, Jiri Pirko <jiri@...nulli.us>, "David S.
 Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub
 Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 2/3] [PATCH 2/3] netem: allow using a seeded
 PRNG for generating random losses

On Mon, 14 Aug 2023 22:14:53 +0200
François Michel <francois.michel@...ouvain.be> wrote:

> Thank you very much for your comment.
> 
> I do not use prandom_u32_state() directly in order to ensure
> that the original netem behaviour is preserved when no seed is specified.
> 
> But I agree that it would be cleaner to directly use prandom_u32_state() 
> instead of get_random_u32(), if we are sure that we won't have problems 
> (e.g. short prng cycles) with the randomly generated seeds when no seed 
> is explicitly provided. If it is okay, then
> I don't see a reason to not use prandom_u32_state() directly.
> 
> I'll make an update of the patch taking these comments into account and 
> simplifying the patch.
> 
> Thank you !
> 
> François

Older versions of netem had prandom_u32_state() equivalent built inside.
The code was split out later to be usable in other places.
Over time, get_random_u32() was added because it was more random and
there were calls to unify random number usage.

The prandom was based on Tausworthe to have good long simulation cycles
and reasonable performance.

Going back to prandom always is good idea, since get_random_u32()
has addition locking and batched entropy which netem really doesn't need/want.




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ