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 1830280 - Please enable CONFIG_RANDOM_TRUST_CPU
Summary: Please enable CONFIG_RANDOM_TRUST_CPU
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: kernel
Version: 8.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Chris von Recklinghausen
QA Contact: Chunyu Hu
URL:
Whiteboard:
Depends On:
Blocks: 1807069 1928027
TreeView+ depends on / blocked
 
Reported: 2020-05-01 13:05 UTC by Colin Walters
Modified: 2024-06-13 22:36 UTC (History)
9 users (show)

Fixed In Version: kernel-4.18.0-201.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1928027 1976877 (view as bug list)
Environment:
Last Closed: 2020-11-04 01:16:48 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Colin Walters 2020-05-01 13:05:48 UTC 
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 Herbert Xu 2020-05-01 23:55:25 UTC 
The random device is not part of the kernel Crypto API.
Comment 2 Colin Walters 2020-05-04 17:21:29 UTC 
There's no reason for this bug to be private (did something in Bugzilla change to default to private?), and I needed to duplicate some public bugs against related bugs.
Comment 3 Colin Walters 2020-05-12 13:02:27 UTC 
I'd hoped to at least get a "yeah seems sane" or "no we'll never do that because $reasons" here.

For now: https://gitlab.cee.redhat.com/coreos/redhat-coreos/merge_requests/937
Comment 4 Chris von Recklinghausen 2020-05-12 13:28:12 UTC 
I don't know of any reason to not to. Fedora doesn't enable it for aarch64. I'll put out a change with it enabled just like kernel-ark does and see if there are any objections from reviewers.

I'm currently preempted by some high priority work, so it may be a week or so before I'm able to see if there are any objections to enabling it.
Comment 5 Colin Walters 2020-05-12 14:25:18 UTC 
For what it's worth I checked Debian stable:

# dpkg -l linux*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                Version           Architecture Description
+++-===================================-=================-============-==================================
ii  linux-base                          4.6               all          Linux image base package
un  linux-doc-4.19                      <none>            <none>       (no description available)
ii  linux-image-4.19.0-6-amd64          4.19.67-2+deb10u2 amd64        Linux 4.19 for 64-bit PCs (signed)
un  linux-image-4.19.0-6-amd64-unsigned <none>            <none>       (no description available)
un  linux-initramfs-tool                <none>            <none>       (no description available)
un  linux-show-player                   <none>            <none>       (no description available)
# grep RANDOM_TRUST_CPU /boot/config-4.19.0-6-amd64 
CONFIG_RANDOM_TRUST_CPU=y
#

OpenSUSE leap apparently doesn't:

# rpm -qa|grep kernel
kernel-vanilla-base-4.12.14-lp151.28.48.1.x86_64
# grep RANDOM_TRUST /boot/config-4.12.14-lp151.28.48-vanilla 
# 

But tumbleweed does:

$ podman run --rm -ti docker.io/opensuse/tumbleweed
...
0900b096880b:/ # grep CONFIG_RANDOM_TRUST /boot/config-5.6.11-1-vanilla 
CONFIG_RANDOM_TRUST_CPU=y
CONFIG_RANDOM_TRUST_BOOTLOADER=y
0900b096880b:/ #
Comment 7 Chris von Recklinghausen 2020-05-14 18:17:15 UTC 
Patches have been posted for review. FYI we only enable it for x86_64, ppc64le and s390x. aarch64 does not have it enabled. This is identical to how Fedora configures it.

FYI Fedora does not enable CONFIG_RANDOM_TRUST_BOOTLOADER
Comment 8 Colin Walters 2020-05-14 18:55:41 UTC 
> Patches have been posted for review.

Thank you very much!

> FYI we only enable it for x86_64, ppc64le and s390x. aarch64 does not have it enabled. This is identical to how Fedora configures it.

That seems OK I guess, though we will probably want to chase down whether aarch64 actually needs it or not at some point.

> FYI Fedora does not enable CONFIG_RANDOM_TRUST_BOOTLOADER

I saw that one and briefly looked into it - it seems like that comes into play mostly for architectures that don't have hardware entropy - the people deploying these systems want to basically have /var/lib/systemd/random-seed handled by the bootloader, which makes total sense.  I was talking with Lennart about this once and he pointed out that OpenBSD has done it this way for a while.  But in the Linux world we have a much more...variety...in userspace and bootloaders.
He ended up implementing support for this in systemd/sd-boot: https://github.com/systemd/systemd/pull/13137/

But I don't think anyone looked at it for other bootloaders like grub.

I don't think it's important to enable right now, but (architecture astronauting here) eventually a good flow would be:

Firstboot: use hardware entropy up to early userspace
  Gather entropy from outside the CPU (e.g. we can talk to network services like https://blog.cloudflare.com/league-of-entropy/ or whatever)
  Save that strong entropy in the bootloader config

Subsequent boots: Don't trust the CPU entropy if we have bootloader entropy

But anyways, not critical right now.
Comment 10 Frantisek Hrbata 2020-05-19 12:25:45 UTC 
Patch(es) available on kernel-4.18.0-201.el8
Comment 19 errata-xmlrpc 2020-11-04 01:16:48 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: kernel security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:4431
Note You need to log in before you can comment on or make changes to this bug.