On 2012/10/12 03:50, Eitan Adler wrote:
On 11 October 2012 07:44, Pawel Jakub Dawidek <p...@freebsd.org> wrote:
On Tue, Oct 09, 2012 at 01:51:05PM -0400, Eitan Adler wrote:
On 9 October 2012 13:27, <m...@freebsd.org> wrote:
The original behavior can be recovered by using inline assembly to
fetch the value from a register into a local C variable; this would at
least not rely on undefined behavior. But I agree it's of dubious
value anyways.
I proposed this (with a patch). We want to move to not using
/dev/random and instead make a kernel system call directly. The patch
for this is not finished yet though.
You should do something similar to:
http://people.freebsd.org/~pjd/patches/libc_arc4random.c.patch
Yes, this is exactly the proposed "correct" fix. I haven't had time to
properly write and test such a patch though, so I opted for this one
in the meantime.
FWIW, the man page *used* to contain the text
The srandomdev() routine initializes a state array using the random(4)
random number device which returns good random numbers, suitable for
cryptographic use.
which made this problem 'worse' as it mislead people into believing
rand/random could be used for crpyto.
des@ fixed this problem already
As you may already know, this issue was pointed out by Xi Wang in his paper
"Undefined Behavior: Who Moved My Code?" at APSYS 2012 conference:
http://apsys2012.kaist.ac.kr/media/papers/apsys2012-final42.pdf
The bottom line is don't use uninitialized memory as a source of entropy :-)
Kevin
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
