Buttonless Failsafe Mode

[CFSworks]

You are familiar with the functional difference between /dev/random and /dev/urandom, right?

EDIT: I guess not! Well, they behave the same, right up until the kernel's entropy pool runs dry. Then, /dev/urandom keeps on going with the stale entropy (which is often good enough for many uses), while /dev/random will block until there are at least enough bits to return from the read() call. This means that the kernel guarantees that every bit read from the latter interface is backed by at least 1 bit worth of unused entropy. So it may take a while, you may have to flood-ping your device to generate a bunch of interrupts, the preinit environment may have to run an entropy daemon of its own, but that nonce will be high-entropy.

[slh]

@CFSworks

Then, /dev/urandom keeps on going with the stale entropy (which is often good enough for many uses), while /dev/random will block until there are at least enough bits to return from the read() call.

That was true, but no longer - /dev/random is no longer blocking either.

[dlakelan]

@CFSworks

functional difference between /dev/random and /dev/urandom, right?

They've been changed, /dev/random will only ever block once, after it's got enough entropy it never blocks again. But this is a good point because on a router it's entirely possible for this blockage to be several seconds initially and it will extend the boot time on every boot.

A couple mitigation strategies... Ping ff02::1 about 5 times, that could be a useful entropy source. According to the mitigation strategies put into the kernel it shouldn't be more than a couple seconds before the kernel is initialized with entropy anyway (I recently read a bunch of lkml mailing list stuff on this topic).