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

[Torvald Riegel <triegel at redhat dot com>]

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?).

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