VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Tomas Mraz]

On Fri, 2019-06-07 at 18:03 +1000, Dr Paul Dale wrote:
> Mark, I agree that the project area would be better for this
> discussion.
> 
> For those not involved, this revolves around the vote to merge
> PR#9084 and possible alternate mitigations for the underlying
> problem.
> 
> 
> Tim’s explanatory message is:
> 
> > For the record, I think we need to do a better job of tackling the
> > underlying issue.
> > Dealing with systems on first boot with no entropy is an issue for
> > a class of systems.
> > However we should be distinguishing between contexts where we have
> > decent seeding material (from having had reasonable entropy) from
> > those where we haven't.
> > We also should be able to persist seeding across boots and have
> > recommendations for how vendors should do that.
> > We should be able to fall back to handling it at the user level
> > (i.e. non-root user, persisted in the file system).
> > We need knowledge of install state (for FIPS) and that can also act
> > as a first-boot state effectively.
> > 
> > And this applies equally to getentropy usage - it is only a problem
> > in very limited contexts where blocking actually makes sense to
> > perform.
> > That the kernel has no additional entropy available is not
> > necessarily an issue - except in a very limited context (first time
> > boot with no other entropy available from previous contexts). 

The previous context can easily provide false entropy - for example due
to the booting system being a cloned virtual machine. Or boot image for
a small router device which contains such saved entropy which is
distributed to millions of devices worldwide.

This was the reason why systemd guys rejected the idea to actually seed
the kernel rng with such entropy with the call that counts this seed
entropy. They just use it as additional seed with no accounting for the
entropy it would provide if it was not reused.

> 
> Viktor replied:
> 
> > I just want to make sure we don't lock ourselves in to a single
> > potentially clumsy solution in the library.  Various strategies
> > may be appropriate depending on the platform, and ultimately the
> > cooperation of the system administrator to enable the required
> > mechanisms.
> > 
> > Potential additional sources for initial entropy on systems
> > without getrandom(2) might include:
> > 
> >   RDSEED/RDRAND
> >   TPM (or Virtualized TPM which is sometimes better!)
> >   RNG state saved across reboots.
> >   ...
> > 
> > This requires knowledge of various platforms, and potential
> > help from the platform vendors.  It might, for example, make
> > sense to delegate initial seeding to systemd on platforms
> > that use systemd, and work with the systemd maintainers to
> > provide a set of sensible entropy sources for initial boot.
> > 
> > Exposing a decent RNG to virtual guests and containers is
> > would be another area of focus.

>From the point of view of distribution maintainer of OpenSSL I would
say what we had in 1.1.1 before the introduction of DEVRANDOM_WAIT had
no real problems for us.

However I can understand that when OpenSSL is built and installed
separately by application vendors on some legacy system that they do
not have control of they might appreciate that the library itself tries
to solve the hard problems related to the entropy gathering for them.

So I would just ask for one thing - all this additional stuff should be
optional - I do not of course care wheter it is opt-in or opt-out as
that is easily handled in our builds.

> 
> My suggestion as a fallback would be Stephan Müller’s CPU Jitter.
>  He’s collected a large corpus of data from many processors and the
> scheme works relatively quickly.

+1 to that.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]