d/control: Remove havged as it no longer relevant on latest kernels (!2496) · Merge requests · FreedomBox / FreedomBox

Sunil Mohan Adapa requested to merge remove-haveged into main Aug 19, 2024

Closes: Debian bug #961733.

The version of Linux kernel supported in FreedomBox is from Debian Bookworm and that is 6.1, released on Sun, 11 Dec 2022[4][5].
Around 2014, in Linux kernel version 5.4, a way to extract entropy from CPU execution jitter every second was implemented. This is similar to HAVAGE/havaged's approach[1][2]. This ensures that user space applications never hang indefinitely when entropy is not available.
Since 2020, /dev/random only blocks until it is initialized and after that never blocks. It provides cryptographically secure psuedo-random numbers after initialization (which is believed to be as good as blocking pool even for security sensitive applications). This the same behavior as getrandom() call[6]. This means that even on embedded systems, haveged is not necessary once the initialization of the random pool has been completed.
Since Feb/Mar 2022, /dev/urandom no longer provides insecure random numbers[3]. Earlier, if it was used before full initialization, it provided insecure random numbers. Now it blocks the caller until initialization and then provides cryptographically secure pseudo-random numbers. The initialization itself won't take too much time due to the "Jitter Dance" technique of extracting entropy from CPU execution jitter. The only way to request for insecure random number (without even blocking for 1 second) is to use getrandom(GRND_INSECURE) which systemd uses to initialize hash tables. This change was reverted because Jitter Dance did not work on several architectures including arm[3]. Later it was added back as an opportunistic approach, where secure random numbers would be provided by urandom if Jitter Dance worked.
Git repository for haveged mentions that it is less relevant now[7]. It also lists circumstances where haveged might still help (old kernels, user-space RNG, additional source of entry and early boot). Of these, only early boot scenario is of interest for us.
In summary, the understanding of relevance of haveged is as follows:

Request Random Number

Is this during initialization of the random pool? No:

Linux never blocks after initialization. It uses CSPRNG now instead of blocking for entropy. Yes: Is this for secure purposes? No:
- It does not block and provides insecure (or secure in most practical cases) numbers with getrandom(GRND_INSECURE), used by systemd hash tables, etc. Yes: Does the architecture provide hardware random numbers? Yes:
  - Use RDSEED (Intel/AMD) CPU instruction or HWRNG (SOCs) to initialize the random pool.
  - If on virtual machine, use virtio-rng, ACPI VM ID, etc. to initialize the random pool. No: Is this on architectures with time stamp counter? Yes:
    - The system will block for 1-2 seconds and provide secure random numbers using "Jitter Dance" (similar to haveged).
    - ARMv7 (Allwinner A20, etc.) the lowest ARM architecture we support, seems to have time stamp counters but we not sure kernel uses it and implements "Jitter Dance". No:
    - On urandom, The system will not block and provide insecure random numbers. This is as per the original definition of /dev/urandom.
    - The system will block until entropy is available through interrupts, etc.
    - haveged will likely not help here because it also requires time stamp counter provided by CPU.

Links:

Edited Aug 21, 2024 by Joseph Nuthalapati

d/control: Remove havged as it no longer relevant on latest kernels

Request Random Number

Merge request reports