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: gnats-bugs%netbsd.org@localhost
Cc: Robert Elz <kre%munnari.OZ.AU@localhost>
Subject: Re: lib/56905: getentropy() may return predictable data
Date: Fri, 22 Jul 2022 21:03:36 +0300

 Robert Elz wrote:
 >  getentropy() is being added to POSIX in the next version of the standard.
 >  
 >  The description doesn't explicitly say it is not allowed to block,
 >  but it does say (explicitly) that it is not a thread cancellation
 >  point.
 >  
 >  In general, everything which can block is either a cancellation point,
 >  or is allowed to be (the latter for things like putc() which might call
 >  a function which is a cancellation point, or might not).
 >  
 >  Not being a cancellation point tells me that getentropy() is not
 >  expected to block (ever).
 
 Yet in FreeBSD and Linux, it does block:
 
   https://www.freebsd.org/cgi/man.cgi?query=getentropy&sektion=3&format=html
   https://man7.org/linux/man-pages/man3/getentropy.3.html
 
 On operating systems where the kernel CSPRNG is not guaranteed to be
 seeded by the time a user process runs, such as FreeBSD, Linux, and
 NetBSD, getentropy() needs to block until it is seeded in order to
 meet the POSIX requirement of returning unpredictable data.  If POSIX
 has not anticipated this, that seems like a serious flaw in the
 standard.
 
 >  It is allowed to fail - but the description of its one possible relevant
 >  failure mode (it is also possible for it to return an error if the user
 >  passes invalid params - asks for too many bits, for example - that's not
 >  relevant here) is:
 >  
 >      [ENOSYS]  The system does not provide the necessary source of entropy.
 >  
 >  which seems to me to be more a permanent failure, that is, it isn't
 >  saying "no entropy is currently available", than one which can
 >  ever be rectified (eg: by pausing and trying later - similating blocking
 >  in the caller).
 
 I do agree that ENOSYS seems to be intended for more permanent
 failures.
 
 >  Blocking in getentropy() won't happen, "the proper semantics" are not that.
 
 And I won't be using an operating system where it doesn't block (or
 possibly fail) when the system knows it is lacking entropy, even if
 that means the end of my 27 years as a NetBSD user.  Since that is not
 a decision to be made lightly, I'm sure you understand that I'm not
 taking your word for this but asking core to make a formal decision
 one way the other.
 -- 
 Andreas Gustafsson, gson%gson.org@localhost