-
Notifications
You must be signed in to change notification settings - Fork 39
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
Don't try to improve Kernel randomness #77
Don't try to improve Kernel randomness #77
Conversation
According Kernel developer Jason A. Donenfeld it's not the job of userspace to care of randomness: "That script has *always* been wrong. Writing to /dev/urandom like that has *never* ensured that those bytes are taken into account immediately after. It's just not how that interface works. So any assumptions based on that are bogus, and that line effectively does nothing. Fortunately, however, the kernel itself incorporates hwrng output into the rng pool, so you don't need to think about doing it yourself. So go ahead and remove that line from your script." Link: https://lore.kernel.org/linux-crypto/20e3c73c-7736-b010-516a-6618c88d8dad@gmx.net/T/#mfd7cca35fe18d6039fbcb2201317a38456cb5b67
Whether writing to RPi OS ships with But to be true, while I know the practice to manually feed |
This line has always felt a bit cargo-culty and I trust Stefan's and other upstream developers' judgement on this. |
I suggest to at least test this once on a real RPi first boot, to see whether it now hangs on SSH hostkey generation. This would be the reason why the line was added in the first place. |
This is not true. Stop saying nonsense. If you see a bug in the code that would make your statement true, please send a patch to fix that, as I'd consider that an important bug to fix. |
And why do As said, I have not tested it since a while, but such a daemon became very necessary with the release of Debian Bullseye (or was it Buster?), more precisely the systemd version shipped with it. |
I think for most uses, those daemons are no longer useful for anything at all and can be safely uninstalled. For a long time, random.c development was stagnant, so userspace had to come up with all sorts of hacks to account for its shortcomings. These days, hwrng output is fed into random.c in the kernel, and it even does a haveged-like jitter thing in desperate scenarios. |
Quoting myself:
So you say that indeed something has changed, that is good to know. The released RPi kernel build is 6.1.21, which is sufficiently new for these changes? I'll do some tests. Would be actually nice to get rid of those userland services, both of them have/had bugs on certain Debian versions with certain architectures. |
That should be sufficiently new, yes. |
d9e79726193346569af7953369a638ee2275ade5 is when we started feeding the kernel entropy pool from hwrng devices without relying on user space |
- DietPi-Installer | Skip entropy daemon on all devices but those with old kernel, as recent Linux versions use hardware random generators on their own as well as use HAVEGE-like algorithm if required. Tested on various devices with Linux 6.x.y as well as Debian Bullseye VM with Linux 5.10.191: RPi-Distro/raspberrypi-sys-mods#77
According Kernel developer Jason A. Donenfeld it's not the job of userspace to care of randomness:
"That script has always been wrong. Writing to /dev/urandom like that has never ensured that those bytes are taken into account immediately after. It's just not how that interface works. So any assumptions based on that are bogus, and that line effectively does nothing.
Fortunately, however, the kernel itself incorporates hwrng output into the rng pool, so you don't need to think about doing it yourself.
So go ahead and remove that line from your script."
Link: https://lore.kernel.org/linux-crypto/20e3c73c-7736-b010-516a-6618c88d8dad@gmx.net/T/#mfd7cca35fe18d6039fbcb2201317a38456cb5b67