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.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,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 D39AB1F453 for ; Wed, 30 Jan 2019 18:51:34 +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:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; q=dns; s=default; b=mNsy5 R+LbQiW+d3F5l4WhxWrB4xHnOtHqkjSr7t+SKe1CuEjuZWtYPjdqD3vC9VeI/f82 +rD6oaeVzjrVVFQMDetbZi2Vc/Z0CpGjM0YkiMGoPea4mVyWeFp5bV40FLz6gucS 9cTZuq3bZy2gSibWCCKJyVqDfm9uLRK7hM/lDc= 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:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; s=default; bh=/Y9BFpnK8L4 mAKyw+/sNp4rR3AM=; b=FxRxzrHynmH5J4pqjbG+QWaeul009MdA9vEiIIQA6mf TOQOF865DpluDYg8pgZ26dMC9kJmbjbwpO3mom8xMtEM20GC9lcZcpEow3o2JqRh Q8MIYBQfdAa0giJVgwoLk/3sQFgeBDjpzbxDRHaCUErahDnHTNsKX9kUoX4+IOjE = Received: (qmail 34251 invoked by alias); 30 Jan 2019 18:51:31 -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 34242 invoked by uid 89); 30 Jan 2019 18:51:31 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.redhat.com From: Florian Weimer To: Zack Weinberg Cc: Mathieu Desnoyers , Joseph Myers , libc-alpha Subject: Re: [RFC PATCH glibc 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v6) References: <20190121213530.23803-1-mathieu.desnoyers@efficios.com> <632671842.3079.1548781059601.JavaMail.zimbra@efficios.com> <596949707.3888.1548812359874.JavaMail.zimbra@efficios.com> <1832200535.4162.1548871426959.JavaMail.zimbra@efficios.com> Date: Wed, 30 Jan 2019 19:51:26 +0100 In-Reply-To: (Zack Weinberg's message of "Wed, 30 Jan 2019 13:30:44 -0500") Message-ID: <87o97yges1.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain * Zack Weinberg: > In that case, is there any reason not to use the same value on _all_ > architectures? Or maybe the same value on all 32-bit architectures, > and another one on all 64-bit architectures? I think the intent here is to use a value that would be extremely unlikely to appear in the instruction stream, so that jump target pointer in struct rseq_cs can be somewhat validated before the program counter is updated. This doesn't have to be a trapping instruction (in fact, the default trapping instruction would probably be a bad choice because the instruction does appear in the text segment quite frequently). But even if we choose an optimal value for all currently supported architectures, we might add an architecture in the future which prefers a different value. Thanks, Florian