Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 26 Jan 2022 14:49:03 -0800
From:   Eric Biggers <ebiggers@kernel.org>
To:     Stephan =?iso-8859-1?Q?M=FCller?= <smueller@chronox.de>
Cc:     herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org,
        simo@redhat.com, Nicolai Stange <nstange@suse.de>
Subject: Re: [PATCH 0/7] Common entropy source and DRNG management
Message-ID: <YfHP3xs6f68wR/Z/@sol.localdomain>
References: <2486550.t9SDvczpPo@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: <2486550.t9SDvczpPo@positron.chronox.de>
Precedence: bulk

On Wed, Jan 26, 2022 at 08:02:54AM +0100, Stephan M?ller wrote:
> The current code base of the kernel crypto API random number support
> leaves the task to seed and reseed the DRNG to either the caller or
> the DRNG implementation. The code in crypto/drbg.c implements its own
> seeding strategy. crypto/ansi_cprng.c does not contain any seeding
> operation. The implementation in arch/s390/crypto/prng.c has yet
> another approach for seeding. Albeit the crypto_rng_reset() contains
> a seeding logic from get_random_bytes, there is no management of
> the DRNG to ensure proper reseeding or control which entropy sources
> are used for pulling data from.

ansi_cprng looks like unused code that should be removed, as does the s390 prng.

With that being the case, what is the purpose of this patchset?

- Eric