On Wed, 28 Oct 2020 19:07:28 +0100 Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, Oct 28, 2020 at 06:51:17PM +0100, Torsten Duwe wrote: > > On Mon, 19 Oct 2020 21:28:50 +0200 > > Stephan Müller <smueller@xxxxxxxxxx> wrote: > > [...] > > > * Sole use of crypto for data processing: > > [...] > > > - 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 > > [...] > > > * 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. > > > > [...] > > > - 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
