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

[Zack Weinberg <zackw at panix dot com>]

On Tue, Oct 4, 2016 at 12:05 PM, Torvald Riegel <triegel@redhat.com> wrote:
>
> From a birds-eye view, I think it would have been better if users would
> explicitly enable cancellation points, instead of vice versa (see the
> default of enabled+deferred you mention).  Like we do for timeouts, for
> example.
> However, POSIX doesn't specify that.  I'd prefer if we would not add
> more of that in the form of more cancellation points by default, but I
> also can't argue that what you prefer would be inconsistent with POSIX.
>
> Given that, and that a majority seems to share your opinion, I guess we
> have consensus.

I'll take getrandom that's a cancellation point over no getrandom at
all, but I think there are very strong reasons why getrandom,
specifically, should *not* be a cancellation point, whether or not it
can block.

Fundamentally the problem I have with it is that getrandom must always
succeed; applications cannot realistically be expected to recover from
failure.  In fact, under sufficiently nasty adversarial conditions it
might not be acceptable for getrandom to *crash* -- look up the
concept of a "bomb oracle".  The deviations from ideal behavior that
already exist (might block, might return fewer bytes than requested)
may already render it unfit for purpose!  Adding cancellation into the
mix is just another headache and a reason for people to either not use
getrandom at all, or continue manually open-coding the syscall.

zw