This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v3] getrandom system call wrapper [BZ #17252]
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:
> >>> 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.
I do mean the other side. That is, in all the code that may see a
> > 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.
OK, though that's much like open(), which is a cancellation point, so
making the syscall a cancellation point too would make sense.
The pseudo-RNG functions are not cancellation points.
> > 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).
Can you elaborate on your reasoning?
> 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
Interesting, thanks. That might be one interpretation of the situation
(ie, that users know that they don't have to worry about cancellation
requests concurrent or pending while getting a random number).
However, it might also mean that what I worry about is actually
realistic (ie, that user code should be cancellation-aware but isn't).