linux-kernel - Re: rseq/arm32: choosing rseq code signature

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:   Mon, 15 Apr 2019 09:11:30 -0400 (EDT)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     peter maydell <peter.maydell@...aro.org>
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 Apr 11, 2019, at 3:55 PM, peter maydell peter.maydell@...aro.org wrote:

> 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.

Right. I selected 0xe7f5def3, which should ensure we are distinct
from gdb's choice.

> 
>> /*
>>  * 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...

I don't think we care enough about it to look for a trick to
turn the branch into something else (which would not branch away from the
udf instruction), but considering this signature will be ABI, it's good to
be thorough documentation-wise and cover all existing cases.

Thoughts ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com