You are not logged in.

#1 2019-03-11 21:58:08

danboid
Member
Registered: 2009-11-12
Posts: 13

Any fix in sight for the rng / boot issue?

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

#2 2019-03-11 22:41:43

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 7,796

Re: Any fix in sight for the rng / boot issue?

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

#3 2019-03-11 22:45:24

seth
Member
Registered: 2012-09-03
Posts: 12,929

Re: Any fix in sight for the rng / boot issue?

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

#4 2019-03-12 01:28:45

danboid
Member
Registered: 2009-11-12
Posts: 13

Re: Any fix in sight for the rng / boot issue?

V1del wrote:

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

Board footer

Powered by FluxBB