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

[Florian Weimer]

On 11/29/2016 04:23 PM, Torvald Riegel wrote:
> On Tue, 2016-11-29 at 15:40 +0100, Florian Weimer wrote:
>> On 11/29/2016 02:56 PM, Torvald Riegel wrote:
>>> On Tue, 2016-11-29 at 09:16 +0100, Florian Weimer wrote:
>>>> On 11/18/2016 05:04 PM, Torvald Riegel wrote:
>>>>> On Fri, 2016-11-18 at 16:13 +0100, Florian Weimer wrote:
>>>>>> On 11/18/2016 03:21 PM, Torvald Riegel wrote:
>>>>>>
>>>>>>> As discussed in the thread, there are different opinions about what the
>>>>>>> default should be.  There are reasonable arguments for both options.  In
>>>>>>> such a case, it seems better to make the choice explicit, simply from an
>>>>>>> ease-of-use and interface design perspective.
>>>>>>
>>>>>> Unfortunately, this is not the approach that POSIX has chosen.  But
>>>>>> there is precedent for doing our own thing in this area: the "c" flag
>>>>>> for fopen.  We cannot use the existing flags argument in getrandom for
>>>>>> this purpose because its layout is controlled by the kernel.
>>>>>
>>>>> It seems a separate argument would be better than using up space in the
>>>>> existing flags.  Cancellation is something we add, so we should add to
>>>>> the underlying interface too, instead of messing with it.
>>>>
>>>> Is this separate argument your personal preference, or are you just
>>>> trying to find common ground and reconcile different positions?
>>>
>>> It's my personal preference.  Which is partially motivated by trying to
>>> find common ground between the different use cases (and not finding
>>> obvious common group, so therefore make the choice explicit).
>>
>> Hmph.
>
> Note that I mean that this is my preference specifically in the scenario
> of adding some sort of flag to getrandom() and offering only
> getrandom().
>
>> I was about to propose a new patch, with two functions:
>>
>> getrandom, as I posted it the last time (an unadorned system call which
>> is also a cancellation point).
>>
>> getentropy, a thin wrapper which avoids returning EINTR (to match
>> OpenBSD and Solaris) and is not a cancellation point.  It would return
>> EIO on short reads, too.
>>
>> The documentation would have said that getrandom is a lower-level
>> function for those which need GRND_RANDOM or cancellation, and everyone
>> else should call getrandom.
>
> I guess one of these should be getentropy (the latter?).

Yes, developers should prefer getentropy or a PRNG seeded from getentropy.

>> Would this work for you?
>
> Yeah, I guess so.  I can't really estimate how obvious it would be for
> users to have to consider the pair of these (and thus make a conscious
> choice and understand what cancellation means) -- but if we can make
> this fairly obvious (eg, through proper documentation) and thus are
> likely to prevent users from making a mistake, and we have an
> alternative for the non-cancellation use case, then I guess this could
> be a meaningful solution.

Great.

Zack, what do you think?

Thanks,
Florian