Summary: | =sys-kernel/gentoo-sources-{4.14.52,4.16.18,4.17.6}: x11-misc/sddm hangs until kernel outputs "random: crng init done" | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Till Schäfer <till2.schaefer> |
Component: | Current packages | Assignee: | LxQt maintainers <lxqt> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | emilien.mottet, gentoo, ilmostro7, jstein, kde, kernel, limanski, mmk, poncho, realnc, skobkin-ru, soprwa |
Priority: | Normal | Keywords: | PullRequest |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://github.com/gentoo/gentoo/pull/18935 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | journald.log of affected boot |
Description
Till Schäfer
2018-07-09 16:57:08 UTC
Also affects gdm on systemd.. the issue exists across distributions and probably due to a kernel change as specified here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572 My currentl work around has been to install sys-apps/rng-tools[jitterentropy] right now which has brought down the boot time from up to 5 minutes to 13s This seems to have been backported upstream, so it's likely to affect >=kernel-4.8 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43838a23a05fbd13e47d750d3dfd77001536dd33 I had similar situation with my machine, and as it comes out, this was not a kernel bug. I suppose that something has changed with crng initialization because of CVE-2018-1108. You should install sys-apps/rng-tools, set it up accordingly to your needs/hardware in "/etc/conf.d/rngd" and add it to the boot level: "rc-update add rngd boot". Boot delay should be mitigated. I have just spotted that you are using systemd so: "systemctl enable rngd.service" I had the same problem on stable sys-kernel/gentoo-sources-4.14.52 and stable x11-misc/sddm-0.17.0-r4. IMHO this means that rngd should become a dependency of sddm. Same here. SDDM doesn't start X until this point: [ 13.177997] r8169 0000:06:00.0 eth0: link up [ 13.178017] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 56.959275] random: crng init done [ 56.959278] random: 6 urandom warning(s) missed due to ratelimiting and then I have to press random keys on the keyboard for X to start. Not sure why Jonas assigned this to the kernel. This patch is in kernels >=4.17.0 and 4.16 is now EOL. Assigning to sddm maintainers for their thoughts about the dependency and keeping kernel project on CC in case we need to do something here. Picking on KDE team, since the user appears to be using the DM. (In reply to Mike Pagano from comment #7) > Not sure why Jonas assigned this to the kernel. This patch is in kernels > >=4.17.0 and 4.16 is now EOL. I'm on 4.14, which exhibits the same problem, and it's obviously not EOL. The problem persists for 4.17.6. There is some broader discussion going on regarding this topic: https://www.phoronix.com/scan.php?page=news_item&px=Linux-Protect-User-Entropy There are plans to introduce kernel config option to enable hardware CPU's randr and include it to entropy pool which will mitigate the boot delay. https://lkml.org/lkml/2018/7/17/1279 (In reply to PrSo from comment #11) > There are plans to introduce kernel config option to enable hardware CPU's > randr and include it to entropy pool which will mitigate the boot delay. > > https://lkml.org/lkml/2018/7/17/1279 Only if the CPU supports it. Not all do. Second that, but there could be an alternative besides rng-tools (for those that have such CPU) Same here. Workaround for me: emerger haveged and enable it. Linux kernel >=4.19.0 has a new option, with this enabled, the issue is fixed on my systemd box.
RANDOM_TRUST_CPU - Trust the CPU manufacturer to initialize Linux's CRNG
> Assume that CPU manufacturer (e.g., Intel or AMD for RDSEED or
> RDRAND, IBM for the S390 and Power PC architectures) is trustworthy
> for the purposes of initializing Linux's CRNG. Since this is not
> something that can be independently audited, this amounts to trusting
> that CPU manufacturer (perhaps with the insistence or mandate
> of a Nation State's intelligence or law enforcement agencies)
> has not installed a hidden back door to compromise the CPU's
> random number generation facilities. This can also be configured
> at boot with "random.trust_cpu=on/off".
Alternative userspace solutions mentioned in this bug:
sys-apps/haveged
sys-apps/rng-tools
Maybe this in-kernel option also works, in case people have the hardware:
CONFIG_HW_RANDOM
It seems that, since this bug was reported for more DMs than sddm, it would not be enough for those informations to be only disclosed via sddm ebuild. Thusly reassigning to systemd proj for coordination.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fd3d4e174e04d50697e9761bdf2e14be2476fd0a commit fd3d4e174e04d50697e9761bdf2e14be2476fd0a Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2022-03-31 20:46:57 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2022-04-01 14:47:10 +0000 x11-misc/sddm: Add pkg_postinst info for fixing entropy Closes: https://bugs.gentoo.org/660812 Package-Manager: Portage-3.0.30, Repoman-3.0.3 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> x11-misc/sddm/sddm-0.18.1-r6.ebuild | 6 ++++++ 1 file changed, 6 insertions(+) |