From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Will Deacon <will.deacon@arm.com>
Cc: libc-alpha <libc-alpha@sourceware.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
carlos <carlos@redhat.com>
Subject: Re: rseq/arm32: choosing rseq code signature
Date: Wed, 10 Apr 2019 16:29:19 -0400 (EDT) [thread overview]
Message-ID: <1933578130.3292.1554928159928.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <1050734985.2625.1554838340011.JavaMail.zimbra@efficios.com>
----- On Apr 9, 2019, at 3:32 PM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:
> Hi Will,
>
> We are about to include the code signature required prior to restartable
> sequences abort handlers into glibc, which will make this ABI choice final.
> We need architecture maintainer input on that signature value.
>
> That code signature is placed before each abort handler, so the kernel can
> validate that it is indeed jumping to an abort handler (and not some
> arbitrary attacker-chosen code). The signature is never executed.
>
> The current discussion thread on the glibc mailing list leads us towards
> using a trap with uncommon immediate operand, which simplifies integration
> with disassemblers, emulators, makes it easier to debug if the control
> flow gets redirected there by mistake, and is nicer for some architecture's
> speculative execution.
>
> We can have different signatures for each sub-architecture, as long as they
> don't have to co-exist within the same process. We can special-case with
> #ifdef for each sub-architecture and endianness if need be. If the architecture
> has instruction set extensions that can co-exist with the architecture
> instruction set within the same process (e.g. thumb for arm), we need to take
> into account to which instruction the chosen signature value would map (and
> possibly decide if we need to extend rseq to support many signatures).
>
> Here is an example of rseq signature definition template:
>
> /*
> * TODO: document trap instruction objdump output on each sub-architecture
> * instruction sets, as well as instruction set extensions.
> */
> #define RSEQ_SIG 0x########
>
> Ideally we'd need a patch on top of the Linux kernel
> tools/testing/selftests/rseq/rseq-arm.h file that updates
> the signature value, so I can then pick it up for the glibc
> patchset.
Would the following diff work for you ? If so, can I get your
acked-by ?
diff --git a/tools/testing/selftests/rseq/rseq-arm.h b/tools/testing/selftests/rseq/rseq-arm.h
index 5f262c54364f..1f261ad2ac1b 100644
--- a/tools/testing/selftests/rseq/rseq-arm.h
+++ b/tools/testing/selftests/rseq/rseq-arm.h
@@ -5,7 +5,17 @@
* (C) Copyright 2016-2018 - Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
*/
-#define RSEQ_SIG 0x53053053
+/*
+ * RSEQ_SIG uses the udf A32 instruction with an uncommon immediate operand
+ * value 0x5305. This traps if user-space reaches this instruction by mistake,
+ * and the uncommon operand ensures the kernel does not move the instruction
+ * pointer to attacker-controlled code on rseq abort.
+ *
+ * The instruction pattern is:
+ *
+ * e7f530f5 udf #21253 ; 0x5305
+ */
+#define RSEQ_SIG 0xe7f530f5
#define rseq_smp_mb() __asm__ __volatile__ ("dmb" ::: "memory", "cc")
#define rseq_smp_rmb() __asm__ __volatile__ ("dmb" ::: "memory", "cc")
@@ -78,7 +88,8 @@ do { \
__rseq_str(table_label) ":\n\t" \
".word " __rseq_str(version) ", " __rseq_str(flags) "\n\t" \
".word " __rseq_str(start_ip) ", 0x0, " __rseq_str(post_commit_offset) ", 0x0, " __rseq_str(abort_ip) ", 0x0\n\t" \
- ".word " __rseq_str(RSEQ_SIG) "\n\t" \
+ ".arm\n\t" \
+ ".inst " __rseq_str(RSEQ_SIG) "\n\t" \
__rseq_str(label) ":\n\t" \
teardown \
"b %l[" __rseq_str(abort_label) "]\n\t"
>
> Thanks!
>
> Mathieu
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2019-04-10 20:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-09 19:32 rseq/arm32: choosing rseq code signature Mathieu Desnoyers
2019-04-10 20:29 ` Mathieu Desnoyers [this message]
2019-04-11 16:42 ` Will Deacon
2019-04-11 17:51 ` Mathieu Desnoyers
2019-04-11 19:55 ` Peter Maydell
2019-04-15 13:11 ` Mathieu Desnoyers
2019-04-15 13:30 ` Peter Maydell
2019-04-15 13:37 ` Mathieu Desnoyers
2019-04-16 13:39 ` Mathieu Desnoyers
2019-04-17 10:37 ` Richard Earnshaw (lists)
2019-04-17 14:43 ` Mathieu Desnoyers
2019-04-17 15:30 ` Mathieu Desnoyers
2019-04-18 16:18 ` Richard Earnshaw (lists)
2019-04-11 12:24 ` Florian Weimer
2019-04-15 13:22 ` Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1933578130.3292.1554928159928.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=carlos@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-kernel@vger.kernel.org \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.