From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by sourceware.org (Postfix) with ESMTP id 76801396E07C for ; Thu, 30 Apr 2020 16:36:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 76801396E07C Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-413-629V3yTBP9erMAd_WkCRDQ-1; Thu, 30 Apr 2020 12:36:55 -0400 X-MC-Unique: 629V3yTBP9erMAd_WkCRDQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5BEDC107ACF9; Thu, 30 Apr 2020 16:36:53 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-113-72.ams2.redhat.com [10.36.113.72]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3B6F76061B; Thu, 30 Apr 2020 16:36:46 +0000 (UTC) From: Florian Weimer To: Mathieu Desnoyers Cc: carlos , Joseph Myers , Szabolcs Nagy , libc-alpha , Thomas Gleixner , Ben Maurer , Peter Zijlstra , Paul , Boqun Feng , Will Deacon , Dave Watson , Paul Turner , Rich Felker , linux-kernel , linux-api Subject: Re: [RFC PATCH glibc 1/3] glibc: Perform rseq(2) registration at C startup and thread creation (v18) References: <20200428171513.22926-1-mathieu.desnoyers@efficios.com> <875zdhmaft.fsf@oldenburg2.str.redhat.com> <1287616647.77866.1588263099045.JavaMail.zimbra@efficios.com> Date: Thu, 30 Apr 2020 18:36:44 +0200 In-Reply-To: <1287616647.77866.1588263099045.JavaMail.zimbra@efficios.com> (Mathieu Desnoyers's message of "Thu, 30 Apr 2020 12:11:39 -0400 (EDT)") Message-ID: <878sidkk0z.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Spam-Status: No, score=-9.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 16:37:01 -0000 * Mathieu Desnoyers: > @deftypevar {struct rseq} __rseq_abi > @standards{Linux, sys/rseq.h} > @Theglibc{} implements a @code{__rseq_abi} TLS symbol to interact with the > Restartable Sequences system call (Linux-specific). The layout of this > structure is defined by the @file{sys/rseq.h} header. Registration of each > thread's @code{__rseq_abi} is performed by @theglibc{} at libc library > initialization and thread creation. s/libc library/library/ > The main executable and shared libraries may either have an undefined > @code{__rseq_abi} TLS symbol, or define their own, with the same > declaration as the one present in @file{sys/rseq.h}. The dynamic linker > will ensure that only one of those available symbols will be used at > runtime across the process. > > If the main executable or shared libraries observe an uninitialized > @code{__rseq_abi.cpu_id} field (value @code{RSEQ_CPU_ID_UNINITIALIZED}), they > may perform rseq registration to the kernel: this means either glibc was > prevented from doing the registration, or an older glibc version, which does > not include rseq support, is in use. When the main executable or a library > thus takes ownership of the registration, the memory used to hold the > @code{__rseq_abi} TLS variable must stay allocated, and is not re-used, until > the very end of the thread lifetime or until an explicit rseq unregistration > for that thread is performed. It is not recommended to dlclose() libraries > owning the @code{__rseq_abi} TLS variable. s/dlclose()/@code{dlclose}/ (no parentheses) Rest looks okay. >>> + if (__rseq_abi.cpu_id == RSEQ_CPU_ID_REGISTRATION_FAILED) >>> + return; >>> + ret = INTERNAL_SYSCALL_CALL (rseq, &__rseq_abi, sizeof (struct rseq), >>> + 0, RSEQ_SIG); >>> + if (INTERNAL_SYSCALL_ERROR_P (ret) && >>> + INTERNAL_SYSCALL_ERRNO (ret) != EBUSY) >>> + __rseq_abi.cpu_id = RSEQ_CPU_ID_REGISTRATION_FAILED; >> >> Sorry, I forgot: Please add a comment that the EBUSY error is ignored >> because registration may have already happened in a legacy library. > > Considering that we now disable signals across thread creation, and that > glibc's initialization happens before other libraries' constructors > (as far as I remember even before LD_PRELOADed library constructors), > in which scenario can we expect to have EBUSY here ? That's a good point. > Not setting __rseq_abi.cpu_id to RSEQ_CPU_ID_REGISTRATION_FAILED in case > of EBUSY is more a way to handle "unforeseen" scenarios where somehow the > registration would already be done. But I cannot find an "expected" > scenario which would lead to this now. > > So if EBUSY really is unexpected, how should we treat that ? I don't think > setting REGISTRATION_FAILED would be appropriate, because then it would > break assumption of the prior successful registration that have already > been done by this thread. You could call __libc_fatal with an error message. ENOSYS is definitely an expected error code here, and EPERM (and perhaps EACCES) can happen with seccomp filters. Thanks, Florian