On Mon, Jun 25, 2018 at 06:46:12PM +0100, Ken Moffat wrote:
> On Sun, Jun 24, 2018 at 09:36:52PM +0100, Ken Moffat wrote:
>
> >
> > So I'm guessing that keying Ctrl-C one or more times, and possibly
> > <enter>, generates enough entropy.
[...]
>
> Tried that on my haswell, where I had needed to use Ctrl-C, Ctrl-C,
> <enter> to (I originally thought) stop whatever was hanging. No
> change, but just keying Ctrl-C three times was good enough - and I
> now guess that hitting any key(s) three tiem will do.
>
Nope, Ctrl-C (possibly by sending a signal) generates more entropy
than a plain keypress, I had to thump a few keys to continue.
Like redhat bug 1572916 - in that case, gcrypt was making a blocking
call. That also says an early 4.18 kernel (during the merge window)
seems to have fixed it. Maybe 4.18-rc2 will be good enough and not
bring any new regressions (slim chance of the latter).
A reddit post re sddm suggests using init-tools to feed output from
the hardware RNG into the kernel. But posts by the kernel random
maintainer show he is worried that hardware RNGs have been
backdoored to be predictable.
Looks as if the root cause is fixing CVE-2018-1108. I wonder how
*late* we could successfully start unbound ?
Looking at other links, one of the sources of entropy is rotational
hard disks. My modern desktops don't have any of those.
<sigh/>
--
Keyboard not found, Press F1 to continue
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
