Saving random seed on restart/shutdown, and restoring it during system boot
Why do that at all, in the first place. Do we need to "preserve" the random seed between restarts ? What would happen if we don't? Will the computer have 0 randomness when it boots?
This turns out to be a much deeper question than you might realize. I'll try to do justice to it without writing a textbook.
Basically: computers suck at randomness; when you have some true randomness (aka entropy), it's a good idea to hold on to it.
Let's assume that your computer doesn't have a hardware random number generator. (Modern Intel chips have the rdrand instruction that taps into a hardware rng, but for political reasons, the Linux kernel doesn't use it.)
On boot, where does the kernel get pure randomness from? According to Wikipedia:
The Linux kernel generates entropy from keyboard timings, mouse movements, and IDE timings and makes the random character data available to other operating system processes through the special files /dev/random and /dev/urandom. This capability was introduced in Linux version 1.3.30.
So mouse, keyboard, and timing of harddrive IO events. Let's say you need entropy during OS boot (for example you start sshd which needs to generate keys on its first startup), you haven't loaded the mouse and keyboard drivers yet, and that early in the boot cycle you won't have made very many disk IO calls -- hell, early enough in the boot the kernel is still running in a RAM FS, and even after that you may be on an SSD or flash drive that has very predictable IO times.
So back to your question:
What would happen if we don't? Will the computer have 0 randomness when it boots?
It's possible.
On small embedded linux devices like routers that boot out of flash memory (both the small home ones, and the big datacentre ones that power the internet), this is actually a serious problem.
For an awesome read on this topic, see the 2012 paper Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices which has the shocking finding that
0.75% of TLS certificates [on the internet] share keys due to insufficient entropy during key generation.
Just a few lines below the Short-Description you quoted, /etc/init.d/urandom notes some assumptions about the secrecy:
## Assumption 1: We assume [/var/lib/urandom/random-seed] is a file (or a symlink
## to a file) that resides on a non-volatile medium that persists
## across reboots.
## Case 1a: Ideally, it is readable and writeable. Its is unshared,
## i.e. its contents are unique to this machine. It is protected so
## that its contents are not known to attackers.
## Case 1b: Less than ideally, it is read-only. Its contents are
## unique to this machine and not known to attackers.
Later in that file, where the seed is written to disk, there is a comment:
# see documentation in linux/drivers/char/random.c
which is worth reading but includes:
* When any operating system starts up, it will go through a sequence
* of actions that are fairly predictable by an adversary, especially
* if the start-up does not involve interaction with a human operator.
* This reduces the actual number of bits of unpredictability in the
* entropy pool below the value in entropy_count. In order to
* counteract this effect, it helps to carry information in the
* entropy pool across shut-downs and start-ups.
... Even with
* complete knowledge of the start-up activities, predicting the state
* of the entropy pool requires knowledge of the previous history of
* the system.
Saving entropy between reboots is an imperfect solution to boot-time entropy shortages. Why imperfect? First, because saved entropy is discoverable, if potential attacker could get a hold of that saved seed they could also compromise all random number generators seeded with it. Second, because when system is restored from backups or multiple VM instances spawned with the same saved seed they would all reuse the same saved entropy.
Still, such disasters are still preferable to having no boot-time entropy available to your system.
Keep in mind, if you configure to save entropy your solution will not be certifiable, as FIPS and pretty much any other crypto and infosec related standard prohibits this practice.