Re: Waiting for Randot

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Sun, 17 Jan 2021 10:43:41 +0200
> From: Andreas Gustafsson <gson%gson.org@localhost>
> 
> For the Nth time: if the problem is solved at the system integration
> level, there will be no blocking and therefore no need for your
> proposed change.

But conversely, if the problem is solved at the system integration
level, there will be no need for blocking and therefore no harm from
the proposed change.

So what I would like to hear is how causing applications to silently
hang indefinitely helps to solve the problem.

The experience I've seen over a year where the unblocking criterion
is, for the first time, actually meaningful -- and not just `eh, a few
keystrokes or network packets oughta be ``random enough'', right?' --
is that applications silently hanging indefinitely confuses people,
leads them to think NetBSD is broken, and/or gets them frustrated at
the stupid paternalistic entropy system.  (`Why don't you just put
``dd if=/dev/urandom of=/dev/random bs=32 count=1'' in the man page,
or do it in rc to fix the issue automatically?')

> I for one did feel trapped by this, but it's easily fixed.  I also
> think the UI is too complicated and intimidating in general and
> needs to be simplified.  But I still think sysinst is the best place
> to do this, and certainly more user friendly than being dropped into
> single user mode on boot.

You and I may be perfectly happy with understanding and addressing the
technical details at installation time, but I'm not willing to impose
the same burden on everyone around me.

There's a tension between several things here:

1. Minimizing burden on users -- which means avoiding asking deeply
   technical questions they may not be competent to answer like `what
   is a string you just picked uniformly at random from 2^256
   possibilities?', especially when captive while running sysinst
   where there's little opportunity to explore and read man pages at
   leisure.

2. Working on a large variety of hardware -- which includes hardware
   that does not have a HWRNG.

3. Guaranteeing security or failing closed -- which means suddenly
   ceasing to work for deeply technical reasons.

We can't satisfy all three at the same time.  You would like to do (2)
and (3); someone whose machines all have HWRNGs might only care for
(1) and (3); others who are just trying to get things done on private
networks will pick (1) and (2).

So I'm trying to simultaneously do a few things to improve the
situation for everyone:

- improve silent out-of-the-box entropy on as many systems as possible
  (more HWRNG drivers; hardclock samples as makeshift ring oscillator;
  also considering spinlock contention as another one)

- give users unobtrusive feedback about their own security (concise
  warnings on console, daily security report, maybe motd) so they are
  alerted to the problem with a reference to further reading about how
  to address it

- provide the option for security-critical systems to fail closed at
  boot with a clear indication of why (entropy=check/wait in rc.conf)

- potentially log the keys that may need to be regenerated to assist
  the operator in fixing the problem in case of, e.g., installation by
  writing a live image only accessible via ssh

and

- keep the people who aren't security nerds happy enough that they
  aren't tempted to go around creating workarounds that make things
  worse just to get done what they were trying to do (like suppress
  _all_ feedback with the dd hack)

But it's becoming less and less clear to me what value there is to
making applications hang indefinitely in this system -- not just as an
isolated matter of a single component failing closed, but how it helps
the whole system.