Bug 1830280
| Summary: | Please enable CONFIG_RANDOM_TRUST_CPU | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Colin Walters <walters> | |
| Component: | kernel | Assignee: | Chris von Recklinghausen <crecklin> | |
| kernel sub component: | Kernel-Core | QA Contact: | Chunyu Hu <chuhu> | |
| Status: | CLOSED ERRATA | Docs Contact: | ||
| Severity: | unspecified | |||
| Priority: | unspecified | CC: | crecklin, ddelcian, dhoward, herbert.xu, liwan, mharri, miabbott, syangsao, toneata | |
| Version: | 8.3 | Keywords: | ZStream | |
| Target Milestone: | rc | |||
| Target Release: | 8.0 | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | kernel-4.18.0-201.el8 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1928027 1976877 (view as bug list) | Environment: | ||
| Last Closed: | 2020-11-04 01:16:48 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1807069, 1928027 | |||
|
Description
Colin Walters
2020-05-01 13:05:48 UTC
The random device is not part of the kernel Crypto API. 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. 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 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. 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:/ # 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 > 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. Patch(es) available on kernel-4.18.0-201.el8 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 |