On Fri, Apr 17, 2015 at 02:55:28PM +0200, Stephan Mueller wrote:
>
> @@ -1349,7 +1348,9 @@ static int drbg_generate_long(struct drbg_state *drbg,
> unsigned int chunk = 0;
> slice = ((buflen - len) / drbg_max_request_bytes(drbg));
> chunk = slice ? drbg_max_request_bytes(drbg) : (buflen - len);
> + mutex_lock(&drbg->drbg_mutex);
> tmplen = drbg_generate(drbg, buf + len, chunk, addtl);
> + mutex_unlock(&drbg->drbg_mutex);
> if (0 >= tmplen)
> return tmplen;
BTW I just noticed that we always return 0 now so this is broken.
> @@ -1377,10 +1378,12 @@ static int drbg_generate_long(struct drbg_state *drbg,
> static int drbg_instantiate(struct drbg_state *drbg, struct drbg_string
> *pers,
> int coreref, bool pr)
> {
> - int ret = -ENOMEM;
> + int ret = -EOPNOTSUPP;
>
> pr_devel("DRBG: Initializing DRBG core %d with prediction resistance "
> "%s\n", coreref, pr ? "enabled" : "disabled");
> + mutex_init(&drbg->drbg_mutex);
This shouldn't be here because the reset function will call this
and break. This needs to be moved to cra_init.
Incidentally the whole reset concept seems redundant as you could
always free and allocate a new RNG instead. So I'm planning on
replacing it with a seed/reseed function instead. IOW it will
keep the existing state and just add in new data if it's already
seeded.
This will change our user-space API semantically but as you're the
only user I hope we won't need to add any backwards compatibility
cruft.
This also means that cra_init will no longer seed this and the RNG
won't be usable until seed is called.
Cheers,
-
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
