I get that when GETRANDOM is called with bitmask 00, the entropy source is from /dev/urandom, and the CSPRNG output is blocking until internal entropy pool has at least 128 bits of entropy. Is the state of the pool readable at /proc/sys/kernel/random/entropy_avail ? If it's not that one, where can I find it?

The goal here is to be able to set a custom threshold (256-bits) for entropy pool's internal state before using it to generate keys etc.

1 Answer 1


Sysctls and the blocking pool.

You can increase the value of the kernel.random.read_wakeup_threshold sysctl. This sysctl changes the behavior of the blocking pool, forcing users of the blocking pool to wait until the entropy estimate exceeds this value. From the manpage at random(4):

    This file contains the number of bits of entropy required for
    waking up processes that sleep waiting for entropy from
    /dev/random.  The default is 64.

Note however that the blocking behavior you describe only applies to the system at very early boot. Once it has enough entropy, it will change to non-blocking behavior regardless of how low the current estimate gets. This is because you only need a certain number of bits of entropy once, and can create a virtually unlimited amount of cryptographically secure pseudorandom data once you have it. The entropy estimate going down does not change this fact.

Answering your exact question

Now, is it possible to change this initial threshold for the non-blocking pool (if you don't want to learn all the nitty-gritty, skip to the end of this answer)? I suspected it was not, but I wasn't sure, so I went to consult to the most authoritative documentation available: the source. The syscall getrandom(2) is defined in the kernel randomness driver. Note that this is specific to Linux kernel 4.14 (major changes to the randomness driver were made in 4.8).

Comments added by me for clarification to the getrandom() syscall code:

SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count,
        unsigned int, flags)
    int ret;

    // If the flags bitmask is invalid, return an error.
    if (flags & ~(GRND_NONBLOCK|GRND_RANDOM))
        return -EINVAL;

    // Cap the requested size at the maximum value.
    if (count > INT_MAX)
        count = INT_MAX;

    // If the blocking pool is selected, read from it and return.
    // The _random_read() function will deal with blocking.
    if (flags & GRND_RANDOM)
        return _random_read(flags & GRND_NONBLOCK, buf, count);

    // If we get to here, we know the non-blocking pool was selected.

    // Is the CRNG ready? Evaluates true if it is not.
    if (!crng_ready()) {
        // If we want to bail out and not block, return -EAGAIN.
        if (flags & GRND_NONBLOCK)
            return -EAGAIN;

        // Otherwise, block until random bytes become available.
        ret = wait_for_random_bytes();
        if (unlikely(ret))
            return ret;

    // Finally, read from the non-blocking pool and return.
    return urandom_read(NULL, buf, count, NULL);

OK, so most of this is pretty self-evident, but what are the functions crng_ready() and wait_for_random_bytes() for? The latter is defined in the same file:

int wait_for_random_bytes(void)
    // If crng_ready() returns true (which is likely), return 0.
    if (likely(crng_ready()))
        return 0;

    // Otherwise, wait until it does return true before returning.
    return wait_event_interruptible(crng_init_wait, crng_ready());

So now we know in the definition of getrandom() that, if the non-blocking pool is selected, it will check if crng_ready() returns true. If it does not return true, then we will wait, sleeping until it does. What does crng_ready() do? It turns out it's defined as a simple macro:

#define crng_ready() (likely(crng_init > 0))

The variable starts out as zero, but what matters is where exactly it is set to 1. It appears that this is done in the crng_fast_load() function, defined here:

static int crng_fast_load(const char *cp, size_t len)
    unsigned long flags;
    char *p;

    // Enter the critical section (acquire the spinlock).
    if (!spin_trylock_irqsave(&primary_crng.lock, flags))
        return 0;

    // If crng_ready() is already true, leave the critical section and return.
    if (crng_ready()) {
        spin_unlock_irqrestore(&primary_crng.lock, flags);
        return 0;

    // Mix in the values at cp with the CRNG state. Increment crng_init_cnt
    // for each byte from cp that gets mixed in (up to len times).
    p = (unsigned char *) &primary_crng.state[4];
    while (len > 0 && crng_init_cnt < CRNG_INIT_CNT_THRESH) {
        p[crng_init_cnt % CHACHA20_KEY_SIZE] ^= *cp;
        cp++; crng_init_cnt++; len--;

    // Leave the critical section (release the spinlock).
    spin_unlock_irqrestore(&primary_crng.lock, flags);

    // If crng_init_cnt is >= CRNG_INIT_CNT_THRESH, set crng_init to 1.
    if (crng_init_cnt >= CRNG_INIT_CNT_THRESH) {
        crng_init = 1;
        pr_notice("random: fast init done\n");
    return 1;

From this, we see that crng_init_cnt is incremented for each byte which crng_fast_load() takes in. The function is called early at boot in various entropy-gathering functions to add as much possible data to the pool early on. We're almost there! Last thing to do is find out the value of CRNG_INIT_CNT_THRESH, defined here:


So it's double CHACHA20_KEY_SIZE. This one is defined in a header file, crypto/chacha20.h:

#define CHACHA20_KEY_SIZE   32

So CRNG_INIT_CNT_THRESH is 64. And there's your answer!


  • CHACHA20_KEY_SIZE is hardcoded as 32.
  • CRNG_INIT_CNT_THRESH is double CHACHA20_KEY_SIZE, making it 64.
  • crng_init_cnt is incremented for every byte of early randomness gathered.
  • When at least 64 bytes of randomness are gathered, crng_init is set to 1.
  • When crng_init is 1, crng_ready() evaluates true.
  • When crng_ready() evaluates true, getrandom() resumes and returns.

The amount of early entropy required before getrandom() resumes and returns is not in fact 128 bits. It is already hardcoded as 64 bytes (512 bits), twice the amount you wanted.

  • Thank you. I just want to point out 64 bytes is in fact 512 bits (not 256). It would be worth mentioning 64 bytes was most likely chosen because it's the internal size of the ChaCha20 CSPRNG.
    – maqp
    Commented Apr 3, 2018 at 4:18
  • @maqp Oh wow, I must have written this when I was really tired. I will correct that.
    – forest
    Commented Apr 3, 2018 at 4:20
  • 1
    I don't think 64 was chosen specifically because it is the internal size of the CSPRNG. ChaCha20 has a constant, σ, which is 16 bytes. So only 384 bytes of the input are actually random. I imagine 512 was chosen simply because it's a nice multiple of the key size, but still large enough to provide the nonce.
    – forest
    Commented Apr 3, 2018 at 4:29
  • Ah, you're right of course, the entire state is not filled with the seed. However, I wonder if both the 64-bit nonce and the 64-bit block counter are filled: is the fully seeded CSPRNG entropy 320 or 384 bits. (Regardless the 2*CHACHA20_KEY_SIZE fully initializes it.)
    – maqp
    Commented Apr 3, 2018 at 4:48
  • 1
    Yes they are, so it's 384 bits of random data when filled. I actually asked a question about how ChaCha20's keyspace under those conditions. In theory, they could get rid of σ and fill that with random data too, since it's only necessary to prevent an attacker from having too much control over the input which is not an issue for the randomness driver, but then it wouldn't be ChaCha20 anymore. In the kernel: _get_random_bytes(&crng->state[4], sizeof(__u32) * 12);.
    – forest
    Commented Apr 3, 2018 at 4:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .