This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v7] getrandom system call wrapper [BZ #17252]
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).
Note that I mean that this is my preference specifically in the scenario
of adding some sort of flag to getrandom() and offering only
> 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.