From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2676 invoked by alias); 12 Sep 2016 07:26:05 -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 2649 invoked by uid 89); 12 Sep 2016 07:26:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=leaked, customers X-HELO: mx1.redhat.com Subject: Re: [PATCH v3] getrandom system call wrapper [BZ #17252] To: Torvald Riegel References: <661db778-8110-82b2-2c41-d6195916cbea@redhat.com> <1473430905.30192.5.camel@localhost.localdomain> <1473434601.30192.13.camel@localhost.localdomain> Cc: GNU C Library From: Florian Weimer Message-ID: <771c9c53-44df-cfdb-1ad2-c7a249b7d6c5@redhat.com> Date: Mon, 12 Sep 2016 07:26:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1473434601.30192.13.camel@localhost.localdomain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-09/txt/msg00194.txt.bz2 On 09/09/2016 05:23 PM, Torvald Riegel wrote: > On Fri, 2016-09-09 at 16:28 +0200, Florian Weimer wrote: >> On 09/09/2016 04:21 PM, Torvald Riegel wrote: >>> On Thu, 2016-09-08 at 13:44 +0200, Florian Weimer wrote: >>>> I have made the system call wrapper a cancellation point. (If we >>>> implement the simpler getentropy interface, it would not be a >>>> cancellation point.) >>> >>> Why did you do that? >> >> I have to, because it can block indefinitely. > > That doesn't mean you have to make the default function a cancellation > point. There are many POSIX functions which can block indefinitely and > which are not required to be cancellation points (eg, rwlocks only *may* > be cancellation points). > > Can the system call really block indefinitely, or only for a long time > and (ie, will return eventually)? Yes, if the system enters a deadlock condition where the waiting for randomness prevents it from accumulating additional randomness. >>> Can't we just let cancellation rot in its corner? >> >> No, we have many customers who use it (and this despite the fact that >> the current implementation has a critical race condition). > > Usage of it doesn't mean that it has to be the default. It's not used by default. Something has to call pthread_cancel. > Have we made > other syscall wrappers cancellation points in the past (ie, syscalls > that don't already have a matching POSIX function that is specified to > be a cancellation point too)? I found open_by_handle. > I'm worried about people who just want to use the syscall but don't know > that much about POSIX cancellation. They couldn't use the syscall > safely in a library without also being aware of POSIX cancellation, and > I'm concerned that they might just forget to disable cancellation around > the syscall, thus creating resource leaks, deadlocks (eg, cancellation > handler doesn't release locks), etc. If this is primarily a Linux API > currently (ignoring the Solaris case for a while), then marrying it to > POSIX seems wrong. If we add getentropy, I suggest that it will not be a cancellation point (even if it can still block indefinitely). I looked at quite a few getrandom emulations using /dev/urandom, and not one of them was cancellation-aware (it leaked the file descriptor on cancellation, for example). Based on that, I really doubt getrandom would introduce an unexpected cancellation point that causes actual problems. Florian