From: Eric Biggers <ebiggers@kernel.org>
To: Thomas Huth <thuth@redhat.com>
Cc: linux-crypto@vger.kernel.org,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"Stephan Müller" <smueller@chronox.de>
Subject: Re: [PATCH 04/14] crypto: jitterentropy - Add library API
Date: Fri, 13 Nov 2026 11:57:42 -0800 [thread overview]
Message-ID: <20261113195742.GA2147@quark> (raw)
In-Reply-To: <cc552609-ece5-4f82-94b2-b00edf0f92a7@redhat.com>
On Fri, Nov 13, 2026 at 12:28:12PM +0100, Thomas Huth wrote:
> Am 18.10.26 um 22:46 schrieb Eric Biggers:
> > Make the jitterentropy RNG accessible using a regular set of functions.
> >
> > This will allow drbg.c to just access it directly, instead of going
> > through the overly-general crypto_rng abstraction.
> >
> > Later commits will remove crypto_rng.
> >
> > Note that the library API should also continue to meet all the same
> > certification requirements, including the health check which occurs on
> > the first call to crypto_jent_alloc().
> >
> > Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> > ---
> ...
> > +int crypto_jent_get_bytes(struct jitterentropy *rng, u8 *out,
> > + unsigned int out_len)
> > +{
> > + int ret;
> > +
> > + guard(mutex)(&rng->jent_lock);
> > +
> > + ret = jent_read_entropy(rng->entropy_collector, out, out_len);
> > +
> > + if (ret == -3) {
> > + /* Handle permanent health test error */
> > + /*
> > + * If the kernel was booted with fips=1, it implies that
> > + * the entire kernel acts as a FIPS 140 module. In this case
> > + * an SP800-90B permanent health test error is treated as
> > + * a FIPS module error.
> > + */
> > + if (fips_enabled)
> > + panic("Jitter RNG permanent health test failure\n");
> > +
> > + pr_err("Jitter RNG permanent health test failure\n");
> > + return -EFAULT;
> EFAULT means "bad address" in the sense of a page fault ... not sure whether
> this is the appropriate error code here? Maybe -EIO would be a better fit?
I intentionally left the EFAULT unchanged from the old code in
jent_kcapi_random(), to limit the scope of this conversion. I agree
that EFAULT is not an appropriate error code here though, and feel free
to send a separate patch that changes it to something else. Thanks!
- Eric
next prev parent reply other threads:[~2026-11-13 19:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-18 20:46 [PATCH 00/14] crypto: Remove the unnecessary crypto_rng API Eric Biggers
2026-10-18 20:46 ` [PATCH 01/14] crypto: drbg - Don't use uninitialized stack data Eric Biggers
2026-10-18 20:46 ` [PATCH 02/14] crypto: rng - Remove unnecessary inclusions of internal/rng.h Eric Biggers
2026-10-18 20:46 ` [PATCH 03/14] crypto: jitterentropy - Move health check to first use Eric Biggers
2026-10-18 20:46 ` [PATCH 04/14] crypto: jitterentropy - Add library API Eric Biggers
2026-11-13 11:28 ` Thomas Huth
2026-11-13 19:57 ` Eric Biggers [this message]
2026-10-18 20:46 ` [PATCH 05/14] crypto: drbg - Use jitterentropy " Eric Biggers
2026-10-18 20:46 ` [PATCH 06/14] crypto: drbg - Add " Eric Biggers
2026-10-18 20:46 ` [PATCH 07/14] crypto: drbg - Add self-test for " Eric Biggers
2026-10-18 20:46 ` [PATCH 08/14] crypto: algif_rng - Use DRBG and jitterentropy library APIs Eric Biggers
2026-10-18 20:46 ` [PATCH 09/14] crypto: stdrng - Reimplement "stdrng" using direct DRBG calls Eric Biggers
2026-10-18 20:46 ` [PATCH 10/14] crypto: drbg - Remove crypto_rng support Eric Biggers
2026-10-18 20:46 ` [PATCH 11/14] crypto: jitterentropy " Eric Biggers
2026-10-18 20:46 ` [PATCH 12/14] crypto: jitterentropy - Remove the kconfig prompt Eric Biggers
2026-10-18 20:46 ` [PATCH 13/14] crypto: rng - Remove the rng algorithm type Eric Biggers
2026-10-18 20:46 ` [PATCH 14/14] crypto: stdrng - Make crypto_stdrng_get_bytes() take size_t Eric Biggers
2026-11-02 1:23 ` [PATCH 00/14] crypto: Remove the unnecessary crypto_rng API Eric Biggers
2026-11-06 11:29 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261113195742.GA2147@quark \
--to=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=smueller@chronox.de \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.