#941300 finish-install: write additional random seed to location for systemd systemd-random-seed.service

#941300#5
Date:
2019-09-28 09:20:47 UTC
From:
To:
finish-install creates a random seed in the location used by the
urandom init script from the initscripts package. On systemd based
systems, systemd-random-seed.service overrides the urandom init script
but uses a different location for its random seed file. Consequently on
first boot of systemd based systems there is no random seed file so the
amount of entropy available is lower.

/var/lib/urandom/random-seed
/var/lib/systemd/random-seed

I think finish-install needs to fix this with one of these options:

   1. Write the random seed to both locations. This means that when
      switching init systems you get the old random seed.
   2. Write two different random seeds to the two locations. This means
      that when switching init systems you get the a new random seed that
      has never been used before, but which was generated during the
      install.
   3. Detect the chosen init system and write the random seed to the
      location preferred by that init system. This means that when
      switching init systems the first boot of the new init systems has no
      random seed.

I think probably the second scenario is the best since then there is
always a random seed available even when switching init systems and
that random seed is never reused.

I think this issue should get fixed in stable/oldstable too.

#941300#18
Date:
2019-09-28 13:32:49 UTC
From:
To:
[...]

This should improve the randomness of /dev/urandom.  However, the last
time I checked, the systemd service does not change the kernel's
entropy accounting.  (And there was a small risk of using the seed
twice, which would need to be fixed before changing that.)  So this
does not help with the problem of slow boots due to the kernel not
accounting enough entropy.

Ben.

#941300#23
Date:
2019-10-01 10:55:22 UTC
From:
To:
Wouldn't it just be easier to write it one location and replace the
other with a symlink to it?

#941300#28
Date:
2019-10-02 00:59:25 UTC
From:
To:
Looks like neither the urandom init script nor systemd-random-seed
unlink the file before writing to it, so this could potentially work
unless that changes at some point. Just writing two different seeds
avoids the need to care about what the implementations will do in the
future so I think it is safer.

Looking at systemd's documentation, on non-virtual systems d-i should
probably also write to the random seed stored in the UEFI ESP, in case
the user decides to use systemd-boot instead of initramfs-tools.

https://systemd.io/RANDOM_SEEDS.html

#941300#33
Date:
2019-10-02 09:59:12 UTC
From:
To:
The original report says:

If it's going to override/shadow (as opposed to simply working
alongside/in parallel) urandom, probably it ought to also be looking
at/consuming the urandom seed?

Ian.

#941300#38
Date:
2019-10-02 12:05:08 UTC
From:
To:
Perhaps. I'm not sure systemd upstream would be convinced though.
#941300#43
Date:
2024-09-13 09:57:41 UTC
From:
To:
Sent using Zoho Mail
#941300#48
Date:
2024-09-13 10:57:26 UTC
From:
To:
Sent using Zoho Mail