Re: [PATCH v3] getrandom system call wrapper [BZ #17252]

[Torvald Riegel <triegel at redhat dot com>]

On Mon, 2016-09-12 at 09:25 +0200, Florian Weimer wrote:
> On 09/09/2016 05:23 PM, Torvald Riegel wrote:
> > On Fri, 2016-09-09 at 16:28 +0200, Florian Weimer wrote:
> >> On 09/09/2016 04:21 PM, Torvald Riegel wrote:
> >>> On Thu, 2016-09-08 at 13:44 +0200, Florian Weimer wrote:
> >>>> I have made the system call wrapper a cancellation point.  (If we
> >>>> implement the simpler getentropy interface, it would not be a
> >>>> cancellation point.)
> >>>
> >>> Why did you do that?
> >>
> >> I have to, because it can block indefinitely.
> >
> > That doesn't mean you have to make the default function a cancellation
> > point.  There are many POSIX functions which can block indefinitely and
> > which are not required to be cancellation points (eg, rwlocks only *may*
> > be cancellation points).
> >
> > Can the system call really block indefinitely, or only for a long time
> > and (ie, will return eventually)?
> 
> Yes, if the system enters a deadlock condition where the waiting for 
> randomness prevents it from accumulating additional randomness.

Is it known that this can happen under certain situations, or is it just
unproven that this cannot happen?
I would guess that it cannot happen, because at some point, waiting
probably needs polling or can be implemented with polling.  Is there a
concern that polling and the timing differences that arise when doing so
do not feature enough randomness to be able to eventually provide enough
random data?