Re: PATCH: Round 2 of octeon rng
On Tue, Oct 22, 2013 at 22:05, William Orr wrote: I guess I misunderstood, as I thought that /dev/random dumped the entropy pool, and that /dev/arandom put the random data through a stream cipher so that grabbing random data would never block. That was true some time ago, but since at least 2011 everything behaves identically to what was once /dev/arandom. Assorted other names are kept in /dev for compatibility, their behavior is not different.
Re: PATCH: Round 2 of octeon rng
Hi William, I have an almost identical diff in my tree for a driver for octeon's RNG. On which machines did you test this? I wrote mine for DSR-500. But I remember the reads had some hick-ups. Since why I did not commit the diff until now.
Re: PATCH: Round 2 of octeon rng
On Oct 23, 2013, at 4:38 AM, Paul Irofti p...@irofti.net wrote: Hi William, I have an almost identical diff in my tree for a driver for octeon's RNG. On which machines did you test this? I wrote mine for DSR-500. But I remember the reads had some hick-ups. Since why I did not commit the diff until now. I tested this on the Edge Router Lite. I experienced no such issue with it being slow on reads. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: PATCH: Round 2 of octeon rng
On Oct 22, 2013, at 11:54 PM, Ted Unangst t...@tedunangst.com wrote: On Tue, Oct 22, 2013 at 22:05, William Orr wrote: I guess I misunderstood, as I thought that /dev/random dumped the entropy pool, and that /dev/arandom put the random data through a stream cipher so that grabbing random data would never block. That was true some time ago, but since at least 2011 everything behaves identically to what was once /dev/arandom. Assorted other names are kept in /dev for compatibility, their behavior is not different. Thanks for the heads up, guess I'm still thinking in terms of Solaris and Linux. Sorry for the confusion. That doesn't change that there was a significant time difference between writing out entropy with and without my driver: With octrng: # time dd if=/dev/random of=random/out count=1M 1048576+0 records in 1048576+0 records out 536870912 bytes transferred in 354.696 secs (1513605 bytes/sec) 5m59.52s real 0m3.30s user 2m50.23s system Without octrng: # time dd if=/dev/random of=random/out count=1M 1048576+0 records in 1048576+0 records out 536870912 bytes transferred in 1187.522 secs (452093 bytes/sec) 19m49.70s real 0m2.55s user 1m48.99s system signature.asc Description: Message signed with OpenPGP using GPGMail
PATCH: Round 2 of octeon rng
Hi again tech@ This is my second attempt at a patch to add support for the octeon's onboard rng. I've fixed all of the concerns (ISC license, wrong #define, comment removal) and I've also come bearing statistics on the quality of the entropy. I dd'd 512M of /dev/random and ran the ent from http://www.fourmilab.ch/random/ 512M of /dev/random With octrng: # sysctl kern.random kern.random=tot: 232802 used: 2560 read: 326918 stirs: 5 enqs: 12575 deqs: 791 drops: 0 ledrops: 704 ed: 198 188 280 385 487 666 786 790 901 698 496 207 163 76 35 29 20 13 3 4 5 1 2 0 0 0 0 0 0 0 2 6140 sc: 6140 27 0 49 0 6359 0 0 sb: 190340 0 0 779 0 42140 0 0 # uptime 10:12PM 36 secs, 1 user, load averages: 0.48, 0.12, 0.04 # ./ent Entropy = 8.00 bits per byte. Optimum compression would reduce the size of this 536870912 byte file by 0 percent. Chi square distribution for 536870912 samples is 240.04, and randomly would exceed this value 74.09 percent of the times. Arithmetic mean value of data bytes is 127.5021 (127.5 = random). Monte Carlo value for Pi is 3.141322610 (error 0.01 percent). Serial correlation coefficient is -0.13 (totally uncorrelated = 0.0). Without octrng: # sysctl kern.random kern.random=tot: 43283 used: 2560 read: 328224 stirs: 5 enqs: 6439 deqs: 405 drops: 0 ledrops: 542 ed: 194 169 270 370 567 715 729 748 865 683 479 206 160 111 62 42 28 17 4 6 7 2 3 0 0 0 0 0 0 0 2 0 sc: 0 27 0 73 0 6339 0 0 sb: 0 0 0 1112 0 42375 0 0 # uptime 10:13PM 52 secs, 1 user, load averages: 0.61, 0.19, 0.07 # ./ent Entropy = 8.00 bits per byte. Optimum compression would reduce the size of this 536870912 byte file by 0 percent. Chi square distribution for 536870912 samples is 270.87, and randomly would exceed this value 23.64 percent of the times. Arithmetic mean value of data bytes is 127.4949 (127.5 = random). Monte Carlo value for Pi is 3.141474244 (error 0.00 percent). Serial correlation coefficient is 0.15 (totally uncorrelated = 0.0). You'll notice that there's no significant difference between the output of the two rngs. However, with octrng the dd completed in under a minute (more entropy in pool). Without, it took several minutes. If you want time output, I can add that as well. So the addition of hardware entropy has no meaningful negative effect on the quality of the entropy, and greatly increases the size of the entropy pool. Ok? Index: conf/GENERIC === RCS file: /cvs/src/sys/arch/octeon/conf/GENERIC,v retrieving revision 1.10 diff -u -b -w -p -r1.10 GENERIC --- conf/GENERIC19 Sep 2013 00:15:59 - 1.10 +++ conf/GENERIC23 Oct 2013 01:22:06 - @@ -51,3 +51,6 @@ pciide* at pci? flags 0x # IDE hard drives wd*at pciide? flags 0x + +# RNG +octrng0at iobus0 Index: conf/files.octeon === RCS file: /cvs/src/sys/arch/octeon/conf/files.octeon,v retrieving revision 1.14 diff -u -b -w -p -r1.14 files.octeon --- conf/files.octeon 15 Aug 2013 06:54:35 - 1.14 +++ conf/files.octeon 23 Oct 2013 01:22:06 - @@ -90,3 +90,8 @@ file arch/octeon/dev/octeon_pcibus.c p file arch/octeon/dev/octeon_bus_space.c file arch/octeon/octeon/pciide_machdep.c pciide + +# Onboard rng +device octrng +attach octrng at iobus +file arch/octeon/dev/octrng.coctrng Index: dev/cn30xxrnmreg.h === RCS file: dev/cn30xxrnmreg.h diff -N dev/cn30xxrnmreg.h --- /dev/null 1 Jan 1970 00:00:00 - +++ dev/cn30xxrnmreg.h 23 Oct 2013 01:22:06 - @@ -0,0 +1,40 @@ +/* $OpenBSD$ */ +/* + * Copyright (c) 2013 William Orr w...@worrbase.com + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#ifndef _CN30XXRNMREG_H_ +#define _CN30XXRNMREG_H_ + +#define RNM_REG_BASE 0x000118004000ULL +#define RNM_REG_SIZE 0xFULL + +#define RNM_REG_CTL0x000118004000ULL +#define RNM_REG_BIST 0x000118004008ULL + +#define RNM_CTL_ENT_EN 0x0001ULL +#define RNM_CTL_RNG_EN 0x0002ULL +#define RNM_CTL_RNM_RST
Re: PATCH: Round 2 of octeon rng
On Tue, Oct 22, 2013 at 18:31, William Orr wrote: You'll notice that there's no significant difference between the output of the two rngs. However, with octrng the dd completed in under a minute (more entropy in pool). Without, it took several minutes. If you want time output, I can add that as well. This doesn't make sense, because that's not how the random device works. The bits userland reads come from a stream cipher (rc4). Always. Regardless of any entropy calculations. The cipher is reseeded from time to time, again regardless of the amount of entropy. No matter how much entropy there is, a lot or a little or none at all, the device always produces output at the same speed.
Re: PATCH: Round 2 of octeon rng
On Oct 22, 2013, at 9:06 PM, Ted Unangst t...@tedunangst.com wrote: On Tue, Oct 22, 2013 at 18:31, William Orr wrote: You'll notice that there's no significant difference between the output of the two rngs. However, with octrng the dd completed in under a minute (more entropy in pool). Without, it took several minutes. If you want time output, I can add that as well. This doesn't make sense, because that's not how the random device works. The bits userland reads come from a stream cipher (rc4). Always. Regardless of any entropy calculations. The cipher is reseeded from time to time, again regardless of the amount of entropy. No matter how much entropy there is, a lot or a little or none at all, the device always produces output at the same speed. I guess I misunderstood, as I thought that /dev/random dumped the entropy pool, and that /dev/arandom put the random data through a stream cipher so that grabbing random data would never block. I can do this again with time, but pulling data from /dev/random took significantly longer without my patch than with it. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: PATCH: Round 2 of octeon rng
I can do this again with time, but pulling data from /dev/random took significantly longer without my patch than with it. That is not possible.
