From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75319 invoked by alias); 21 Nov 2016 17:12:36 -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 75239 invoked by uid 89); 21 Nov 2016 17:12:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=RNG, concerns X-HELO: mailbackend.panix.com X-Gm-Message-State: AKaTC03lIYDRE8RBXw3WYC4vIR96rXOykGWrHIL/q204XCs9sScJWQsvyuZCGVSiJgiZpn4FIbrnV0cV/kFNCg== X-Received: by 10.28.142.16 with SMTP id q16mr15667003wmd.35.1479748349655; Mon, 21 Nov 2016 09:12:29 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1479747467.7146.1263.camel@localhost.localdomain> 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> From: Zack Weinberg Date: Mon, 21 Nov 2016 17:12:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v7] getrandom system call wrapper [BZ #17252] To: Torvald Riegel Cc: Szabolcs Nagy , Florian Weimer , nd , GNU C Library Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-11/txt/msg00733.txt.bz2 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. (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