Re: regarding the changes to kernel entropy gathering

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Sun, Apr 04, 2021 at 11:47:10PM +0700, Robert Elz wrote:
> If not, what prevents someone from reading (copying) the file from the
> system while it is stopped (assessing the storage device via other methods)
> and then knowing exactly what the seed is going to be when the system boots?

That is discussed in the security model Taylor presented a long time
ago. In short: nothing. In most use cases, you are screwed at this point
anyway since various other cryptographic material like the host ssh key
is also lost. There is one special case here where this has to be taken
under consideration and that is cloning virtual machines. The short
answer is that you as system integrator are responsible for handling it
in an appropiate manner. Ensuring that the VM sees enough entropic
action before the entropy is accessed would ensure that. The seed file
doesn't replace the entropy pool, so any entropy that actually did get
added during the boot process still remains.

> I think I'd prefer possibly insecure, but difficult to obtain from outside
> like disk drive interrupt timing low order bits than that.   Regardless of
> how unproven that method might be.

See above, that's still the case. Noone said anything about not using
sources of potential entropy. All that changed is that we don't pretend
it provides entropy. As I mentioned elsewhere, a lot of the classic
entropy sources are surprisingly bad nowadays when someone can observe
the kernel, especially in a virtualized environment.

Joerg