Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 12 May 2022 16:05:40 -0700
From:   Jakub Kicinski <kuba@kernel.org>
To:     "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc:     linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
        netdev@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>
Subject: Re: [PATCH] random32: use real rng for non-deterministic randomness
Message-ID: <20220512160540.255ddd88@kernel.org>
In-Reply-To: <20220511143257.88442-1-Jason@zx2c4.com>
References: <20220511143257.88442-1-Jason@zx2c4.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, 11 May 2022 16:32:57 +0200 Jason A. Donenfeld wrote:
> random32.c has two RNGs in it: one that is meant to be used
> deterministically, with some predefined seed, and one that does the same
> exact thing as random.c, except does it poorly. The first one has some
> use cases. The second one no longer does and can be replaced with calls
> to random.c's proper random number generator.
>=20
> The relatively recent siphash-based bad random32.c code was added in
> response to concerns that the prior random32.c was too deterministic.
> Out of fears that random.c was (at the time) too slow, this code was
> anonymously contributed by somebody who was likely reusing the alias of
> long time anonymous contributor George Spelvin. Then out of that emerged
> a kind of shadow entropy gathering system, with its own tentacles
> throughout various net code, added willy nilly.
>=20
> Stop=F0=9F=91=8Fmaking=F0=9F=91=8Fcrappy=F0=9F=91=8Fbespoke=F0=9F=91=8Fra=
ndom=F0=9F=91=8Fnumber=F0=9F=91=8Fgenerators=F0=9F=91=8F.
>=20
> Fortunately, recently advances in random.c mean that we can stop playing
> with this sketchiness, and just use get_random_u32(), which is now fast
> enough. In micro benchmarks using RDPMC, I'm seeing the same median
> cycle count between the two functions, with the mean being _slightly_
> higher due to batches refilling (which we can optimize further need be).
> However, when doing *real* benchmarks of the net functions that actually
> use these random numbers, the mean cycles actually *decreased* slightly
> (with the median still staying the same), likely because the additional
> prandom code means icache misses and complexity, whereas random.c is
> generally already being used by something else nearby.
>=20
> The biggest benefit of this is that there are many users of prandom who
> probably should be using cryptographically secure random numbers. This
> makes all of those accidental cases become secure by just flipping a
> switch. Later on, we can do a tree-wide cleanup to remove the static
> inline wrapper functions that this commit adds.
>=20
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Theodore Ts'o <tytso@mit.edu>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> Jakub - If there are no objections to this plan, I intend on taking this
> through the random.git tree, which is what this commit is based on, with
> its recent siphash changes and such. -Jason

Acked-by: Jakub Kicinski <kuba@kernel.org>

I wish there was a good way to anycast to subsystem maintainers.
With 4 netdev maintainers now even name smooshing won't work.