[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200810145318.GB9060@1wt.eu>
Date: Mon, 10 Aug 2020 16:53:18 +0200
From: Willy Tarreau <w@....eu>
To: Florian Westphal <fw@...len.de>
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: [DRAFT PATCH] random32: make prandom_u32() output unpredictable
On Mon, Aug 10, 2020 at 02:03:02PM +0200, Florian Westphal wrote:
> As this relates to networking, you could also hook perturbation into rx/tx
> softirq processing. E.g. once for each new napi poll round or only once
> for each softnet invocation, depending on cost.
I was wondering what/where to add some processing. I was thinking about
having a per_cpu "noise" variable that would get mixed with the randoms
when generated. This "noise" would need to be global so that we can easily
append to it. For example on the network path it would be nice to use
checksums but nowadays they're not calculated anymore.
> IIRC the proposed draft left a unused prandom_seed() stub around, you could
> re-use that to place extra data to include in the hash in percpu data.
Probably. What I saw was that prandom_seed() expected to perform a full
(hence slow) reseed. Instead I'd like to do something cheap. I like the
principle of "noise" in that it doesn't promise to bring any security,
only to perturb a little bit.
Willy
Powered by blists - more mailing lists