linux-kernel - Re: [PATCH net-next 2/3] [PATCH 2/3] netem: allow using a seeded PRNG for generating random losses

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.