random stuff (literally)

Jan Dvorak jan.dvorak at sitronicsts.com
Thu Oct 16 00:35:39 PDT 2008


> arc4random() works in a chroot, but the new ssp routines in Glibc
> need /dev/?random in the chroot (using arc4random() with ssp will pull
> too much code into ld.so). So since we need /dev/?random for ssp, other
> stuff like mkstemp() can depend on the device in the chroot too.

No problem, just `cp -a` them. You need /dev/null in chroot anyway.

> I added patches yesterday and today to make Bash use /dev/urandom for
> $RANDOM,

mordae at dvorak:~$ RANDOM=1
mordae at dvorak:~$ echo $RANDOM
16838
mordae at dvorak:~$ echo $RANDOM
5758
mordae at dvorak:~$ RANDOM=2
mordae at dvorak:~$ echo $RANDOM
908
mordae at dvorak:~$ RANDOM=1
mordae at dvorak:~$ echo $RANDOM
16838
mordae at dvorak:~$ echo $RANDOM
5758

So throw the patch away, you are screwing things. It's documented and must 
behave like this. If you want to use it with arc4random(), you must ensure 
that once it's seeded by a number, old behavior returns.

> All this is heavy use of /dev/urandom, especially ssp, so /dev/erandom
> becomes more important. I've tried ssp using /dev/urandom with random
> number gathering daemon, and while the kernel entropy pool never runs
> empty, the rngd uses 50% cpu to keep up with demand. So /dev/erandom is
> the only thing that makes sense, and I can't really blame Glibc and
> others from using cheap entropy (blame the kernel developers for not
> providing it with aes).

Well... gettimeofday() is +/- safe. On smp systems it's IMO unpredictable 
unless you block (n - 1) cores with 100% load. It's safe enough for 
temporary files of non-critical applications (no, compiler is not critical 
in this case).





More information about the hlfs-dev mailing list