Arch Linux

danboid

Member

Registered: 2009-11-12

Posts: 16

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)

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 21,657

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)

seth

Member

Registered: 2012-09-03

Posts: 51,017

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)

---

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

danboid

Member

Registered: 2009-11-12

Posts: 16

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)

Not quite the news I wanted but thanks for explaining the state of this  V1del!