Discussion
Next up in Linux's initialization sequence is its harvesting of random numbers, in case you've got something to secure or want to have fun! In short this involves harvesting some initial sources of randomness.
Depending on build flags it 1st mixes in some uninitialized RAM. Then it feeds in randomness provided by the CPU (via a couple CPU-specific routines) a fixed number of times, followed by the configured UTS-name & commandline args. Then it might reseed or "credit" the entropy counter.
1/3
... under lock copies the extracted entropy out & increments an atomic count or 2, flags the system as initialized, & zeroes out the transient storage.
And to credit into an entropy counter it caps the given value to a minimum & adds it into the atomic counter. As we pass a threshold it reseeds the entropy pool, possibly enqueues some work setting an atomic flag that we're ready, invokes callbacks waiting for randomness to be initialized, ...
3/3.5!
... awakes waiting tasks in the scheduler or those waiting on a dev file, & checks an atomic ratelimit to inform its logging.
While a different threshold merely leads it to reseed under lock.
3.3/3.3 Fin for today! Tomorrow: Log buffering, & maybe more!
To mix some bytes of entropy into this "pool" it invokes the Blake2s hash function. This in turn splits the bytes up into blocks adding a counter & some magic numbers before repeatedly shuffling the bits around. Or its specially optimized on ARM32 or x86 CPUs.
There's a flag (and getter macro) for whether the CRNG is ready, in which case another helper which (once said queues are ready) enqueues itself to be called at a computed time, reinits blake2s hashing with CPU-specific seeds, ...
2/