Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2166695yba; Mon, 15 Apr 2019 06:23:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqwnZdKhyOXMlmS8Mf2zTBEfoyTI5Ow4e/3U8oLW+trqgarkdsT2gk3a8HZaVHNSPLe3slIy X-Received: by 2002:a17:902:bc85:: with SMTP id bb5mr48842256plb.310.1555334612779; Mon, 15 Apr 2019 06:23:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555334612; cv=none; d=google.com; s=arc-20160816; b=LGV0F58QZ+bm7b6T0BEQ8VYR33XQ3+hi+8ZL2jsBAN6Kqp/FQYnsqkDxeTgMHKUcQ/ qXMfiSG6s3Fd3To+DRYXBJ4SMl2J+IRyAgCgdmtgRcO6ioTgB8jiy4XSIPVlq6nrtzOs /QHtyJC2s2VMRR9foShk8TESLI1h7dXK1IXXGEaHiF7CTHVi5zpvAmqXxs+adn0HvOqh E4jqQd3cysRr+Mx8HiZis/1RmTA+Ts5Dmznd2Q9TzhTbMXZ9GVY+QmfO5Osj7O7M4b0l 0OowiS5iQ5DBbAWBTnIAK3qk5tdaSzKC8fso2eUIms4Xzi7c9riinL8C2BfUiHi9Nt7n igGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:thread-index:thread-topic :content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:dkim-signature:dkim-filter; bh=bYKkERI1SwG+4Ei/g+V6d5eNPDTPu1ET8bVIr4ZqnNM=; b=0tlCY50au+d9ALCZqCva9JEZ1vVFAVVDjsPXvu76nhvEWYYmY7ugK/w7VE2KedutTq pdoVjSaysull+fsfMbbUS5w1yXY1kQCLaaF1NB4aHvwX3VNvNYLVel+0RRn9dcTWZiJt QMJdgB/L3yU+ognKz0adwOplbGtwkWlS+Vobqp3zQkW/IZp6i+SBTDffgktk65yMniIL Hl1GgwN3Bh42tKjkUhwhqAA72ZgDls9v6A/1GOHgtoPVZonZ7PpLyflPuJhtD+bgoj9Y hxtreuG07yDfZDzavINk9Zv4aF4SbSE4YSNhOaRZo/f5kfmikAkdOmb9JcgeL8nhwAI1 KvLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@efficios.com header.s=default header.b=czIi1vdx; 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=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f1si28958912pff.158.2019.04.15.06.23.16; Mon, 15 Apr 2019 06:23:32 -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; dkim=pass header.i=@efficios.com header.s=default header.b=czIi1vdx; 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=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727373AbfDONWk (ORCPT + 99 others); Mon, 15 Apr 2019 09:22:40 -0400 Received: from mail.efficios.com ([167.114.142.138]:40864 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726095AbfDONWk (ORCPT ); Mon, 15 Apr 2019 09:22:40 -0400 Received: from localhost (ip6-localhost [IPv6:::1]) by mail.efficios.com (Postfix) with ESMTP id 79869B7C4A; Mon, 15 Apr 2019 09:22:38 -0400 (EDT) Received: from mail.efficios.com ([IPv6:::1]) by localhost (mail02.efficios.com [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id ZSrCnVQznHYP; Mon, 15 Apr 2019 09:22:38 -0400 (EDT) Received: from localhost (ip6-localhost [IPv6:::1]) by mail.efficios.com (Postfix) with ESMTP id E4EABB7C43; Mon, 15 Apr 2019 09:22:37 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com E4EABB7C43 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1555334557; bh=bYKkERI1SwG+4Ei/g+V6d5eNPDTPu1ET8bVIr4ZqnNM=; h=Date:From:To:Message-ID:MIME-Version; b=czIi1vdxuYcWyi7/5gQqMluofUUbkUt2ivk9eXtOxy9zfr60Chog8/6bWQ18+LDgE Hbewnd/IARIi/z1Y3nSidFFQuCYsXWcVwaQdsk2ohQhpU58linawk5H/Q6G5ILezSc GpFnS23HOxov1/9bFusQDvGnfLxU7yyqTH18MxbhiIOgdEiJKNSGljmDw7sIPgtBYo KMwCEzrM5KT2dEQ4qZD15rsoX99b5Dj4dU8D7uYyMfE7mYVAbX8Vv7DVz51q5Tjgqn z/EZurFoBzlt5cIEupFTkBjICs9A3uOQa8ME/69e9NRYb11lH1US/oU57TzS96uZu2 qYmjhgslZo6xA== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([IPv6:::1]) by localhost (mail02.efficios.com [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id 2P_aT5QrQHns; Mon, 15 Apr 2019 09:22:37 -0400 (EDT) Received: from mail02.efficios.com (mail02.efficios.com [167.114.142.138]) by mail.efficios.com (Postfix) with ESMTP id C5B7AB7C3C; Mon, 15 Apr 2019 09:22:37 -0400 (EDT) Date: Mon, 15 Apr 2019 09:22:37 -0400 (EDT) From: Mathieu Desnoyers To: Florian Weimer Cc: Will Deacon , libc-alpha , linux-kernel , carlos Message-ID: <1341767794.285.1555334557497.JavaMail.zimbra@efficios.com> In-Reply-To: <87pnpsd91x.fsf@oldenburg2.str.redhat.com> References: <1050734985.2625.1554838340011.JavaMail.zimbra@efficios.com> <87pnpsd91x.fsf@oldenburg2.str.redhat.com> Subject: Re: rseq/arm32: choosing rseq code signature MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.142.138] X-Mailer: Zimbra 8.8.12_GA_3794 (ZimbraWebClient - FF66 (Linux)/8.8.12_GA_3794) Thread-Topic: rseq/arm32: choosing rseq code signature Thread-Index: fsYjoZseDMCAVxBdA8tCwrEOc3OPKQ== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Apr 11, 2019, at 8:24 AM, Florian Weimer fweimer@redhat.com wrote: > * 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)? Here is how I plan to use it: - rseq registration performed by glibc, - rseq critical section abort handlers: - inlined into applications, - inlined into libraries. I plan that it will be mostly used through librseq headers, but inlined into applications/libraries, which really makes this a fixed ABI once it's published through public headers. > > Actually rseq users will emit the signature directly into the text > section, right? They never have to load it into a register, I assume. The user-space libraries defining rseq critical sections only emit this signature into their text section. However, the kernel will load that signature and compare its value before moving the instruction pointer to the abort handler. So it gets eventually loaded into a register and compared by the kernel, not by user-space. > 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. The kernel knows at which address the RSEQ_SIG sits based on the abort_ip of the current rseq_cs struct. Getting the address of the abort_ip is performed through an assembler label. Note that on arm32, I had to use ".arm\n\t.inst 0xNNNNNNNN" rather than ".long 0xNNNNNNNN" to ensure the assembler emits the signature as an actual instruction rather than non-instruction "data". This modifies the content of the symbol table .symtab elf section. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com