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

[Florian Weimer <fweimer at redhat dot com>]

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.

Thanks,
Florian