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

Torvald Riegel triegel@redhat.com
Fri Sep 23 09:44:00 GMT 2016


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?



More information about the Libc-alpha mailing list