From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112548 invoked by alias); 18 Nov 2016 18:50:35 -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 112535 invoked by uid 89); 18 Nov 2016 18:50:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=blocked, concerns X-HELO: mailbackend.panix.com X-Gm-Message-State: AKaTC03W26JuxtmRUrJgyxRskjZO4mp64+YTQdU6bFHmZP1x8kVpcQxcCDjIzlW1C7UpBysoNIqh6+BH7ztgow== X-Received: by 10.28.150.75 with SMTP id y72mr1414962wmd.47.1479495020486; Fri, 18 Nov 2016 10:50:20 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <582ED78F.3050400@arm.com> 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> From: Zack Weinberg Date: Fri, 18 Nov 2016 18:50:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v7] getrandom system call wrapper [BZ #17252] To: Szabolcs Nagy Cc: Florian Weimer , nd , GNU C Library Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-11/txt/msg00673.txt.bz2 On Fri, Nov 18, 2016 at 5:27 AM, Szabolcs Nagy wrote: > On 17/11/16 17:16, Zack Weinberg wrote: >> [This is just the general argument that adding new cancellation points >> to the C library can render existing code buggy without notice.] > > there is no existing code that uses glibc getrandom. > > a user can easily turn a cancellation point into > a non-cancellation one if desired, but the other > way is not possible. I specifically said there was a wrapper that anticipates the availability of glibc getrandom, and uses a direct syscall in the meantime. AC_REPLACE_FUNCS(getrandom) or dlsym("getrandom") or like that. > blocking syscalls have to be cancellation points > otherwise they cannot be called safely from a long > running process that has to remain responsive: > blocked threads can keep piling up and there is no > way to reuse the resources they hold. This is a valid point - I personally read it as an argument against adding any new blocking syscalls, but that's not the world we live in. 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); } I could live with that. zw