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/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.


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