----- On Apr 11, 2019, at 3:55 PM, peter maydell [email protected] wrote:
> On Thu, 11 Apr 2019 at 18:51, Mathieu Desnoyers > <[email protected]> wrote: >> ----- On Apr 11, 2019, at 12:42 PM, Will Deacon [email protected] 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
