#941300 finish-install: write additional random seed to location for systemd systemd-random-seed.service #941300
- Package:
- finish-install
- Source:
- finish-install
- Submitter:
- Paul Wise
- Date:
- 2024-09-13 11:00:01 UTC
- Severity:
- important
- Tags:
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.
[...] 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.
Wouldn't it just be easier to write it one location and replace the other with a symlink to it?
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
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.
Perhaps. I'm not sure systemd upstream would be convinced though.
Sent using Zoho Mail
Sent using Zoho Mail