Kernel Watch

Jon Masters summarises the latest happenings in the Linux kernel, so that you don’t have to.

Linus Torvalds announced the release of Linux 5.3. The new kernel includes support for AMD Navi GPUS among many other new features. As usual, the Kernelnewbies site has a breakdown (https://kernelnewbies.org/linux_5.3). In particular, the write-up of the work that Dave Taht (of ‘Bufferbloat’ fame) is doing to free up additional IPV4 addresses is worth following the links.

You’re so random!

One thing 5.3 did not include was a seemingly innocuous small change to the ext4 filesystem intended to improve performance. Ted Ts’o (ext4 maintainer) had pulled in the improvement, which “avoids a lot of small disk requests” when performing read-ahead (opportunistic prefetching) of certain data structures on disk. This change did improve performance, so much so that on some systems there would be far fewer disk accesses early in boot.

Alas, it is the relative timing of (hard to predict) hardware interrupts from such devices as disks that helps to seed the kernel’s random number generator – known as a PRNG or Pseudo Random Number Generator – without which it can’t generate random numbers. Since some applications desire random numbers early in the boot process, those machines would appear to hang. As a result, Linus was forced to revert the ext4 patch for “all the wrong reasons”.

Linux has relatively recently moved to a much stronger CRNG (Cryptographic Random Number Generator) that has the property of being either fully initialised and available, or will ‘block’ (wait) on reads from it until it is. You may have noticed this yourself in the form of a virtual machine taking some time to boot, until random: crng init done is displayed. Some distros might even have recommended that you install a utility to help seed the CRNG, albeit not with cryptographically strong or safe data.

The truth is that the system either has good random numbers available, or it doesn’t. Some recent x86 systems provide an RDRAND instruction that helps, but it isn’t yet universal, and there are many non-x86 systems out there.

Part of the problem, as Linus vented at length, is that userspace is expecting to get high-quality random numbers too early in boot. A lengthy discussion ensued, during which the logic of the new(ish) ‘getrandom’ system call was disputed versus the traditional filesystem interfaces of /dev/random and /dev/urandom. Only the latter doesn’t block, at possible cost of randomness. Ultimately Linus settled on a hack for 5.4-rc1. The hack exploits CPU speculative execution to add just enough random entropy early in boot to squeak by.