This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
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 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
random data?

Time itself is not necessarily used as a randomness source in the kernel.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]