Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751471AbdGRIcS (ORCPT ); Tue, 18 Jul 2017 04:32:18 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:42858 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751349AbdGRIcQ (ORCPT ); Tue, 18 Jul 2017 04:32:16 -0400 Date: Tue, 18 Jul 2017 10:32:10 +0200 From: Greg Kroah-Hartman To: Stephan =?iso-8859-1?Q?M=FCller?= Cc: "Jason A. Donenfeld" , Arnd Bergmann , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v12 3/4] Linux Random Number Generator Message-ID: <20170718083210.GB18340@kroah.com> References: <3910055.ntkqcq1Chb@positron.chronox.de> <2686871.50X2Wu6ijA@positron.chronox.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2686871.50X2Wu6ijA@positron.chronox.de> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1141 Lines: 33 On Tue, Jul 18, 2017 at 09:59:09AM +0200, Stephan M?ller wrote: > The LRNG with the following properties: > > * noise source: interrupts timing with fast boot time seeding > > * lockless LFSR to collect raw entropy > > * use of standalone ChaCha20 based RNG with the option to use a > different DRNG selectable at compile time > > * "atomic" seeding of secondary DRBG to ensure full entropy > transport > > * instantiate one DRNG per NUMA node > > Further details including the rationale for the design choices and > properties of the LRNG together with testing is provided at [1]. > In addition, the documentation explains the conducted regression > tests to verify that the LRNG is API and ABI compatible with the > legacy /dev/random implementation. > > [1] http://www.chronox.de/lrng.html external references do not last as long as the kernel change log does :( Also a "wholesale" replacement of random.c is a major thing, why not just submit patches to fix it up to add the needed changes you feel are necessary? We don't like to have major changes like this, that's not how kernel development is done. thanks, greg k-h