lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 11 Apr 2019 20:55:59 +0100
From:   Peter Maydell <peter.maydell@...aro.org>
To:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:     Will Deacon <will.deacon@....com>,
        libc-alpha <libc-alpha@...rceware.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        carlos <carlos@...hat.com>,
        richard earnshaw <richard.earnshaw@....com>
Subject: Re: rseq/arm32: choosing rseq code signature

On Thu, 11 Apr 2019 at 18:51, Mathieu Desnoyers
<mathieu.desnoyers@...icios.com> wrote:
> ----- On Apr 11, 2019, at 12:42 PM, Will Deacon will.deacon@....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

Powered by blists - more mailing lists