Re: Patch: rework kernel random number subsystem

2011-11-21 Thread Thor Lancelot Simon
On Mon, Nov 21, 2011 at 09:20:36AM +0100, Pawel Jakub Dawidek wrote: Could you tell more about performance characteristics of your implementation? If I read the code correctly, you also use single mutex in cprng_strong() around all the work. The simplest scalability test is to run 'dd

Re: Patch: rework kernel random number subsystem (*nearly final*)

2011-11-08 Thread Matthias Drochner
t...@panix.com said: There's a new patch at http://www.panix.com/~tls/rnd4.diff I've been running a system with this for a couple of hours now and it appears stable. (With rnd3.diff I got locking related panics indeed.) Just some mostly formal comments: -shouldn't the remaining uses of

Re: Patch: rework kernel random number subsystem (*nearly final*)

2011-11-08 Thread Christos Zoulas
In article 20081825.taa076...@zel459.zel.kfa-juelich.de, Matthias Drochner m.droch...@fz-juelich.de wrote: -not directly related: What is the Mersenne Twister code in libkern good for? Matt Thomas wanted to use this for network port allocation IIRC. I don't know what happened with

Patch: rework kernel random number subsystem (*nearly final*)

2011-11-07 Thread Thor Lancelot Simon
On Fri, Oct 21, 2011 at 05:15:55PM -0400, Thor Lancelot Simon wrote: I have placed a patch at http://www.panix.com/~tls/rnd1.diff which implements many changes to the generation and use of randomness in the kernel (I previously sent it to these lists directly but it seems to be too large).

Patch: rework kernel random number subsystem (*nearly final*)

2011-11-06 Thread Thor Lancelot Simon
On Fri, Oct 21, 2011 at 05:15:55PM -0400, Thor Lancelot Simon wrote: I have placed a patch at http://www.panix.com/~tls/rnd1.diff which implements many changes to the generation and use of randomness in the kernel (I previously sent it to these lists directly but it seems to be too large).

Re: Patch: rework kernel random number subsystem

2011-10-30 Thread Thor Lancelot Simon
New patch at http://www.panix.com/~tls/rnd3.diff which has Jachym Holecek's fix for the data corruption issue (which isn't, actually), makes the sysctl prng IPL_NONE, and fixes some issues revealed by LOCKDEBUG. Also, this fixes a very old and ugly bug where rnd_add_data manipulated the entropy

Re: Patch: rework kernel random number subsystem

2011-10-28 Thread Thor Lancelot Simon
On Fri, Oct 21, 2011 at 05:15:55PM -0400, Thor Lancelot Simon wrote: WARNING: #7 and #8 reveal some kind of synchronization or locking bug in this patch. #8 causes the entropy pool to log to the console whenever it supplies rekeying entropy. #7

Re: Patch: rework kernel random number subsystem

2011-10-22 Thread Mouse
The critical values for the statistical tests are set so that p=.0001, so there should be one false positive (the null hypothesis being that the data _are_ random) in 10,000 rekeyings. In that case the right thing to do is simply to rekey -- though for a hardware generator that fails the

Re: Patch: rework kernel random number subsystem

2011-10-22 Thread Thor Lancelot Simon
On Sat, Oct 22, 2011 at 04:35:42PM +, Christos Zoulas wrote: 1) + memset(r, 0, sizeof(r)); needs (*r) Indeed. 2) The code around the above memset has whitespace issues. There are a lot of KNF issues in general. I'll fix these in a final pass before I check anything in, and send

Re: Patch: rework kernel random number subsystem

2011-10-22 Thread Thor Lancelot Simon
On Sat, Oct 22, 2011 at 02:05:52AM -0400, Mouse wrote: Conservative, but not necessarily conrrect. Some systems stay up a long time, and if working hardware RNG get auto-detached whenever a 1-in-1 test trips, long-lived systems _will_ lose their RNGs. I think this is suboptimal. Two

Patch: rework kernel random number subsystem

2011-10-21 Thread Thor Lancelot Simon
I have placed a patch at http://www.panix.com/~tls/rnd1.diff which implements many changes to the generation and use of randomness in the kernel (I previously sent it to these lists directly but it seems to be too large). It is (most of) the first step in a three step process I envision for

Re: Patch: rework kernel random number subsystem

2011-10-21 Thread Simon Burge
Thor Lancelot Simon wrote: *When these generators are rekeyed, the 'rngtest' test is run on their output and the kernel will panic if it fails.* It is not the long-term intent to panic on a rngtest failure, but rather to rekey; but this is a good way to

Re: Patch: rework kernel random number subsystem

2011-10-21 Thread Thor Lancelot Simon
On Sat, Oct 22, 2011 at 01:53:39PM +1100, Simon Burge wrote: Thor Lancelot Simon wrote: *When these generators are rekeyed, the 'rngtest' test is run on their output and the kernel will panic if it fails.* It is not the long-term intent to panic on a rngtest failure,

Re: Patch: rework kernel random number subsystem

2011-10-21 Thread Thor Lancelot Simon
On Sat, Oct 22, 2011 at 02:21:09PM +1100, Simon Burge wrote: It isn't obvious form either of your messages if you want to commit that patch to the source tree before or after the rekey portion was implemented. My point is that there will be some (many? most?) Oh, for crying out loud. I

Re: Patch: rework kernel random number subsystem

2011-10-21 Thread Thor Lancelot Simon
On Fri, Oct 21, 2011 at 11:27:08PM -0400, Thor Lancelot Simon wrote: Oh, for crying out loud. I pointed out that the patch has bugs and solicited help debugging. Did you really think I intended to check it in as-is? Sorry to have been snippy about this. It's been a very long day... I