This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v7] getrandom system call wrapper [BZ #17252]
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