From: Stephan Mueller <smueller@chronox.de>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: pebolle@tiscali.nl, andreas.steffen@strongswan.org,
tytso@mit.edu, sandyinchina@gmail.com,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org
Subject: Re: [PATCH v3 4/6] crypto: drbg - add async seeding operation
Date: Fri, 01 May 2015 06:15:58 +0200 [thread overview]
Message-ID: <1920079.qHlzZPHHdY@tauon> (raw)
In-Reply-To: <20150501031331.GA32741@gondor.apana.org.au>
Am Freitag, 1. Mai 2015, 11:13:31 schrieb Herbert Xu:
Hi Herbert,
>On Tue, Apr 28, 2015 at 05:00:03AM +0200, Stephan Mueller wrote:
>> @@ -1081,6 +1115,11 @@ static int drbg_seed(struct drbg_state *drbg, struct
>> drbg_string *pers,>
>> return -EINVAL;
>>
>> }
>>
>> + /* cancel any previously invoked seeding */
>> + mutex_unlock(&drbg->drbg_mutex);
>> + drbg_async_work_cancel(&drbg->seed_work);
>> + mutex_lock(&drbg->drbg_mutex);
>
>This seems dangerous and unnecessary. Releasing and reacquiring
>the locks may invalidate previous checks. Even if it doesn't
>matter today if somebody modifies the callers later on this could
>explode.
Agreed.
>
>You can easily remove this by making get_blocking_random_bytes_cb
>idempotent, i.e., do nothing if the work is already queued, which
>is what it would do anyway if you simply move the INIT_WORK out of
>it.
As the get_blocking_random_bytes_cb fully sets up the random_work data
structure, I think INIT_WORK should be left in there to have a nice and easy
API. Otherwise either a new call would need to be added to random.c. The
caller is not able to invoke INIT_WORK himself as the worker function is
static.
However, what about simply checking if rw->work is NULL and only then
performing the INIT_WORK? In that case then, I guess that all the members of
random_walk in get_blocking_random_bytes_cb should only be filled in if
INIT_WORK is to be called as otherwise a race may occur:
get_blocking_random_bytes_work already performs its operation on the data in
the supplied random_work and in the middle of that work, and then we would
change it with a new call to get_blocking_random_bytes_cb.
Ciao
Stephan
next prev parent reply other threads:[~2015-05-01 7:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-28 2:53 [PATCH v3 0/6] Seeding DRBG with more entropy Stephan Mueller
2015-04-28 2:54 ` [PATCH v3 1/6] random: Addition of kernel_pool Stephan Mueller
2015-04-28 2:58 ` [PATCH v3 2/6] random: Async and sync API for accessing kernel_pool Stephan Mueller
2015-04-28 2:59 ` [PATCH v3 3/6] crypto: drbg - prepare for async seeding Stephan Mueller
2015-04-28 3:00 ` [PATCH v3 4/6] crypto: drbg - add async seeding operation Stephan Mueller
2015-05-01 3:13 ` Herbert Xu
2015-05-01 4:15 ` Stephan Mueller [this message]
2015-04-28 3:00 ` [PATCH v3 5/6] crypto: drbg - use Jitter RNG to obtain seed Stephan Mueller
2015-04-28 3:01 ` [PATCH v3 6/6] crypto: add jitterentropy RNG Stephan Mueller
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=1920079.qHlzZPHHdY@tauon \
--to=smueller@chronox.de \
--cc=andreas.steffen@strongswan.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pebolle@tiscali.nl \
--cc=sandyinchina@gmail.com \
--cc=tytso@mit.edu \
/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