Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AB52FC4332F for ; Mon, 29 Nov 2021 15:35:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345201AbhK2PjK (ORCPT ); Mon, 29 Nov 2021 10:39:10 -0500 Received: from mo4-p02-ob.smtp.rzone.de ([85.215.255.81]:34046 "EHLO mo4-p02-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244985AbhK2PhJ (ORCPT ); Mon, 29 Nov 2021 10:37:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1638199921; s=strato-dkim-0002; d=chronox.de; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=v6c6Xn6Fs31Rf3Z7IjbdhYoA5Fgm3xF8Nq3u6kz0t6s=; b=PVA+Fg3lwJX6Jc3bKWgSVBYwLDL4eKa0zOfxy+Q5Od9SHRkvlTd04n/0tFb7MCB5f2 VEsWFyZ0jQhB6OWiF7Yr0r6e+uI70REz/RexfFCUNiE9UhEN9eBJqE2CtZIY5nRsHX5c U9HOSu8mcvSAp0QFc9j/qK+60ffC6BXkTAKYHEij8RJSH0aDWPYPuW2HP7lcCTzNkeWr lyANtSdVJOofgfjG4EiAXUqHDVuM7IJhOqSyZuuA3HLxnSk1dO1TZeFd6yFlVvS4u8TJ TKK2MceZe2VeWk0vcQC2nKZrA/IddBl7ts5YpMagxeZqqbz28zHVw9hiIIvnumqGHoKi ae/g== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":P2ERcEykfu11Y98lp/T7+hdri+uKZK8TKWEqNyiHySGSa9k9xmwdNnzGHXPbIvSX5lo=" X-RZG-CLASS-ID: mo00 Received: from tauon.chronox.de by smtp.strato.de (RZmta 47.34.10 DYNA|AUTH) with ESMTPSA id 006230xATFVxR5f (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 29 Nov 2021 16:31:59 +0100 (CET) From: Stephan Mueller To: Greg Kroah-Hartman Cc: Simo Sorce , "Jason A. Donenfeld" , Tso Ted , linux-crypto@vger.kernel.org, Willy Tarreau , Nicolai Stange , LKML , Arnd Bergmann , "Eric W. Biederman" , "Alexander E. Patrakov" , "Ahmed S. Darwish" , Matthew Garrett , Vito Caputo , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , zhangjs , Andy Lutomirski , Florian Weimer , Lennart Poettering , Peter Matthias , Marcelo Henrique Cerri , Neil Horman , Randy Dunlap , Julia Lawall , Dan Carpenter , Andy Lavr , Eric Biggers , Petr Tesarik , John Haxby , Alexander Lobakin , Jirka Hladky Subject: Re: [PATCH v43 01/15] Linux Random Number Generator Date: Mon, 29 Nov 2021 16:31:59 +0100 Message-ID: <9311513.S0ZZtNTvxh@tauon.chronox.de> In-Reply-To: References: <2036923.9o76ZdvQCi@positron.chronox.de> <22137816.pfsBpAd9cS@tauon.chronox.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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