Is `jitterentropy-rngd` daemon and/or `jitterentropy_rng.k` kernel module still useful in modern kernels?

[adrelanos]

Due to https://github.com/QubesOS/qubes-issues/issues/4169#issuecomment-1173063459 I was hoping I could ask something very specific.

1. Is jitterentropy-rngd daemon still useful recent kernel versions? Would you recommend security-focused operating systems to install the jitterentropy-rngd package by default?

2. Is jitterentropy_rng.ko kernel module still useful with recent kernel versions? Would you recommend security-focused operating systems to built the jitterentropy_rng.ko statically in the kernel?

3. Do you have other suggestions of steps that security-focused operating systems could realistically take to improve kernel entropy quality, security?

---

• What is "realistic": Pre-configuration changes; package default installation; kernel modules loading, kernel compilation configuration.
• What is "unrealistic" (for the one asking): Maintaining a fork of the Linux kernel, a huge scope project such as lrng with lots of research, development and unfortunately also Linux kernel politics works required.

---

To allow this post to age well... What could be considered a recent kernel version at time of writing? Let's say 5.18.5.

[smuellerDD]

Am Sonntag, 3. Juli 2022, 13:43:53 CEST schrieb Patrick Schleizer:

Hi Patrick,

Due to https://github.com/QubesOS/qubes-issues/issues/4169#issuecomment-1173063459 I was hoping I could ask something very specific.

1. Is jitterentropy-rngd daemon still useful recent kernel versions?

Yes, because it wakes up periodically and inserts entropy into the kernel.

Would you recommend security-focused operating systems to install the [jitterentropy-rngd](https://packages.debian.org/bullseye/jitterentropy-r ngd) package by default?

I would.

With the presence of ESDM, I would look deeper into ESDM whether it is viable to me, because the entropy management is more in line with common approaches.

2. Is jitterentropy_rng.ko kernel module still useful with recent kernel versions?

It is still as useful as I mentioned in your referenced email:

https://download.whonix.org/developer-meta-files/old-whonix-mailinglist-mailman-v2/www.whonix.org/pipermail/whonix-devel/2019-April/001371.html

So, for /dev/random without additional patches it is of no use.

Would you recommend security-focused operating systems to built the jitterentropy_rng.ko statically in the kernel?

I find it unnecessary given the rationale above and considering that the in- kernel DRBG's main use is to provide a random IV for GCM.

3. Do you have other suggestions of steps that security-focused operating systems could realistically take to improve kernel entropy quality, security?

You have the options:

• jitterentropy-rngd as already discussed

• a large kernel patch, the LRNG

• the new ESDM user space mechanism that provides an API/ABI drop-in replacement for /dev/random, /dev/urandom, and getrandom(2) that is completely unprivileged. It works without any kernel patches, but offers patches to add yet additional entropy sources. It is feature complete.

I explicitly exclude the option to not do anything and leave all as it is, because the latest changes to /dev/random alter the complete algorithmic part such that it less and less covers requirements from known standards.

---

• What is "realistic": Pre-configuration changes; package default installation; kernel modules loading, kernel compilation configuration. * What is "unrealistic" (for the one asking): Maintaining a fork of the Linux kernel, a huge scope project such as lrng with lots of research, development and unfortunately also Linux kernel politics works required.

Maybe the ESDM is a solution that could be of help here? It is exactly LRNG but in user space. The code is basically duplicated and works entirely unprivileged in user space.

---

To allow this post to age well... What could be considered a recent kernel version at time of writing? Let's say 5.18.5.

With respect to our discussion, all LTS kernels (which are stable kernels (!)) at the time of writing (>= 5.15.44, >= 5.10.120, >= 5.4.203, >= 4.19.250, >= 4.14.286, >= 4.9.321) now received the complete rewrite of random.c. I find it frightning that the rewrite of random.c that appeared in 5.18.1 (again, a stable kernel) is now backported to all LTS kernels as part of their stable(!) maintenance.

Ciao Stephan

[krishjainx]

@smuellerDD Hi, sorry, I don't understand what you mean by "So, for /dev/random without additional patches it is of no use." could you please elaborate? In addition, would it be possible to provide a dkms configuration so the module could rebuild against new kernel sources on kernel upgrades. Thank you !

[smuellerDD]

Am Mittwoch, 20. Juli 2022, 00:15:29 CEST schrieb Krish-sysadmin:

Hi Krish,

@smuellerDD Hi, sorry, I don't understand what you mean by "So, for /dev/random without additional patches it is of no use." could you please elaborate? In addition, would it be possible to provide a dkms configuration so the module could rebuild against new kernel sources on kernel upgrades. Thank you !

Starting with 5.6 when the nonblocking pool was removed, the kernel never woke up user space rngds after it was initially seeded.

If you want to once in a while provide entropy from your rngd to the kernel you need to actively wake up and insert it.

Note, there are several considerations at play:

1. Try to get the kernel RNG seeded as fast as possible with any available entropy -> no change is necessary to user space rngds

2. If you do not fully trust the entropy sources the kernel utilizes (typically the IRQ entropy source only (HID/disk entropy sources are just a derivative of IRQs), maybe you have a HW-Rand entropy source too) and you want your user space rngd to provide entropy, you cannot rely on the kernel to wake you up any more. -> change to rngd is needed

Ciao Stephan

[krishjainx]

Ah @smuellerDD . Thank you I understand. So I'm using Fedora and would love to test this project and add more entropy to the kernel. I set random.trust_cpu=off. Now how could I securely and "correctly" (never worked with entropy before) add more entropy to the kernel? This could also help other beginners to entropy and could be added to the wiki. Thanks!

Best Regards

[smuellerDD]

Am Samstag, 30. Juli 2022, 12:40:01 CEST schrieb Krish-sysadmin:

Hi Krish,

Ah @smuellerDD . Thank you I understand. So I'm using Fedora and would love to test this project and add more entropy to the kernel. I set random.trust_cpu=off. Now how could I securely and "correctly" (never worked with entropy before) add more entropy to the kernel? This could also help other beginners to entropy and could be added to the wiki. Thanks!

Sorry for the delay, vacation time :-)

