Bug 1888695
| Summary: | [rhel-8.4] Do not install rng-tools by default | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Simo Sorce <ssorce> |
| Component: | releng | Assignee: | EXD SP RHEL Compose team <exd-sp-rhel-compose> |
| releng sub component: | RHELCMP | QA Contact: | Release Test Team <release-test-team-automation> |
| Status: | CLOSED CURRENTRELEASE | Docs Contact: | |
| Severity: | unspecified | ||
| Priority: | unspecified | CC: | bkhomuts, core-kernel-mgr, herbert.xu, jklech, jwboyer, libhe, linl, lisas, luzhang, pzatko, redhat.bugzilla, simon.matter, skozina, vdronov, xiliang, yduan |
| Version: | 8.3 | Keywords: | Triaged |
| Target Milestone: | rc | ||
| Target Release: | 8.4 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: |
A new way to gather randomness and fill the entropy pool very early at the boot time was introduced in the kernel of the RHEL-8.3. This means there is generally enough entropy in all cases and rngd daemon is not needed to run in a userspace any more.
Starting with the RHEL-8.3 the rng-tools package which contains the rngd daemon is not installed by default. Still the rng-tools package could be explicitly installed in cases when a certain hardware random number generator should fill the general kernel entropy pool (available to a userspace via /dev/random file).
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-05-24 09:08:16 UTC | Type: | Enhancement |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Simo Sorce
2020-10-15 14:12:45 UTC
The simplest and a proper way to do that is systemctl presets. As of now they enable rngd both in Fedora and RHEL8: # grep -ri rng /usr/lib/systemd/system-preset/ /usr/lib/systemd/user-preset/ /usr/lib/systemd/system-preset/90-default.preset:enable rngd.service We need to change "enable" to "disable" or remove this line. Probably we need to create the same bz for Fedora. The 2 similar bzs (bz1578833 and bz1215645) have "redhat-release{,-sever}" component, I believe this one should go there too. fedora/rawhide's copy of the same: https://bugzilla.redhat.com/show_bug.cgi?id=1888823 > With the introduction of jitter-rng in the kernel as of 8.3
being:
upstream: 50ee7529ec45 random: try to actively add entropy rather than passively wait for it
rhel-8.3: edc3002c84e7 [char] random: try to actively add entropy rather than passively wait for it
fedora solved it in bz1888823#c3 by not installing rng-tools by default and not touching presets: https://pagure.io/fedora-workstation/issue/184 https://pagure.io/fedora-comps/pull-request/533 probably, RHEL can do the same (AFAIK, RHEL uses comps.xml too). I like the fedora solution, not installing the rng-tools by default but keeping the presets and I agree witch comment 4 from rhbz#1888823 > Agreed, if people wish to install it I think it's useful to be enabled by default if there's an available HW RNG. Switching component to releng as a proposal. Sounds good to me. Thanks Petr! I'm not sure it was a smart decision to not install rng-tools by default on servers. This is what I brought to the CentOS mailing list: ... On a new test install of EL9 I saw this message in the logs: Mar 01 08:09:18 <hostname> pcp-pmie[2870]: Low random number entropy available 15.6%... This is on a 64 core "AMD Opteron(tm) Processor 6282 SE" server but I also got the same low entropy on an EL9 KVM guest running on a "AMD EPYC 7601" server. After a lot of searching the net I understand that rng has been reworked in 5.x kernels and /proc/sys/kernel/random/entropy_avail reaches only 256 in default configurations. But why does it go too low on a test system with almost not load? Is this an issue with AMD CPUs or does it also happen on other systems? ... I'm afraid many users may not realize that their random number entropy goes low and therefore may experience low performance but don't find it out. At least for server installs rng-tools should be installed in case the hardware requires it IMHO. I'm not talking about laptops here but for servers, my test boxes are from HPE and Gigabyte, it really hurts to end up with a system running low on entropy. Thanks, Simon (In reply to Simo Sorce from comment #0) > With the introduction of jitter-rng in the kernel as of 8.3 we generally > have enough entropy in all cases and do not need rngd to run in userspace > anymore. Unfortunately this is not the case and it appears to be causing problems: https://bugzilla.redhat.com/show_bug.cgi?id=2176255 The RHEL8 kernel only collects CPU jitter during the boot initialisation stage, it does not use CPU jitter at all once the kernel RNG has finished initialisation. So on a system that is otherwise starved of entropy, the RHEL8 kernel will soon block on /dev/random when left on its own. This is quite different from the RHEL9 kernel behaviour where /dev/random has been completely replaced with /dev/urandom. Thanks, Herbert, With that, we should think about adding rng-tools installed by default back in RHEL8. There were problems in FIPS mode mentioned in bz1884857, but they were resolved. Also, bz2154804 has disabled rng-tools in FIPS mode. Any reason why we should not feed jitter-rng into /dev/random after boot on the RHEL-8 kernel ? To add to Simon Matter’s comment about the need for rng-tools in a virtual machine context – rngd may also fail to initialise the Jitter source (a fix is to extend the timeout: https://access.redhat.com/solutions/6984027), or it could happen that neither hwrng nor rdrand is available. In either case, one can instead opt for jitterentropy-rngd, either as an RPM through the copr repo (and forthcoming in EPEL8) or compiled directly from source. |