Messages in this thread | | | Date | Tue, 30 Oct 2018 10:15:44 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1 |
| |
On Tue, Oct 30, 2018 at 01:18:08AM +0100, Sebastian Andrzej Siewior wrote: > Using ioctl(/dev/urandom, RNDADDENTROPY, ) instead writting to > /dev/urandom would do the trick. Or using RNDADDTOENTCNT to increment > the entropy count after it was written. Those two are documented in > random(4). Or RNDRESEEDCRNG could be used to force crng to be reseeded. > It does also the job, too. > > Ted, is there any best practise what to do with the seed which as > extrected from /dev/urandom on system shutdown? Using RNDADDTOENTCNT to > speed up init or just write to back to urandom and issue RNDRESEEDCRNG?
The reason why writing to /dev/[u]random via something like:
cat /var/lib/random/seed > /dev/random
Dosn't bump the the entropy counter is because it's possible that an attacker could read /var/lib/random/seed. Even if the seed file is refreshed on shutdown, (a) the attacker could have read the file while the system is down, or (b) the system could have crashed so the seed file was not refreshed and the attacker could have read the file before the crash.
If you are using a VM, if the host has virtio-rng, using a kernel that has virtio-rng support will solve the problem. For qemu, this means you can enable via something like this:
-object rng-random,filename=/dev/urandom,id=rng0 \ -device virtio-rng-pci,rng=rng0
If you are using Google Compute Engine, I can't comment about future product features, but I would encourage you to file a feature request bug with Google requesting virtio-rng support ASAP.
On any VM (cloud or on-prem), since you have to trust the host *anyway*, with v4.19, you can add random.trust_cpu=on to the boot command-line, or build the kernel with CONFIG_RANDOM_TRUST_CPU.
For the Debian 4.18 kernel, this can be backported via commits 39a8883a2b98 and 9b25436662d5.
- Ted
| |