Re: Flaw in "random32: update the net random state on interrupt and activity"

Hi Andy,

On Fri, Aug 07, 2020 at 10:55:11AM -0700, Andy Lutomirski wrote:

quoted

quoted

This is still another non-cryptographic PRNG.

Absolutely. During some discussions regarding the possibility of using
CSPRNGs, orders around hundreds of CPU cycles were mentioned for them,
which can definitely be a huge waste of precious resources for some
workloads, possibly causing the addition of a few percent extra machines
in certain environments just to keep the average load under a certain
threshold.

I think the real random.c can run plenty fast. It's ChaCha20 plus ludicrous
overhead right now. I'm working (slowly) on making the overhead go away.  I'm
hoping to have something testable in a few days.  As it stands, there is a
ton of indirection, a pile of locks, multiple time comparisons, per-node and
percpu buffers (why both?), wasted bits due to alignment, and probably other
things that can be cleaned up.  I'm trying to come up with something that is
fast and has easy-to-understand semantics.

You can follow along at:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=random/fast

Thanks, we'll see. I developed a quick test tool that's meant to be easy
to use to measure the performance impact on connect/accept. I have not
yet run it on a modified PRNG to verify if it works. I'll send it once
I've tested. I'd definitely would like to see no measurable performance
drop, and ideally even a small performance increase (as Tausworthe isn't
the lightest thing around either so we do have some little margin).

Willy