Some questions about kernel.random.* parameters

Question

I'm trying to understand the linux kernel parameters which are under /proc/sys/kernel/random/, but I have some troubles. Could you help me figure some things out?

1. What is the boot_id parameter used for? I found just information it's generated at boot, but I was unable to find why.
2. I know that the entropy pool size is constant (4096bits) and cannot be changed. Why is the number so small? Couldn't it be, let's say, 1048576 or more? Maybe is it not good to have many bits of entropy available?
3. It's similar to the second question but concerns the entropy_avail parameter -- what is the purpose of not filling the entire pool of entropy? When I check the parameter, it oscillates around 1000 bits, but the pool size is 4096. When entropy_avail hits the threshold set in write_wakeup_threshold, it falls a little bit (usually 100), and it rises again to the point specified in write_wakeup_threshold parameter. So why do we need this 4096 in entropy poolsize?
4. Is there any reason why I should increase or decrease the value of read_wakeup_threshold and write_wakeup_threshold parameters? The first one just sleeps the process that wants entropy from the /dev/random device, but what is the difference when I set this to 64, 128 or 256? It just hangs for a little bit longer period of time, or maybe is there something else?

Answer 1

The boot ID parameter is not relevant to entropy stats really. It just uniquely identifies the current boot, which is useful if you want to know if the computer has rebooted or something.

The entropy pool stores up random data in an implementation-defined way that is designed to be treated as a black box. In general it's nice to have as many bits of entropy as you can, if you rely on having an entropy source; having too much, however, is wasteful. If your server does a lot of cryptography (generating TLS session keys for instance, or frequently generating RSA keys or even security tokens) or needs strong random numbers all the time for some other reason, you want lots of entropy and there are even devices you can get that issue gigabit streams of it (from a physical source).

The pool size can usually be changed by echoing a new size into the pool size file. The kernel will store up entropy it acquires from various sources (relative event timings is a popular way), as well as entropy it acquires from input to /dev/random (via the RNDADDENTROPY ioctl; merely writing to that device changes the data but does not add nominal bits of entropy). If you had a hardware entropy source you were underutilizing, you'd really want this parameter to not be infinite.

The write-wakeup-threshold is rarely used but is good for sequencing; the performance gain it provides should be minimal. What it does is wake up devices blocking to write to the entropy pool (i.e. sources which will use the aforementioned ioctl to add entropy to the pool) when the pool gets low. It will not necessarily have the effect of adding entropy, obviously.

The read-wakeup-threshold is opposite; this is the number of bits of entropy required to be available (i.e. the number indicated in entropy_avail) before we allow anything to read from /dev/random. /dev/urandom ignores this parameter (since reads from it are nonblocking and don't wait for entropy, instead allowing pseudorandom data to be read).