You are not logged in.
I can't remember with which kernel release it started to happen but I'd guess it was about a year ago when my Arch boot times increased significantly (by about an extra 40/50 seconds or so). This was caused by a kernel random number generator change which can be worked around by installing and enabling haveged. I thought I may only have to do that for a few weeks but now, almost a year later Linux 5.0 has been released and this is still an issue - I still have to install haveged or suffer 4x/5x longer boot times.
Has anyone heard of a better fix in the works for this issue that won't rely on external (to the kernel) packages such as haveged? Is there not a kernel option we can change or a patch we could apply to the default arch kernel's config/source to avoid people having to discover and hopefully fix this issue for themselves? I want to create my own Arch install video but I'd rather not have to cover this as its ugly and a bit embarrassing for the world's most popular kernel and I can't believe this is still an issue personally. Has it not annoyed enough people (esp. kernel devs) yet?
Last edited by danboid (2019-03-11 22:03:56)
Offline
An in kernel option is indeed available since the 4.19 series. If your cpu supports it (lscpu | grep rdrand returns something) you can add
random.trust_cpu=on
so that the kernel trusts the RNG of your cpu.
As for "a better fix". The fix that lead to this is a security change which could lead to untrusted random data being used during early boot. The kernel devs in advocacy do prefer slower boot up to that security risk and/or applications start to use a specific linux API that will give out best effort entropy without blocking. So I'm unsure as to whether there are "more active" efforts (though there recently was a change to gather entropy from hard disk activity, granted you still have a hard disk of course)
Offline
lscpu | grep -i rdrand
random.trust_cpu=on
https://bbs.archlinux.org/viewtopic.php?id=241501
There is no "fix" for this - the change *is* the fix of a CVE and generating entropy out of nothing but thin air is not possible (except w/ the help of a wifi antenna and a lot of radio ;-)
edit: blast.
Last edited by seth (2019-03-11 22:46:05)
Offline
An in kernel option is indeed available since the 4.19 series. If your cpu supports it (lscpu | grep rdrand returns something) you can add
random.trust_cpu=on
so that the kernel trusts the RNG of your cpu.
As for "a better fix". The fix that lead to this is a security change which could lead to untrusted random data being used during early boot. The kernel devs in advocacy do prefer slower boot up to that security risk and/or applications start to use a specific linux API that will give out best effort entropy without blocking. So I'm unsure as to whether there are "more active" efforts (though there recently was a change to gather entropy from hard disk activity, granted you still have a hard disk of course)
Not quite the news I wanted but thanks for explaining the state of this V1del!
Offline