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

[Florian Weimer]

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.

> This is not about whether
> it's possible for users to do (they could build their own syscall
> wrappers after all too, right? ;) ) but about clean interfaces.

It's not possible to opt in to cancellation at system calls using only 
public glibc interfaces.  The best you can do is to implement 
cancellation from scratch, using a different signal.

> With your proposal, one could argue that, for example, every library has
> to be aware of cancellation and how it works if one of the clients of
> the library could want to use cancellation;

But that is true for most libraries today, no matter what we do about 
getrandom.  getrandom just does not add significant additional exposure 
in this area.

> the library either has to
> disable it explicitly, or it has to document which additional
> cancellation points exist and has to implement the cleanup handlers.
> This is error-prone and adds complexity to those use cases.  Therefore,
> it seems better to avoid that potential source of bugs and either make
> the default to not support cancellation (ie, an opt-in for the
> cancellation facility), or make at least make the choice explicit for
> users of getrandom (ie, two functions or an additional parameter).

I'm increasingly worried that this discussion is actually about thread 
cancellation in general and only peripherally about getrandom. 
Considering the fringe nature of getrandom (it is intended for the 
implementation of PRNG seeding, after all), it seems to be a strange 
choice to attempt to settle this debate.

Does POSIX even say that cancellation has to be enabled for new threads 
by default, like we do?  It's probably too late to change this.

In the end, this is very similar to the ongoing debate about exception 
handling in C++ and other languages.  For most such languages, there are 
large code bases which ban exceptions for various reasons, and others 
which use them with success.  I don't think we can reach agreement which 
one application developers should prefer.  The only thing we can do is 
try to be as consistent as possible (and for getrandom, I think the 
model should be the read function, and not rand).

This discussion is also blocking further work on my part for additional 
randomness generation functions.  More user-oriented interfaces we could 
add, such as getentropy or arc4random, should *not* be cancellation 
points, I think.

Thanks,
Florian