From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74926 invoked by alias); 29 Nov 2016 08:24:25 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 74909 invoked by uid 89); 29 Nov 2016 08:24:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=permit, userspace, Hx-languages-length:1698, blocked X-HELO: mx1.redhat.com Subject: Re: [PATCH v7] getrandom system call wrapper [BZ #17252] To: Zack Weinberg , Szabolcs Nagy References: <3dd5d3b8-c196-98fb-1671-90cd90ab90c7@redhat.com> <244f578c-889a-a4cf-c686-bb2a5e49cca1@panix.com> <2d175242-1a82-9410-d01e-682ab4d9081e@panix.com> <0cca2fc9-14d2-9fa2-5a6e-fe00af31acd6@redhat.com> <4928b864-9691-021d-fcf9-b3ef9bd10f63@panix.com> <5193b776-03a5-3841-6980-b67c56a99c2a@redhat.com> <582ED78F.3050400@arm.com> Cc: nd , GNU C Library From: Florian Weimer Message-ID: <913b45c2-b4ca-c96a-a14a-5fed1cbf9c49@redhat.com> Date: Tue, 29 Nov 2016 08:24:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg01049.txt.bz2 On 11/18/2016 07:50 PM, 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 -- note that I very much do _not_ mean > "when it is called with arguments that permit it to block." How about > we have the public getrandom do like this: > > ssize_t getrandom (void *buffer, size_t length, unsigned int flags) > { > ssize_t rv = __getrandom_nocancel (buffer, length, flags | GRND_NONBLOCK); > if (rv == length) > return rv; > if (rv < 0 && ((flags & GRND_NONBLOCK) || errno != EAGAIN) > return rv; > rv = max(rv, 0); > return __getrandom_maycancel (buffer + rv, length - rv, flags); > } This is an intriguing idea, but it actually makes reasoning about cancellation more difficult, particularly with GRND_RANDOM. I haven't seen a rationale for the POSIX design (in which cancellation points always check for cancellation, even if they don't block). I suspect it goes something like this: If thread cancellation happens on only blocking, then whether cancellation occurs depends on a race: the cancellation has to occur while being blocked. This might never happen. It's hard to tell whether you actually can cancel threads doing this (when cancellation is desired), or that they do not get canceled accidentally. Thanks, Florian