Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Yann Droneaud <ydroneaud@opteya.com>
Cc: linux-crypto@vger.kernel.org,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"Jason A . Donenfeld" <Jason@zx2c4.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] crypto: testmgr - fix RNG performance in fuzz tests
Date: Mon, 27 Feb 2023 10:19:55 -0800	[thread overview]
Message-ID: <Y/z0S7u01VRM1Z6e@sol.localdomain> (raw)
In-Reply-To: <c18250f8126b92478e31817c4162286a31983f51@opteya.com>

On Mon, Feb 27, 2023 at 08:13:41AM +0000, Yann Droneaud wrote:
> > +/*
> > + * The fuzz tests use prandom instead of the normal Linux RNG since they don't
> > + * need cryptographically secure random numbers. This greatly improves the
> > + * performance of these tests, especially if they are run before the Linux RNG
> > + * has been initialized or if they are run on a lockdep-enabled kernel.
> > + */
> > +
> > +static inline void init_rnd_state(struct rnd_state *rng)
> > +{
> > + static atomic64_t next_seed;
> > +
> > + prandom_seed_state(rng, atomic64_inc_return(&next_seed));
> 
> Isn't making this deterministic defeating the purpose of fuzzing ?
> 
> Regards.

No, it's still fuzzing.  It just means that you'll no longer get different test
cases each individual time you boot the kernel.  Which seems like mostly a good
thing, since it makes test failures reproducible.

This seemed like the obvious thing to do now that we're not using an API that
doesn't provide this option.  Though now that you draw attention to it, there is
indeed a tradeoff that rare bugs will be harder to find.  I suppose that making
it deterministic ought to be a separate patch so that this one isn't doing two
different things.  I'll make this patch use get_random_u64() here instead.

- Eric

      reply	other threads:[~2023-02-27 18:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-27  5:50 [PATCH] crypto: testmgr - fix RNG performance in fuzz tests Eric Biggers
2023-02-27  8:13 ` Yann Droneaud
2023-02-27 18:19   ` Eric Biggers [this message]

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=Y/z0S7u01VRM1Z6e@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=Jason@zx2c4.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ydroneaud@opteya.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox