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

[Zack Weinberg <zackw@panix.com>]

On Mon, Nov 21, 2016 at 11:57 AM, Torvald Riegel <triegel@redhat.com> wrote:
> On Fri, 2016-11-18 at 13:50 -0500, Zack Weinberg wrote:
>> I don't want to derail this into a general debate over adding new
>> cancellation points, and I especially don't want to hold up work on a
>> user-space CSPRNG on something unrelated, because arc4random() is the
>> top item on _my_ todo list after explicit_bzero().  So here is a
>> counterproposal.  Most of my concerns about getrandom() being a
>> cancellation point go away if it is only a cancellation point when it
>> is actually going to block
>
> Is there a way for the caller to ensure that a subsequent call to
> getrandom is not going to block?  If there isn't, then the caller has to
> conservatively assume that the call may be a cancellation point.

The whole reason I can live with my proposal is that most code should
be able to assume getrandom *never* blocks.  Specifically, if
getrandom ever blocks once we're past a fairly early stage of boot-up,
that's a bug in either the kernel or the setup procedure.  (I'd *like*
to get to where the kernel wouldn't even start process 1 until it
could guarantee that the RNG would not block, but that's a long way
off.)  So the only code that has to worry about it is early-stage boot
code that has to be written hyper-defensively anyway.

zw