[PATCH v7] getrandom system call wrapper [BZ #17252]

[Florian Weimer]

On 11/17/2016 02:56 PM, Zack Weinberg wrote:
> On 11/17/2016 08:50 AM, Florian Weimer wrote:
>> On 11/17/2016 02:45 PM, Zack Weinberg wrote:
>>> On 11/17/2016 08:02 AM, Florian Weimer wrote:
>>>> On 11/16/2016 05:41 PM, Zack Weinberg wrote:
>>>>> On Wed, Nov 16, 2016 at 10:52 AM, Florian Weimer <fweimer@redhat.com>
>>>>> wrote:
>>>>>> On 11/16/2016 04:20 PM, Zack Weinberg wrote:
>>>>>>> I am seriously considering escalating my disagreement here to a
>>>>>>> formal objection.  I would like to know why you think it is
>>>>>>> NECESSARY - not merely convenient or consistent with other stuff -
>>>>>>> for this function to be a cancellation point.
>>>>>>
>>>>>> It's necessary if you ever want to cancel a hanging getrandom in a
>>>>>> context where you cannot install a signal handler (so that you can
>>>>>> trigger EINTR when getrandom is stuck).
>>>>>
>>>>> That only pushes the question back a level.  When would it ever be
>>>>> necessary to do that?  Be as concrete as you possibly can.  Actual
>>>>> code from a real program, if possible.
>>>>
>>>> It's not clear to me what you are asking here.
>>>>
>>>> Do you mean cancellation in general, or cancellation in conjunction with
>>>> getrandom specifically?
>>>
>>> Sorry.  I meant cancellation specifically of a thread hanging in
>>> getrandom.
>>
>> I'm not sure how I can provide that, considering that there is currently
>> no way to cancel a thread which hangs in getrandom because we do not
>> provide a way for applications to implement system calls as cancellation
>> points (unless we provide a wrapper for the specific system call, of
>> course).
>
> What I'm asking for is evidence that that is actually a problem for at
> least one real application.

I found this:

<https://opensource.apple.com/source/ppp/ppp-412.3/Helpers/vpnd/ipsecoptions.c>

ipsec_resolver_thread reads from /dev/random, which can block for a very 
long time.  The thread for it is spawned in ipsec_process_prefs, which 
cancels it when got_terminate returns true.  The intent seems to be that 
is terminated on graceful process termination: read in 
ipsec_process_prefs returns EINTR after a signal handler has run which 
makes got_terminate (defined in main.c in the parent directory) return true.

If the read from /dev/random is replaced with a call to getrandom which 
is not a cancellation point, this would like not work as intended.

Is this the kind of stuff you are looking for?

 > Also evidence that making getrandom a
> cancellation point _won't_ break programs that naively assume it can
> never fail.

Cancellation does not add additional error return cases.

Thanks,
Florian