random stuff (literally)

Robert Connolly robert at linuxfromscratch.org
Wed Oct 15 19:43:49 PDT 2008


http://www.openbsd.org/advisories/res_random.txt

This advisory is 11 years old.

You'll never guess what Glibc uses to randomize resolver id's... getpid(). 
resolv/res_init.c line 570.

You'll never guess what Bind9 uses to randomize resolver id's... 
gettimeofday(). lib/bind/resolv/res_init.c line 650.

{:-\

From Alt and Owl Linux:
http://www.linuxfromscratch.org/~robert/new/patches/glibc-2.8-res_randomid.diff
uses /dev/urandom.

Bind9 will need some slight modification to use the res_randomid() from libc, 
instead of it's own version.

Bind9 also uses getpid() in lib/isc/random.c if arc4random() is not found in 
libc.

I'm getting away from adding arc4random() to packages, because no one upstream 
(Glibc, Bash), nor distributions, want anything to do with it. So I'm adding 
patches to use /dev/?random directly. I still want to add arc4random() to 
Glibc for packages like Bind9, so it's there if a package will use it without 
a patch. I would like to modify arc4random to use /dev/erandom, or die, but 
packages will not expect arc4random() to return -1, so I can't, and will have 
to use gettimeofday/getpid as a backup... pretty much leaving it as it is... 
but I suppose arc4random() could exit() if /dev/erandom doesn't open.

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.

I added patches yesterday and today to make Bash use /dev/urandom for $RANDOM, 
and so Glibc's mktemp family uses /dev/urandom. I want to add mkstemps() to 
libc, because if we don't then packages (like GCC and Binutils) will use 
their own version of mktemps, which use gettimeofday().

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).

I have been neglecting a patch for Gawk to use /dev/urandom for its $random. I 
don't know if Perl has a similar feature.

robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20081015/49a0dbf2/attachment.sig>


More information about the hlfs-dev mailing list