New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is jitterentropy-rngd
daemon and/or jitterentropy_rng.k
kernel module still useful in modern kernels?
#27
Comments
Am Sonntag, 3. Juli 2022, 13:43:53 CEST schrieb Patrick Schleizer:
Hi Patrick,
Due to
QubesOS/qubes-issues#4169 (comment)
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](https://www.chronox.de/lrng.html) 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`](https://packages.debian.org/sid/linux-image-amd64).
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
|
@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 ! |
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
|
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 |
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
|
Thanks. Ah, so https://packages.debian.org/unstable/jitterentropy-rngd is derived from this repo? |
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"? |
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
|
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
|
Hi @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
|
@smuellerDD, could you please comment on whether changes leading to no good way to insert entropy into kernel by rngd nhorman/rng-tools#195 (comment) affects jitterentropy-rngd in the same way? |
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
nhorman/rng-tools#195 (comment)
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
|
Many thanks for clarifying, Stephan! |
Due to QubesOS/qubes-issues#4169 (comment) I was hoping I could ask something very specific.
Is
jitterentropy-rngd
daemon still useful recent kernel versions? Would you recommend security-focused operating systems to install thejitterentropy-rngd
package by default?Is
jitterentropy_rng.ko
kernel module still useful with recent kernel versions? Would you recommend security-focused operating systems to built thejitterentropy_rng.ko
statically in the kernel?Do you have other suggestions of steps that security-focused operating systems could realistically take to improve kernel entropy quality, security?
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
.The text was updated successfully, but these errors were encountered: