From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 2F9333858422 for ; Thu, 18 Nov 2021 19:44:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2F9333858422 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-92-a74lvpY7PIC6b_5rBMI9Hw-1; Thu, 18 Nov 2021 14:43:59 -0500 X-MC-Unique: a74lvpY7PIC6b_5rBMI9Hw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E176D804142; Thu, 18 Nov 2021 19:43:57 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.131]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5A8F31000324; Thu, 18 Nov 2021 19:43:55 +0000 (UTC) From: Florian Weimer To: Mathieu Desnoyers Cc: Cristian =?utf-8?Q?Rodr=C3=ADguez?= , libc-alpha@sourceware.org , linux-api , Vincenzo Frascino , Jeremy Linton , Rich Felker Subject: Re: Bringing rseq back into glibc References: <87wnl5u5rz.fsf@oldenburg.str.redhat.com> <1748005532.19737.1637264495123.JavaMail.zimbra@efficios.com> Date: Thu, 18 Nov 2021 20:43:53 +0100 In-Reply-To: <1748005532.19737.1637264495123.JavaMail.zimbra@efficios.com> (Mathieu Desnoyers's message of "Thu, 18 Nov 2021 14:41:35 -0500 (EST)") Message-ID: <87ee7ddzba.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 18 Nov 2021 19:44:05 -0000 * Mathieu Desnoyers: > ----- On Nov 18, 2021, at 1:48 PM, Cristian Rodr=C3=ADguez crrodriguez@op= ensuse.org wrote: > >> On Thu, Nov 18, 2021 at 7:17 AM Florian Weimer via Libc-alpha >> wrote: >>=20 >>> 4. Add public symbols __rseq_abi_offset, __rseq_abi_size (currently 32 >>> or 0), __rseq_abi_flags (currently 0). __rseq_abi_offset is the >>> offset to add to the thread pointer (see __builtin_thread_pointer) to >>> get to the rseq area. They will be public ABI symbols. These >>> variables are initialized before user code runs, and changing the >>> results in undefined behavior. >>=20 >> Why not then __get_rseq_whatwever functions and not variables ? or >> maybe writing to these variables results in a compiler or linker error >> instead of UB ? > > rseq critical sections cannot issue function calls, and also function cal= ls > are noticeably expensive compared to an rseq critical section. So all use= rs > would end up needing to make a local copy of the information fetched by t= hose > getters. > > So rather than require all those extra per-user copies, I suspect exposing > a single copy through public glibc symbols is more efficient. Right, and users that want the last bit of performance can still create local copies. > The downside is indeed that writing to those variables is UB. So is writing garbage to the rseq area. 8-) I will see if we can declare this variables as extern const, and make writes to them terminate the process. Thanks, Florian