From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112184 invoked by alias); 17 Oct 2016 12:54:33 -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 112169 invoked by uid 89); 17 Oct 2016 12:54:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=picking, cancellation, accumulating, cited X-HELO: mx1.redhat.com Message-ID: <1476708857.14800.12.camel@localhost.localdomain> Subject: Re: [PATCH v3] getrandom system call wrapper [BZ #17252] From: Torvald Riegel To: Florian Weimer Cc: GNU C Library Date: Mon, 17 Oct 2016 12:54:00 -0000 In-Reply-To: <2997042e-a33a-afbb-79ae-2c04c015dff1@redhat.com> References: <661db778-8110-82b2-2c41-d6195916cbea@redhat.com> <1473430905.30192.5.camel@localhost.localdomain> <1473434601.30192.13.camel@localhost.localdomain> <771c9c53-44df-cfdb-1ad2-c7a249b7d6c5@redhat.com> <2997042e-a33a-afbb-79ae-2c04c015dff1@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00256.txt.bz2 On Wed, 2016-10-12 at 17:58 +0200, Florian Weimer wrote: > On 09/12/2016 09:25 AM, Florian Weimer wrote: > > 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. > > This is what happens here: > > > > systemd will eventually kill the blocked process and the boot continues, > but all network services will be missing. I don't see how cancellation would be the best solution for this problem. It could be considered *a* solution, but for it to work, the program (or python in this case) needs to (1) be aware of the blocking behavior, and potential absence of getrandom initialization (2) have a fallback plan for when getrandom() fails (3) run more than a single thread just to run the cancellation (4) synchronize between the thread that executes getrandom() and the cancelling thread so that pthread_cancel can cancel only the respective getrandom() call; for example, the getrandom thread could set/unset a flag in a critical section, and the cancelling thread needs to check the flag and cancel in a critical section protected by the same lock. All solutions have to be aware of (1). Maybe doing the fallback plan from (2) is the right solution. This is what they seem to have done in the BZ you cited. Having a getrandom call that can time out would be easier for programs to use than cancellation. It would still require picking the right timeout (ie, less than systemd's), but that's somethign the cancellation-based solution would have to do too. Cancellation would be more a more flexible means than a timeout if systemd would announce to the program that it will get killed in 5s or something like that, and then the program could try to hurry up and cancel the getrandom call. But that seems like a complex and rather rare use case, and thus wouldn't suggest to me that a cancellable getrandom should be the default. Instead, using a provided getrandom_cancellable wrapper seems like the right thing, and trivial compared to all the other complexity the program has to deal with.