This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v3] getrandom system call wrapper [BZ #17252]
On 09/23/2016 11:44 AM, Torvald Riegel wrote:
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
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 don't think anyone has seen this yet because they use /dev/urandom,
which does not block when the pool is initialized. The request we got
for getrandom was specifically to enable blocking until pool initialization.
Delayed initialization of the pool does happen. For example, I'm
currently logged into an aarch64 system (whose root file system is on an
SSD) which initialized the pool 37 seconds after starting the kernel, at
which point many userland processes had already been started.
(I'm not sure if it matters for the cancellation point discussion
whether the blocking is truly indefinite, or just impracticably long.)
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
Time itself is not necessarily used as a randomness source in the kernel.