Re: fix for no ssh

[Greg Wooledge <wooledg@eeg.ccf.org>]

On Wed, Jul 10, 2019 at 11:46:33AM +0000, Andy Smith wrote:
> In the release notes in the relevant section (5.1.4) the last
> paragraph is:
> 
>     See the wiki (https://wiki.debian.org/BoottimeEntropyStarvation)
>     and DLange's overview of the issue
>     (https://daniel-lange.com/archives/152-hello-buster.html) for
>     other options.
> 
> Both those pages have a list of different solutions and both mention
> that this RDRAND thing is enabled. Neither of them say how to
> disable it but they do say:
> 
>     for amd64: use a recent kernel with CONFIG_RANDOM_TRUST_CPU set
>     (less recent kernels may need random.trust_cpu=on added to the
>     commandline)
> 
> which kind of makes it obvious to me that to disable it you would do
> "random.trust_cpu=off". If you don't find this obvious maybe the
> wiki page could do with editing to improve that.
> 
> So what's lacking? Is it just that the release notes and linked
> pages mention that the user trusts the CPU but do not mention why
> some feel that is a bad idea?

The primary thing that's lacking is someone who actually knows all of
this stuff and can explain it properly.  Everyone on this mailing list is
grasping at straws that are lying around in various places, of different
types and quality and age, and trying to assemble a house out of them.

After that, it would be *wonderful* to have a well-written, comprehensive
summary of the situation, and all of the available options, and their
benefits and drawbacks, so users can choose the best one for their needs.

Bearing in mind, there are several kinds of user situations:

1) Users with a modern amd64 CPU, who do not care about this stuff as long
   as it seems to work.

2) Users with a modern amd64 CPU, who care deeply (or are paranoid, your
   call) about security, trust, government agency backdoors in corporate
   products, etc., but are not actually seeing delayed boots.

3) Users with virtual machines, who are actually seeing delayed boots.

4) Users with real machines, who are actually seeing delayed boots.

5) Users with CPUs that don't have RDRAND or an equivalent instruction,
   who may or may not be seeing delayed boots.

And I don't know what all of the possible solutions are, nor even how
many there are.  (That's the problem!  Nobody knows what the choices are.)