[PATCH v3] getrandom system call wrapper [BZ #17252]
Florian Weimer
fweimer@redhat.com
Mon Sep 12 07:26:00 GMT 2016
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
More information about the Libc-alpha
mailing list