Using the jitterentropy-rngd, simply start it with the provided systemd invocation. A lot of Linux distros have this rngd in their package list, so simply install it and do systemctl start jitterentropy followed by systemctl enable jitterentropy should do the trick.

Best Regards

Ciao Stephan

[krishjainx]

Thanks. Ah, so https://packages.debian.org/unstable/jitterentropy-rngd is derived from this repo?

[krishjainx]

And then in Fedora according to https://src.fedoraproject.org/rpms/jitterentropy-rngd/blob/rawhide/f/dead.package I instead do dnf install -y rng-tools && systemctl enable --now rngd since it says "Functionality merged into rng-tools, including a Provides: for this package name"?

[smuellerDD]

Am Samstag, 13. August 2022, 06:16:42 CEST schrieb Krish-sysadmin:

Hi Krish,

Thanks. Ah, so https://packages.debian.org/unstable/jitterentropy-rngd is derived from this repo?

Yes.

Ciao Stephan

[smuellerDD]

Am Samstag, 13. August 2022, 06:18:07 CEST schrieb Krish-sysadmin:

Hi Krish,

And then in Fedora according to https://src.fedoraproject.org/rpms/jitterentropy-rngd/blob/rawhide/f/dead.p ackage I instead do dnf install -y rng-tools && systemctl enable --now rngd since it says "Functionality merged into rng-tools, including a Provides: for this package name"?

Yes, rngd now contains the same functionality as jitterentropy-rngd. So you can also use the rngd instead to obtain the same results.

Ciao Stephan

[SanjeetKaranSingh]

Hi @smuellerDD, I have latest rng-tools installed, should I still install jitterentropy-rngd to improve entropy collection ?

[smuellerDD]

Am Samstag, 10. Dezember 2022, 02:52:22 CET schrieb Sanjeet Singh:

Hi Sanjeet,

Hi @smuellerDD, I have latest rng-tools installed, should I still install jitterentropy-rngd to improve entropy collection ?

I do not think this is necessary as the rngd now also uses the Jitter RNG library.

Ciao Stephan

[nisbet-hubbard]

@smuellerDD, could you please comment on whether changes leading to no good way to insert entropy into kernel by rngd https://github.com/nhorman/rng-tools/issues/195#issuecomment-1520598021 affects jitterentropy-rngd in the same way?

[smuellerDD]

Am Dienstag, 13. Juni 2023, 05:51:14 CEST schrieb nisbet-hubbard:

Hi nisbet,

@smuellerDD, could you please comment on whether changes leading to no good way to insert entropy into kernel by rngd https://github.com/nhorman/rng-tools/issues/195#issuecomment-1520598021 affects jitterentropy-rngd in the same way?

Yes, /dev/random as implemented currently is the way it is and all user space entropy-providers are affected the same way.

Thus, the Jitter RNG unconditionally inserts entropy after 10 minutes irrespective whether the kernel requests that or not.

The change in the size of the pool to 256 bits (Blake2S hash state) does not matter to the jitterentropy-rngd, because /dev/random can receive more data if user space supplies more. And there are various reason why supplying more is (sometimes) helpful.

Ciao Stephan

[nisbet-hubbard]

Many thanks for clarifying, Stephan!