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 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. Thanks Stephan
