Re: lib/56905: getentropy() may return predictable data

[Andreas Gustafsson <gson%gson.org@localhost>]

The following reply was made to PR lib/56905; it has been noted by GNATS.

From: Andreas Gustafsson <gson%gson.org@localhost>
To: Robert Elz <kre%munnari.OZ.AU@localhost>
Cc: Christos Zoulas <christos%zoulas.com@localhost>,
    gnats-bugs%netbsd.org@localhost
Subject: Re: lib/56905: getentropy() may return predictable data
Date: Thu, 30 Jun 2022 15:24:41 +0300

 Robert Elz wrote:
 > It is also deliberately intended to not block, that was the whole
 > point I think.
 
 The getentropy() call originated in OpenBSD, where the question of
 blocking doesn't apply because OpenBSD claims to always have
 sufficient entropy available.  On systems that do not make that claim,
 such as NetBSD or Linux, it must have the option of blocking (or
 failing) to guarantee unpredictability, and on Linux, it can block.
 
 The text in https://www.opengroup.org/austin/docs/austin_1110.pdf does
 not require non-blocking, but it does require unpredictability.
 
 > As I understand it, the idea is that if you care about security,
 > you make sure sufficient entropy is available when the system boots,
 > and there isn't an issue with it the way it is now.
 
 This idea of the user having to "care" and "make sure" does not seem
 compatible with NetBSD's long-standing tradition of being secure by
 default.
 
 > If you don't care (that much) about security then you might not do
 > that, but you also are very unlikely to care that the initial entropy
 > might not be as unpredictable as security conscious people might demand.
 > 
 > But what no-one wants, is processes hanging forever because they're waiting
 > on entropy arriving, from somewhere unknown, which no-one cares (or perhaps
 > knows) enough about to create.   That's what all the complaints have been
 > about.   Note "forever" in the hanging - when there's no initial entropy,
 > and nothing providing any, the loop you're proposing adding never terminates.
 
 Yes, this is a real problem, but it is not specific to getentropy(),
 and it should really have its own PR.  We need to address the root
 cause of entropy not being available, or being available but not being
 counted as such, not sweep the problem under the rug one API at a
 time.
 
 One way to fix it would be to go back to recognizing interrupt timing
 entropy sources as contributing a nonzero amount of entropy, as most
 operating systems do, including NetBSD 9.  While I sympathize in
 principle with the notion that we should only count entropy from
 "certifiable" sources, if that results in us having to disable
 blocking, we have ended up worse off than we were in NetBSD 9, not
 better.  Blocking until we have met at least _some_ criterion for
 sufficient entropy, even one lacking theoretical rigor, is always
 better than not blocking at all.
 
 > The plan, which probably has not yet been implemented (as it isn't an ABI
 > altering change, and so isn't urgent before the branch) is to have rc.d
 > scripts which check (if requested) if entropy is there or not, and if not,
 > delay/abort the system startup until some is provided.   If you care about
 > security, you'll have that turned on, just in case the entropy source isn't
 > available, and needs fixing.   If you don't, you won't, and won't care.
 
 The "if requested" part does not sound like it's secure by default.
 And until or unless the plan is implemented, -current remains vulnerable.
 -- 
 Andreas Gustafsson, gson%gson.org@localhost