Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1743333

Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

Cross-posted to 2 groups.

Show key headers only | View raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1 Sebastian Andrzej Siewior <sebastian@breakpoint.cc> - 2018-10-30 01:30 +0100
  Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1 "Theodore Y. Ts'o" <tytso@mit.edu> - 2018-10-30 15:20 +0100
    Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1 Kurt Roeckx <kurt@roeckx.be> - 2018-10-30 19:40 +0100
      Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1 "Theodore Y. Ts'o" <tytso@mit.edu> - 2018-10-30 22:00 +0100
        Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1 Sebastian Andrzej Siewior <sebastian@breakpoint.cc> - 2018-10-31 13:00 +0100
          Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1 "Theodore Y. Ts'o" <tytso@mit.edu> - 2018-10-31 23:50 +0100
            Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1 Sebastian Andrzej Siewior <sebastian@breakpoint.cc> - 2018-11-01 23:30 +0100
              Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1 "Theodore Y. Ts'o" <tytso@mit.edu> - 2018-11-02 01:00 +0100
                Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1 Kurt Roeckx <kurt@roeckx.be> - 2018-11-02 01:30 +0100
                Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1 "Theodore Y. Ts'o" <tytso@mit.edu> - 2018-11-02 03:20 +0100
                Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1 Sebastian Andrzej Siewior <sebastian@breakpoint.cc> - 2018-11-04 01:30 +0100

csiph-web