From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70040 invoked by alias); 21 Nov 2016 17:30:59 -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 69118 invoked by uid 89); 21 Nov 2016 17:30:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1807, concerns X-HELO: mx1.redhat.com Message-ID: <1479749452.7146.1273.camel@localhost.localdomain> Subject: Re: [PATCH v7] getrandom system call wrapper [BZ #17252] From: Torvald Riegel To: Zack Weinberg Cc: Szabolcs Nagy , Florian Weimer , nd , GNU C Library Date: Mon, 21 Nov 2016 17:30:00 -0000 In-Reply-To: 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> <1479747467.7146.1263.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00736.txt.bz2 On Mon, 2016-11-21 at 12:12 -0500, Zack Weinberg wrote: > On Mon, Nov 21, 2016 at 11:57 AM, Torvald Riegel 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. Does the kernel guarantee this, meaning that it's specifically documented as part of the interface? Or similarly, does it give a guarantee under some precondition (which systemd or similar guarantees to establish)? I understand why you think this would be useful behavior, but the "should be able" part in your statement is too vague for us to rely on. Also, what do you mean specifically by "block"? If it is just taking a relatively long time, but will always eventually finish irrespective of whether other processes do or do not do something, then I wouldn't classify the behavior as blocking.