From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 8127E1F463 for ; Fri, 13 Sep 2019 15:58:16 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=dX77RT3HZRu69/wo bxp4nCmRnuQDSgslwncVFmagdxn0IsRa0UsmezlqM49KWmSRN2F75kujRcWePK30 JGzPaqrUOpBS3fkmclLXlAhldniJfh4kaDf0ce2SjXx+m46ttvdT4DnZQR3Cc6I9 vBbyNHF5fAALCgzxPZrwZL8rFdI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type :content-transfer-encoding; s=default; bh=T040WfPCiOEg4nuKXptE8Q jMXbk=; b=Rq3yZCCYgFSWE/ux2TnhJAas+TslTwkzqhO/ikkAXojST27aNeGK8p KRIA0qCQa2ZraPL42dJ1TMNzYInF2hg8k4hejXqVZSdGDdtyvCuUEPBS4Q9TRVbx bUho/9gIGY7FpL6mgTA2OekYqt56mLoJr5dy8sBNsAN9qgQQ44jZA= Received: (qmail 14696 invoked by alias); 13 Sep 2019 15:58:14 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 14682 invoked by uid 89); 13 Sep 2019 15:58:13 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail.efficios.com DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 016E92B50F9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1568390289; bh=t2rOmkzot+SvxnuW5zmOlNOGh9D8GTyBdB/sgjpjO6w=; h=Date:From:To:Message-ID:MIME-Version; b=GaotWm2jgQWH/tVnzh9WUMYiS5GWgqQfyVHe2CiLiaxBnk4oLGGXi9F/lkvafAOHz LeppsoiiP3DC53gFhkscZWzz2FkxTwsYSVR0c3LtFPS6Y9/4z5PvbyON8iIws/wKrW IiUElIo5mxGUmPA94cNPMsUncrJVbW0UVWLloGWLEs8UUnWBj9x4LimLAKh2oPMh2M 8rJ8dnKLo6JKuc5Fw2It0JpnxxYfDTK4Kcv/3VGty2wyDigxjmoEzTHUMF8+JrW7hh qKWqQvLB+n078lWy3YNXa/yILCMAsKYNmXaKzgp6NM5j0AJY4FK3YfE/IH/OWDgnTC YBqmZONtE6NRg== Date: Fri, 13 Sep 2019 11:58:08 -0400 (EDT) From: Mathieu Desnoyers To: carlos Cc: Florian Weimer , Joseph Myers , Szabolcs Nagy , libc-alpha , Thomas Gleixner , Ben Maurer , Peter Zijlstra , "Paul E. McKenney" , Boqun Feng , Will Deacon , Dave Watson , Paul Turner , Rich Felker , linux-kernel , linux-api Message-ID: <1137395748.2754.1568390288746.JavaMail.zimbra@efficios.com> In-Reply-To: <7db64714-3dc5-b322-1edc-736b08ee7d63@redhat.com> References: <20190807142726.2579-1-mathieu.desnoyers@efficios.com> <20190807142726.2579-2-mathieu.desnoyers@efficios.com> <8736h2sn8y.fsf@oldenburg2.str.redhat.com> <7db64714-3dc5-b322-1edc-736b08ee7d63@redhat.com> Subject: Re: [PATCH glibc 2.31 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v12) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- On Sep 11, 2019, at 3:00 PM, carlos carlos@redhat.com wrote: > On 9/11/19 2:26 PM, Florian Weimer wrote: >> * Mathieu Desnoyers: >> >>> +#ifdef SHARED >>> + if (rtld_active ()) >>> + { >>> + /* Register rseq ABI to the kernel. */ >>> + (void) rseq_register_current_thread (); >>> + } >>> +#else >> >> I think this will need *another* check for the inner libc in an audit >> module. See what we do in malloc. __libc_multiple_libcs is supposed to >> cover that, but it's unfortunately not reliable. >> >> I believe without that additional check, the first audit module we load >> will claim rseq, and the main program will not have control over the >> rseq area. Reversed roles would be desirable here. >> >> In October, I hope to fix __libc_multiple_libcs, and then you can use >> just that. (We have a Fedora patch that is supposed to fix it, I need >> to documen the mechanism and upstream it.) > > This is a technical issue we can resolve. I'm unsure whether there are changes I need to do in my rseq patchset, or if this is a separate issue that will be fixed separately before glibc 2.31 is out, which would then update the rseq bits accordingly ? > >>> +/* Advertise Restartable Sequences registration ownership across >>> + application and shared libraries. >>> + >>> + Libraries and applications must check whether this variable is zero or >>> + non-zero if they wish to perform rseq registration on their own. If it >>> + is zero, it means restartable sequence registration is not handled, and >>> + the library or application is free to perform rseq registration. In >>> + that case, the library or application is taking ownership of rseq >>> + registration, and may set __rseq_handled to 1. It may then set it back >>> + to 0 after it completes unregistering rseq. >>> + >>> + If __rseq_handled is found to be non-zero, it means that another >>> + library (or the application) is currently handling rseq registration. >>> + >>> + Typical use of __rseq_handled is within library constructors and >>> + destructors, or at program startup. */ >>> + >>> +int __rseq_handled; >> >> Are there any programs that use __rseq_handled *today*? No, because I told all open source project developers asking whether they can use rseq to wait until we agree on _this_ precise user-level ABI (__rseq_abi and __rseq_handled). Until we agree on this, there _can_ be no users, unless they are willing to suffer conflicts when their application/program is linked against an updated glibc. >> >> I'm less convinced that we actually need this. I don't think we have >> ever done anything like that before, and I don't think it's necessary. >> Any secondary rseq library just needs to note if it could perform >> registration, and if it failed to do so, do not perform unregistration >> in a pthread destructor callback. If that secondary rseq library happens to try to perform registration within its library constructor (before glibc has performed the __rseq_abi TLS registration), we end up in a situation where the secondary library takes ownership of rseq, even though libc would require ownership. This is a scenario we want to avoid. Making sure libc reserves ownership through __rseq_handled (which is a non-TLS variable that can be accessed early in the program lifetime) protects against this. >> >> Sure, there's the matter of pthread destructor ordering, but that >> problem is not different from any other singleton (thread-local or not), >> and the fix for the last time this has come up (TLS destructors vs >> dlclose) was to upgrade glibc. > > This is a braoder issue. > > Mathieu, > > It would be easier to merge the patch set if it were just an unconditional > registration like we do for set_robust_list(). > > What's your thought there? I don't expect set_robust_list was really useful without glibc support. In the current case, rseq can be used by applications and libraries even with older glibc. My goal is to enable such use and not wait for years before end-users upgrade their glibc before rseq can be used. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com