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: <20150519135028.GC20421@thunk.org>
Date:	Tue, 19 May 2015 09:50:28 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	Stephan Mueller <smueller@...onox.de>, 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 Tue, May 19, 2015 at 03:51:55PM +0800, Herbert Xu wrote:
> On Tue, May 19, 2015 at 09:35:15AM +0200, Stephan Mueller wrote:
> > 
> > Thank you for the hints. I will follow your guidance.
> > 
> > Just for my edification: why is this (rather complex sounding) approach 
> > preferred over a simple cancel API? Other async APIs (e.g. the AIO syscalls 
> > with io_cancel) have such cancel operations.
> > 
> > Such cancel function would be as simple as:
> 
> You're right.  The cancel function is indeed simpler.  I can
> certainly live with that.

I'm not at all convinced it's simpler.  I see it add a huge amount of
hair to drivers/char/random.c that is only used by a single caller.

I'm also not sure I understand herbert's suggstion of adding a struct
module to the /dev/random code.  Why is this helpful, and what is the
race that you are trying to protect against?

Finally, this is only going to block *once*, when the system is
initially botting up.  Why is it so important that we get the
asynchronous nature of this right, and why can't we solve it simply by
just simply doing the work in a workqueue, with a completion barrier
getting triggered once /dev/random initializes itself, and just simply
blocking the module unload until /dev/random is initialized?

	     	    	   	 	     - 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/