From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Thomas Gleixner <tglx@linutronix.de>,
Andy Lutomirski <luto@amacapital.net>,
Peter Zijlstra <peterz@infradead.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Andi Kleen <andi@firstfloor.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>
Cc: libc-alpha <libc-alpha@sourceware.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Carlos O'Donell <carlos@redhat.com>, x86 <x86@kernel.org>
Subject: Re: rseq/x86: choosing rseq code signature
Date: Tue, 9 Apr 2019 16:43:42 -0400 (EDT) [thread overview]
Message-ID: <913288111.2663.1554842622822.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <11513896.2624.1554838336494.JavaMail.zimbra@efficios.com>
----- On Apr 9, 2019, at 3:32 PM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:
> Hi,
>
> 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.
>
> Currently, tools/testing/selftests/rseq/rseq-x86.h defines RSEQ_SIG
> as 0x53053053, and uses it as an immediate operand to the following
> instruction opcodes (as suggested by Andy Lutomirski):
>
> x86-32:
> - .byte 0x0f, 0x1f, 0x05: nopl <sig>
>
> x86-64:
> - .byte 0x0f, 0x1f, 0x05: nopl <sig>(%rip)
>
> 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.
>
> The main advantage of choosing a trap instruction over a no-op is to ensure the
> program traps if the execution flow gets redirected to the signature by mistake
> (makes it easier to debug). It's not a hard requirement, but it would be a
> bonus.
>
> Are there trap instructions that take an uncommon 4-byte immediate
> operand you would recommend on x86 32/64 ? Or is the current choice of
> nopl confirmed to be right one ?
>
> 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########
Peter Zijlstra suggested to use "invlpg" in user-space, which should generate
a trap. The only concern would be emulators, but ideally they would not try to
decode an instruction that is never executed. This would lead to the following
patch. Any objections/ack ?
diff --git a/tools/testing/selftests/rseq/rseq-x86.h b/tools/testing/selftests/rseq/rseq-x86.h
index 2d4887b5d3f0..e9c8a9879e18 100644
--- a/tools/testing/selftests/rseq/rseq-x86.h
+++ b/tools/testing/selftests/rseq/rseq-x86.h
@@ -7,6 +7,11 @@
#include <stdint.h>
+/*
+ * RSEQ_SIG is used with the following privileged instructions, which trap in user-space:
+ * x86-32: 0f 01 3d 53 30 05 53 invlpg 0x53053053
+ * x86-64: 0f 01 3d 53 30 05 53 invlpg 0x53053053(%rip)
+ */
#define RSEQ_SIG 0x53053053
#ifdef __x86_64__
@@ -78,8 +83,8 @@ do { \
#define RSEQ_ASM_DEFINE_ABORT(label, teardown, abort_label) \
".pushsection __rseq_failure, \"ax\"\n\t" \
- /* Disassembler-friendly signature: nopl <sig>(%rip). */\
- ".byte 0x0f, 0x1f, 0x05\n\t" \
+ /* Disassembler-friendly signature: invlpg <sig>(%rip). */\
+ ".byte 0x0f, 0x01, 0x3d\n\t" \
".long " __rseq_str(RSEQ_SIG) "\n\t" \
__rseq_str(label) ":\n\t" \
teardown \
@@ -605,8 +610,8 @@ do { \
#define RSEQ_ASM_DEFINE_ABORT(label, teardown, abort_label) \
".pushsection __rseq_failure, \"ax\"\n\t" \
- /* Disassembler-friendly signature: nopl <sig>. */ \
- ".byte 0x0f, 0x1f, 0x05\n\t" \
+ /* Disassembler-friendly signature: invlpg <sig>. */ \
+ ".byte 0x0f, 0x1f, 0x3d\n\t" \
".long " __rseq_str(RSEQ_SIG) "\n\t" \
__rseq_str(label) ":\n\t" \
teardown \
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2019-04-09 20:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-09 19:32 rseq/x86: choosing rseq code signature Mathieu Desnoyers
2019-04-09 20:43 ` Mathieu Desnoyers [this message]
2019-04-10 0:50 ` Zack Weinberg
2019-04-10 1:57 ` Andy Lutomirski
2019-04-10 4:19 ` Mathieu Desnoyers
2019-04-10 6:54 ` Peter Zijlstra
2019-04-10 15:47 ` Mathieu Desnoyers
2019-04-10 17:57 ` Peter Zijlstra
2019-04-10 18:05 ` 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=913288111.2663.1554842622822.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=andi@firstfloor.org \
--cc=bp@alien8.de \
--cc=carlos@redhat.com \
--cc=hpa@zytor.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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.