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: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id C52361F9E0 for ; Thu, 30 Apr 2020 16:37:05 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 95B13396E848; Thu, 30 Apr 2020 16:37:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 95B13396E848 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1588264622; bh=N1kujXhR0DAj22ohzNF4EmVUFABeAdXNfPVcnWuHRxo=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=nxAmcbiR18cpdx9y4z9uzDQg/ZE6JEXUyyLjGZJ1kpq+UzM8jiGZg59/qPzV3lALC oXXsAI218LEicIrNLH8yE+mSg3Qqc5mxJ1qghoNVFMS9AQCT4Z+T6HfR/jgccaHh/J heHNSaWMaNYrOpyjBAKsgNRgq+6sH2aIohBHnfe4= 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) To: Mathieu Desnoyers 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-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: , From: Florian Weimer via Libc-alpha Reply-To: Florian Weimer Cc: Rich Felker , libc-alpha , linux-api , Boqun Feng , Will Deacon , linux-kernel , Peter Zijlstra , Ben Maurer , Dave Watson , Thomas Gleixner , Paul , Paul Turner , Joseph Myers Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" * 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