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.
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, 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-s390.h file that updates
the signature value, so I can then pick it up for the glibc
patchset.
Thanks!
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
On Tue, 9 Apr 2019 15:32:22 -0400 (EDT)
Mathieu Desnoyers <[email protected]> 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.
>
> 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, 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-s390.h file that updates
> the signature value, so I can then pick it up for the glibc
> patchset.
The trap4 instruction is a suitable one. The patch would look like this
--
commit 2ee28f6d1de968a71f074ab150384b90b4121216
Author: Martin Schwidefsky <[email protected]>
Date: Wed Apr 10 12:28:41 2019 +0200
s390/rseq: use trap4 for RSEQ_SIG
Use trap4 as the guard instruction for the restartable sequence abort
handler.
Signed-off-by: Martin Schwidefsky <[email protected]>
diff --git a/tools/testing/selftests/rseq/rseq-s390.h b/tools/testing/selftests/rseq/rseq-s390.h
index 1069e85258ce..d4c8e1147d86 100644
--- a/tools/testing/selftests/rseq/rseq-s390.h
+++ b/tools/testing/selftests/rseq/rseq-s390.h
@@ -1,6 +1,13 @@
/* SPDX-License-Identifier: LGPL-2.1 OR MIT */
-#define RSEQ_SIG 0x53053053
+/*
+ * RSEQ_SIG uses the trap4 instruction. As Linux does not make use of the
+ * access-register mode nor the linkage stack this instruction will always
+ * cause a special-operation exception (the trap-enabled bit in the DUCT
+ * is and will stay 0). The instruction pattern is
+ * b2 ff 0f ff trap4 4095(%r0)
+ */
+#define RSEQ_SIG 0xB2FF0FFF
#define rseq_smp_mb() __asm__ __volatile__ ("bcr 15,0" ::: "memory")
#define rseq_smp_rmb() rseq_smp_mb()
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
----- On Apr 10, 2019, at 6:32 AM, schwidefsky [email protected] wrote:
> On Tue, 9 Apr 2019 15:32:22 -0400 (EDT)
> Mathieu Desnoyers <[email protected]> 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.
>>
>> 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, 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-s390.h file that updates
>> the signature value, so I can then pick it up for the glibc
>> patchset.
>
> The trap4 instruction is a suitable one. The patch would look like this
Great! I'm picking it up into my rseq tree if that's OK with you.
Thanks,
Mathieu
> --
> commit 2ee28f6d1de968a71f074ab150384b90b4121216
> Author: Martin Schwidefsky <[email protected]>
> Date: Wed Apr 10 12:28:41 2019 +0200
>
> s390/rseq: use trap4 for RSEQ_SIG
>
> Use trap4 as the guard instruction for the restartable sequence abort
> handler.
>
> Signed-off-by: Martin Schwidefsky <[email protected]>
>
> diff --git a/tools/testing/selftests/rseq/rseq-s390.h
> b/tools/testing/selftests/rseq/rseq-s390.h
> index 1069e85258ce..d4c8e1147d86 100644
> --- a/tools/testing/selftests/rseq/rseq-s390.h
> +++ b/tools/testing/selftests/rseq/rseq-s390.h
> @@ -1,6 +1,13 @@
> /* SPDX-License-Identifier: LGPL-2.1 OR MIT */
>
> -#define RSEQ_SIG 0x53053053
> +/*
> + * RSEQ_SIG uses the trap4 instruction. As Linux does not make use of the
> + * access-register mode nor the linkage stack this instruction will always
> + * cause a special-operation exception (the trap-enabled bit in the DUCT
> + * is and will stay 0). The instruction pattern is
> + * b2 ff 0f ff trap4 4095(%r0)
> + */
> +#define RSEQ_SIG 0xB2FF0FFF
>
> #define rseq_smp_mb() __asm__ __volatile__ ("bcr 15,0" ::: "memory")
> #define rseq_smp_rmb() rseq_smp_mb()
> --
> blue skies,
> Martin.
>
> "Reality continues to ruin my life." - Calvin.
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
----- On Apr 10, 2019, at 11:52 AM, schwidefsky [email protected] wrote:
> On Wed, 10 Apr 2019 11:50:39 -0400 (EDT)
> Mathieu Desnoyers <[email protected]> wrote:
>
>> ----- On Apr 10, 2019, at 6:32 AM, schwidefsky [email protected] wrote:
>>
>> > On Tue, 9 Apr 2019 15:32:22 -0400 (EDT)
>> > Mathieu Desnoyers <[email protected]> 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.
>> >>
>> >> 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, 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-s390.h file that updates
>> >> the signature value, so I can then pick it up for the glibc
>> >> patchset.
>> >
>> > The trap4 instruction is a suitable one. The patch would look like this
>>
>> Great! I'm picking it up into my rseq tree if that's OK with you.
>
> Just added the patch to s390/linux:features for the next merge window as well.
Sounds good! I'll carry it in my tree to have a comprehensive up-to-date list of
rseq signatures for all architectures in a single tree. Worse-case the exact same
change will be pulled from both architecture and rseq trees, which I don't think
should be an issue, right ?
Thanks,
Mathieu
>
> --
> blue skies,
> Martin.
>
> "Reality continues to ruin my life." - Calvin.
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
On Wed, 10 Apr 2019 11:57:36 -0400 (EDT)
Mathieu Desnoyers <[email protected]> wrote:
> ----- On Apr 10, 2019, at 11:52 AM, schwidefsky [email protected] wrote:
>
> > On Wed, 10 Apr 2019 11:50:39 -0400 (EDT)
> > Mathieu Desnoyers <[email protected]> wrote:
> >
> >> ----- On Apr 10, 2019, at 6:32 AM, schwidefsky [email protected] wrote:
> >>
> >> > On Tue, 9 Apr 2019 15:32:22 -0400 (EDT)
> >> > Mathieu Desnoyers <[email protected]> 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.
> >> >>
> >> >> 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, 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-s390.h file that updates
> >> >> the signature value, so I can then pick it up for the glibc
> >> >> patchset.
> >> >
> >> > The trap4 instruction is a suitable one. The patch would look like this
> >>
> >> Great! I'm picking it up into my rseq tree if that's OK with you.
> >
> > Just added the patch to s390/linux:features for the next merge window as well.
>
> Sounds good! I'll carry it in my tree to have a comprehensive up-to-date list of
> rseq signatures for all architectures in a single tree. Worse-case the exact same
> change will be pulled from both architecture and rseq trees, which I don't think
> should be an issue, right ?
Should be fine, the worst that can happen is a minor merge conflict.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
On Wed, 10 Apr 2019 11:50:39 -0400 (EDT)
Mathieu Desnoyers <[email protected]> wrote:
> ----- On Apr 10, 2019, at 6:32 AM, schwidefsky [email protected] wrote:
>
> > On Tue, 9 Apr 2019 15:32:22 -0400 (EDT)
> > Mathieu Desnoyers <[email protected]> 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.
> >>
> >> 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, 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-s390.h file that updates
> >> the signature value, so I can then pick it up for the glibc
> >> patchset.
> >
> > The trap4 instruction is a suitable one. The patch would look like this
>
> Great! I'm picking it up into my rseq tree if that's OK with you.
Just added the patch to s390/linux:features for the next merge window as well.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.