Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5763248yba; Thu, 11 Apr 2019 05:25:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqz2DaeGZY4d1MaPHRlNcSZP1hjcjHkfIbJFt4Vap/2o4vX8xkzrnaOR67VEGYLJLdbvbXGS X-Received: by 2002:a63:e850:: with SMTP id a16mr44671499pgk.195.1554985551721; Thu, 11 Apr 2019 05:25:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554985551; cv=none; d=google.com; s=arc-20160816; b=qBVu8ZSI1IuK8Uibdr6cI57y0RyLWjexYlyc5CW/RF7BJW/muW+jouyqVE/D7WHd1x Sxt/AWczUj1q5jqwH8Xxjs/yPZTDeriBxFrdgL8q/31g8IpnvO1RrSXgnpgoIm1+lPRR QQ2elCIRg+sKKIE5A8gSuXJggoiZRg6P50JYfujNLwMNoqfDFB/P3/t8rm62VleNvAgN 0bGBTxdTgT/uT6FgMA1KwcbOD+NC58SA0JNGtsDpUEN15UQ740n3Ip9cRtyJ33Ax5cxF Ngg+wW1Bz3hiq5do4lufwioaCZlYM2pnCvTixJbZsWqKcfi4neP9B3q7x/E7Eamm5Be3 gmIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from; bh=VY1BZ7PwDLYNpho0kECmJ91VCtaFV6Sz4SQ5vE8KcTA=; b=fLdX990kPWCNomtZDhS/qbkRSzYKkVthqZJNITweXSpqHka7VYVXth8mxGQKXxCR7K uy97ZtGlqc/xRLuKD6FSDwv3lqH7O0cyAMgUhebylm1ONRBuUXw5C9xh5Gp1/RFkJInQ iHIRnpyIZzhRudcen0L8xxkDspyX2POy19vXhkZO/xE8FJpKe+4XsWR5nf8tD8z0auag LCtjzcOtdOjbk6NAVCAXeqDZBLSz7YASbchsVZS65/XqXAkHaeWSAIYM7njHxtpSMGJg V9eQ4zSpCJN+sKlSEs8An30YIjN6ggFCG86RDZbPsKyxE2MM8JYxh148SAsIZcZc/4ir Tk/g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w126si36311344pfb.196.2019.04.11.05.25.35; Thu, 11 Apr 2019 05:25:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726814AbfDKMYP (ORCPT + 99 others); Thu, 11 Apr 2019 08:24:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32798 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726517AbfDKMYP (ORCPT ); Thu, 11 Apr 2019 08:24:15 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 72C76883BA; Thu, 11 Apr 2019 12:24:15 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-116-32.ams2.redhat.com [10.36.116.32]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0568819742; Thu, 11 Apr 2019 12:24:11 +0000 (UTC) From: Florian Weimer To: Mathieu Desnoyers Cc: Will Deacon , libc-alpha , linux-kernel , Carlos O'Donell Subject: Re: rseq/arm32: choosing rseq code signature References: <1050734985.2625.1554838340011.JavaMail.zimbra@efficios.com> Date: Thu, 11 Apr 2019 14:24:10 +0200 In-Reply-To: <1050734985.2625.1554838340011.JavaMail.zimbra@efficios.com> (Mathieu Desnoyers's message of "Tue, 9 Apr 2019 15:32:20 -0400 (EDT)") Message-ID: <87pnpsd91x.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 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 11 Apr 2019 12:24:15 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Mathieu Desnoyers: > /* > * TODO: document trap instruction objdump output on each sub-architecture > * instruction sets, as well as instruction set extensions. > */ > #define RSEQ_SIG 0x######## Will RSEQ_SIG actually be needed at run time outside the rseq implementation library (whether it's glibc or something else)? Actually rseq users will emit the signature directly into the text section, right? They never have to load it into a register, I assume. My concern is that on some architectures, the very act of referencing RSEQ_SIG will put it into the text section, as a non-instruction, which is not what we want. Thanks, Florian