On Mon, Nov 29, 2021 at 04:31:59PM +0100, Stephan Mueller wrote: > Am Freitag, 26. November 2021, 17:22:14 CET schrieb Greg Kroah-Hartman: > > Hi Greg, > > > On Fri, Nov 26, 2021 at 05:15:59PM +0100, Stephan Mueller wrote: > > > Am Freitag, 26. November 2021, 16:44:17 CET schrieb Greg Kroah-Hartman: > > > > > > Hi Greg, > > > > > > > On Mon, Nov 22, 2021 at 09:59:01AM -0500, Simo Sorce wrote: > > > > > Jason, > > > > > have you previously produced a list of reasoned concerns with this > > > > > patchset and direction? > > > > > > > > > > This specific email is not really useful to me to understand the > > > > > concerns as it does not contain actionable suggestion or critique. > > > > > > > > > > I personally find the direction fine, and with my distribution hat on > > > > > I > > > > > can say that FIPS is essential for us and any design must include an > > > > > option to be FIPS certifiable. > > > > > > > > > > As NIST keeps improving their testing capabilities and rigorous > > > > > cryptographic design of the CSPRNGs as well as entropy sources the > > > > > kernel must also adapt. > > > > > > > > > > Stephan is providing a path forward, and I haven't seen any other > > > > > proposal, let alone code, that provide improvements in this area. > > > > > I am pretty sure the design can be improved if there is detailed and > > > > > actionable feedback on what to change. > > > > > > > > > > I hope the path forward can be one of collaboration rather then mere > > > > > opposition. > > > > > > > > Replacement of the existing code to cut over to the new one is not > > > > collaboration, it's the exact opposite. > > > > > > > > Submitting patches to the existing codebase to implement the > > > > "requirements" is the proper way forward, why has that never been done. > > > > > > It has been attempted by Nikolai Stange without avail - no comments were > > > received, let alone it was integrated. > > > > Links to the patches and discussion please? > > Please consider https://lkml.org/lkml/2020/9/21/157 That's a load of patches, some of them seem sane, what ever happened to them? Seems like the conversation got derailed by people with email server issues that prevented them from participating in public :( But that patch set is a nice way to do this, incremental changes working with the existing codebase, not trying to ignore the current code and create a separate implementation. Also, minor note, please use lore.kernel.org links, we don't have any control over lkml.org, nor can we take patches out of that site with any of our normal tools. > One side note: the LRNG patch set does not replace random.c, but provides an > additional implementation that can be selected at compile time. I am under the > impression that is an equal approach considering other areas of the kernel > like file systems, memory allocators, and similar. Sometimes, yes, it is valid to have different implementations for things that do different things in the same area (like filesystems), but for a core function of the kernel, so far the existing random maintainer has not wanted to have multiple implementations. Same goes for other parts of the kernel, it's not specific only to this one very tiny driver. As a counterpoint, we do not allow duplicate drivers that control the same hardware types in the tree. We have tried that in the past and it was a nightmare to support and maintain and just caused massive user confusion as well. One can argue that the random driver is in this same category. thanks, greg k-h
