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 <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 > 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
Attachment:
signature.asc
Description: PGP signature
