RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1976877 - Please enable CONFIG_RANDOM_TRUST_CPU
Summary: Please enable CONFIG_RANDOM_TRUST_CPU
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: kernel
Version: 9.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: beta
: ---
Assignee: Vladis Dronov
QA Contact: Chunyu Hu
URL:
Whiteboard:
Depends On:
Blocks: 1988161
TreeView+ depends on / blocked
 
Reported: 2021-06-28 12:51 UTC by Thomas Huth
Modified: 2021-12-02 23:19 UTC (History)
14 users (show)

Fixed In Version: kernel-5.14.0-0.rc4.35.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1830280
Environment:
Last Closed: 2021-12-02 23:18:58 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Gitlab cki-project kernel-ark merge_requests 1287 0 None None None 2021-08-02 13:43:12 UTC

Description Thomas Huth 2021-06-28 12:51:50 UTC 
+++ This bug was initially created as a clone of Bug #1830280 +++

Split out from discussions in this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1778762#c23

The high level here is "synchronize with the current state of Fedora" for how entropy (/dev/random) works.  The two bigger recent changes in Linux are the builtin kernel jitter entropy (covered by the above bug) as well as CONFIG_RANDOM_TRUST_CPU (this bug).

Modern AWS instance types have hardware with RDRAND, but there's still no hypervisor entropy (unlike GCP which offers virtio-rng).

Booting a m5d.4xlarge instance for example, firstboot has:

[   19.887867] random: crng init done

That's quite slow; now obviously there are projects like rng-tools that try to address this but the problem is that particularly for CoreOS, we do a whole lot inside the initial ramdisk, so any userspace solution like rng-tools basically needs to be nearly the first process started - we want to support things like dm-crypt for the root filesystem.  

And not to mention a lot of parts of the kernel want entropy even before userspace is launched.

Whereas instead if I do:

# rpm-ostree kargs --append=random.trust_cpu=on
# systemctl reboot

I see the same thing we have with FCOS:

[    0.001000] random: crng done (trusting CPU's manufacturer)

i.e. basically immediately after kernel boot we aren't going to block on strong entropy.

Now, we *could* enable this kernel argument just for RHCOS but I'd want to  see an argument for why we don't have it enabled by default across the board (like Fedora has).
Comment 1 Thomas Huth 2021-06-28 12:54:44 UTC 
Looks like the CONFIG_RANDOM_TRUST_CPU settings got lost in the RHEL9 kernel, but are set in the RHEL8 and Fedora kernels, thus we might want to enable this in RHEL9 kernels again:

$ grep -r CONFIG_RANDOM_TRUST_CPU redhat/
redhat/configs/common/generic/CONFIG_RANDOM_TRUST_CPU:# CONFIG_RANDOM_TRUST_CPU is not set
redhat/configs/fedora/generic/powerpc/CONFIG_RANDOM_TRUST_CPU:CONFIG_RANDOM_TRUST_CPU=y
redhat/configs/fedora/generic/s390x/CONFIG_RANDOM_TRUST_CPU:CONFIG_RANDOM_TRUST_CPU=y
redhat/configs/fedora/generic/x86/CONFIG_RANDOM_TRUST_CPU:CONFIG_RANDOM_TRUST_CPU=y
Comment 3 Vladis Dronov 2021-07-30 12:59:05 UTC 
RHEL-8 configs are:

config-4.18.0-326.el8.ppc64le:CONFIG_RANDOM_TRUST_CPU=y
config-4.18.0-326.el8.s390x:CONFIG_RANDOM_TRUST_CPU=y
config-4.18.0-326.el8.x86_64:CONFIG_RANDOM_TRUST_CPU=y

make the same for the RHEL9.
Comment 4 Vladis Dronov 2021-07-30 13:21:52 UTC 
(In reply to Thomas Huth from comment #1)
> Looks like the CONFIG_RANDOM_TRUST_CPU settings got lost in the RHEL9
> kernel,

Hello, Thomas,
If you have permissions needed, could you please ACK this merge request?

https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1287
Comment 5 Colin Walters 2021-07-30 14:08:30 UTC 
Added this to the OpenShift tracker; I would probably vote for this one as a blocker for 9 final.
Comment 6 Vladis Dronov 2021-08-02 13:43:13 UTC 
the ARK MR was merged: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1287

the change is under kernel-5.14.0-0.rc4.36 tag, so it will appear in C9S and RHEL9
kernels of this version and later ones.
Comment 11 Vladis Dronov 2021-08-11 13:42:10 UTC 
the change has actually appeared in the 5.14.0-0.rc4.35.el9 version
of C9S and RHEL9 kernels, this bz is ready for tests:

c9s: kernel-core-5.14.0-0.rc4.35.el9.x86_64.rpm
$ grep TRUST_CPU lib/modules/5.14.0-0.rc4.35.el9.x86_64/config 
CONFIG_RANDOM_TRUST_CPU=y

rhel9: kernel-core-5.14.0-0.rc4.35.el9.x86_64.rpm
$ grep -e TRUST_CPU -e RHEL lib/modules/5.14.0-0.rc4.35.el9.x86_64/config
CONFIG_RANDOM_TRUST_CPU=y
CONFIG_RHEL_DIFFERENCES=y
Note You need to log in before you can comment on or make changes to this bug.