Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 10 Feb 2022 15:57:22 +0100
From:   Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To:     Sandy Harris <sandyinchina@gmail.com>
Cc:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Ted Ts'o <tytso@mit.edu>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [PATCH 0/4] random: change usage of arch_get_random_long()
Message-ID: <YgUn0uqwJXskzEzG@kroah.com>
References: <CACXcFmkC=6DsDiTbtnu=LMSsg00Lxz7jvcWNV=yDibz8suoVgw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACXcFmkC=6DsDiTbtnu=LMSsg00Lxz7jvcWNV=yDibz8suoVgw@mail.gmail.com>
Precedence: bulk

On Thu, Feb 10, 2022 at 10:28:26PM +0800, Sandy Harris wrote:
> This series of patches is not strictly necessary, but it is a
> significant improvement.
> 
> The current code has a sequence in several places that calls one or
> more of arch_get_random_long() or related functions, checks the return
> value(s) and on failure falls back to random_get_entropy(). These
> patches provide get_source_long(), which is intended to replace all
> such sequences.
> 
> This is better in several ways. It never wastes effort by calling
> arch_get_random_long() et al. when the relevant config variables are
> not set. If config variables for a hardware rng or the latent entropy
> plugin are set, then it uses those instead. It does not deliver raw
> output from any of these sources, but masks it by mixing with stored
> random data. In the fallback case it gives much more random output
> 
> In the cases where a good source is available, this adds a little
> overhead, but not much. It also saves some by not trying
> arch_get-random_long() unnecessarily.
> 
> If no better source is available, get_source_long() falls back to
> get_xtea_long(), an internal-use-only pseudorandom generator based on
> the xtea block cipher. In general, that is considerably more expensive
> than random_get_entropy(), but also provably much stronger.
> 
> With no good source, there is still a problem at boot; xtea cannot
> become secure until it is properly keyed. It does become safe
> eventually, and in the meanwhile it is certainly no worse than
> random_get_entropy().

This patch series is not actually threaded at all, and is totally
whitespace damaged.

How did you send it?  Try using 'git send-email' next time to correctly
thread them and not corrupt them so that they are unusable :(

thanks,

greg k-h