On Mon, Nov 02, 2020 at 02:44:35PM +0100, Torsten Duwe wrote:

On Wed, 28 Oct 2020 19:07:28 +0100
Greg Kroah-Hartman [off-list ref] wrote:

quoted

On Wed, Oct 28, 2020 at 06:51:17PM +0100, Torsten Duwe wrote:

quoted

On Mon, 19 Oct 2020 21:28:50 +0200
Stephan Müller [off-list ref] wrote:
[...]

quoted

* Sole use of crypto for data processing:

[...]

quoted

 - The LRNG uses only properly defined and implemented
cryptographic algorithms unlike the use of the SHA-1
transformation in the existing /dev/random implementation.

 - Hash operations use NUMA-node-local hash instances to benefit
large parallel systems.

 - LRNG uses limited number of data post-processing steps

[...]

quoted

* Performance

 - Faster by up to 75% in the critical code path of the interrupt
handler depending on data collection size configurable at kernel
compile time - the default is about equal in performance with
existing /dev/random as outlined in [2] section 4.2.

[...]

quoted

 - ChaCha20 DRNG is significantly faster as implemented in the
existing /dev/random as demonstrated with [2] table 2.

 - Faster entropy collection during boot time to reach fully
seeded level, including on virtual systems or systems with SSDs as
outlined in [2] section 4.1.

* Testing

[...]

So we now have 2 proposals for a state-of-the-art RNG, and over a
month without a single comment on-topic from any `get_maintainer.pl`

I don't want to emphasise the certification aspects so much. The
interrelation is rather that those certifications require certain
code features, features which are reasonable per se. But the
current code is lagging way behind.

I see the focus namely on performance, scalability, testability and
virtualisation. And it certainly is an advantage to use the code
already present under crypto, with its optimisations, and not rely
on some home brew.

Can we please have a discussion about how to proceed?
Ted, Greg, Arnd: which approach would you prefer?

Greg and Arnd are not the random driver maintainers, as is now
correctly shown in the 5.10-rc1 MAINTAINERS file, so I doubt we (well
at least I) have any say here, sorry.

No problem. get_maintainer (for the proposals) works on paths, not on
topics and I didn't want to leave anybody out.

Ted, if you don't have the time any more to take care of /dev/random,
it's not a shame to hand over maintainership, especially given your
long history of Linux contributions.

Please do seriously consider to hand it over to someone new. This would
be a good opportunity.

	Torsten

I'd like to help with any solution upstream decide to follow either
testing or with code. I understand some of the concerns the community
has regarding FIPS but that doesn't make it less relevant and it's
totally possible to improve /dev/random while allowing it users to
decide if they want to comply to SP 800 90B. I believe the main
blocker now is the lack of direction.

-- 
Regards,
Marcelo