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;
MIME-Version: 1.0
References: <CACXcFmkC=6DsDiTbtnu=LMSsg00Lxz7jvcWNV=yDibz8suoVgw@mail.gmail.com>
In-Reply-To: <CACXcFmkC=6DsDiTbtnu=LMSsg00Lxz7jvcWNV=yDibz8suoVgw@mail.gmail.com>
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
Date:   Thu, 10 Feb 2022 16:10:06 +0100
Message-ID: <CAHmME9qUidkmQBfKD7gnd4m8pVJvB3RysdvZ4e9j=QJ28ZOnzQ@mail.gmail.com>
Subject: Re: [PATCH 0/4] random: change usage of arch_get_random_long()
To:     Sandy Harris <sandyinchina@gmail.com>
Cc:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        "Ted Ts'o" <tytso@mit.edu>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Herbert Xu <herbert@gondor.apana.org.au>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hard NACK on this patchset.

Issues:
- The superficial ones that Greg's mailbot is now emailing you about:
improper threading, missing sign off, bad whitespace, poor coding
style, etc
- We don't need XTEA for this; there are probably better choices these days.
- Distinction between "get_hw_long()" and arch_get_random_long()
doesn't exist, since get_random_bytes_arch() just calls
arch_get_random_long().
- Even if we did want this, replacing arch_get_random_seed_long(), a
function meant to supply a *fresh* value from a hardware source, with
something more deterministic changes the intention.
- Likewise the cycle counter is supposed to be at least a little bit
entropic, some of the time, maybe, in the best of circumstances,
perhaps... whereas expanding an XTEA key that's seeded from that same
cycle counter (in the absence of other things) at one point in time
seems clearly worse.
- Probably others, but after 10 minutes of reading this it seemed like
it wasn't worth it to go further.