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

[Florian Weimer <fweimer at redhat dot com>]

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.

> > > Can't we just let cancellation rot in its corner?
> >
> > No, we have many customers who use it (and this despite the fact that
> > the current implementation has a critical race condition).
>
> Usage of it doesn't mean that it has to be the default.

It's not used by default.  Something has to call pthread_cancel.

> Have we made
> other syscall wrappers cancellation points in the past (ie, syscalls
> that don't already have a matching POSIX function that is specified to
> be a cancellation point too)?

I found open_by_handle.

> I'm worried about people who just want to use the syscall but don't know
> that much about POSIX cancellation.  They couldn't use the syscall
> safely in a library without also being aware of POSIX cancellation, and
> I'm concerned that they might just forget to disable cancellation around
> the syscall, thus creating resource leaks, deadlocks (eg, cancellation
> handler doesn't release locks), etc.  If this is primarily a Linux API
> currently (ignoring the Solaris case for a while), then marrying it to
> POSIX seems wrong.

If we add getentropy, I suggest that it will not be a cancellation point 
(even if it can still block indefinitely).

I looked at quite a few getrandom emulations using /dev/urandom, and not 
one of them was cancellation-aware (it leaked the file descriptor on 
cancellation, for example).  Based on that, I really doubt getrandom 
would introduce an unexpected cancellation point that causes actual 
problems.

Florian