linux-kernel - Re: [PATCH v6 1/5] random: Blocking API for accessing nonblocking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150518150234.GA4180@thunk.org>
Date:	Mon, 18 May 2015 11:02:34 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Stephan Mueller <smueller@...onox.de>
Cc:	Herbert Xu <herbert@...dor.apana.org.au>, pebolle@...cali.nl,
	andreas.steffen@...ongswan.org, sandyinchina@...il.com,
	linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org
Subject: Re: [PATCH v6 1/5] random: Blocking API for accessing
 nonblocking_pool

On Mon, May 18, 2015 at 03:26:13PM +0200, Stephan Mueller wrote:
> 
> I am just running into an interesting problem with a missing cancel operation: 
> a caller instantiates a DRBG handle and invokes the seeding operation. The 
> nonblocking_pool is not initialized. Therefore, the callback is put onto the 
> list for being processed later.
> 
> Now, the caller releases the DRBG handle *before* the callback is triggered.
> 
> The callback is triggered with a pointer that is invalid, but the pointer is 
> non-NULL. Therefore, I am not sure how to validate the pointer in the callback 
> function.

The simplest thing to do is to put a refcount on inside the DRBG
handle structure.  The caller instantiates the DRBG handle, and
invokes the the DRBG.  The DRBG, since it is kicking off an
asynchronous operation, increments the refcount.

Both the caller and the callback function, before they exit, drop the
refcount, and if they see the refcount is zero, they free the DRBG
handle and the memory where the random seed is to be (or has been)
deposited.

This is the same pattern that the block I/O layer uses with a bio
struct.  In the BIO case, it's important since the callback function
could have been called and returned before the caller gets control
back from the bio_submit() call.  Or the struct bio may contain an
EOPNOTSUPP error, in which case there will be no callback function
dispatched.  So long as everyone handles the refcount rules, it all
works out.

Regards,

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/