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
