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;
MIME-Version: 1.0
References: <1050734985.2625.1554838340011.JavaMail.zimbra@efficios.com>
 <1933578130.3292.1554928159928.JavaMail.zimbra@efficios.com>
 <20190411164219.GE29081@fuggles.cambridge.arm.com> <1469455003.811.1555005112414.JavaMail.zimbra@efficios.com>
In-Reply-To: <1469455003.811.1555005112414.JavaMail.zimbra@efficios.com>
From:   Peter Maydell <peter.maydell@linaro.org>
Date:   Thu, 11 Apr 2019 20:55:59 +0100
Message-ID: <CAFEAcA849mmSds9euyvR2uLWqEeA2eedkmcq1O4pT6-S0oK8BA@mail.gmail.com>
Subject: Re: rseq/arm32: choosing rseq code signature
To:     Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc:     Will Deacon <will.deacon@arm.com>,
        libc-alpha <libc-alpha@sourceware.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        carlos <carlos@redhat.com>,
        richard earnshaw <richard.earnshaw@arm.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, 11 Apr 2019 at 18:51, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
> ----- On Apr 11, 2019, at 12:42 PM, Will Deacon will.deacon@arm.com wrote:
> > Peter suggests that anything of the form 0xe7fxdefx should trap in both A32
> > and T32, although it does assemble to UDF; B <imm11> in T16. I'm not sure we
> > should get too obsessed with trying to encode a signature that universally
> > decodes to a trap.
>
> That's a nice trick.
>
> >
> > Whatever you choose, it would be worth checking that it doesn't clash with
> > other allocations such as software breakpoints in GDB.
>
> GDB seems to have [1] :
>
> #define ARM_LE_BREAKPOINT {0xFE,0xDE,0xFF,0xE7}
> #define ARM_BE_BREAKPOINT {0xE7,0xFF,0xDE,0xFE}
> #define THUMB_LE_BREAKPOINT {0xbe,0xbe}
> #define THUMB_BE_BREAKPOINT {0xbe,0xbe}
>
> None of which match the value you hint at.

Hmm? The ARM BPs match 0xe7fxdefx when considered with
the appropriate endianness (clearly somebody has
been down this line of thought before). Still, as long as
we pick different values for the 8 bits of freedom we
have it should be fine.

> /*
>  * RSEQ_SIG uses the udf A32 instruction with an uncommon immediate operand
>  * value 0x5de3. 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 in the A32 instruction set is:
>  *
>  * e7f5def3    udf    #24035    ; 0x5de3
>  *
>  * This translates to the following instruction pattern in the T16 instruction
>  * set:
>  *
>  * little endian:
>  * def3        udf    #243      ; 0xf3
>  * e7f5        b.n    <7f5>
>  *
>  * big endian:
>  * e7f5        b.n    <7f5>
>  * def3        udf    #243      ; 0xf3

Do we really care about big-endian instruction-ordering for Thumb?
It requires (AIUI) either an ARMv7R CPU which implements and sets
SCTLR.IE to 1, or a v6-or-earlier CPU using BE32, and it's going to
be even rarer than normal BE8 big-endian...

thanks
-- PMM