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
| ||
|
Message-ID: <1469455003.811.1555005112414.JavaMail.zimbra@efficios.com> Date: Thu, 11 Apr 2019 13:51:52 -0400 (EDT) From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com> To: Will Deacon <will.deacon@....com> Cc: libc-alpha <libc-alpha@...rceware.org>, linux-kernel <linux-kernel@...r.kernel.org>, carlos <carlos@...hat.com>, peter maydell <peter.maydell@...aro.org>, richard earnshaw <richard.earnshaw@....com> Subject: Re: rseq/arm32: choosing rseq code signature ----- On Apr 11, 2019, at 12:42 PM, Will Deacon will.deacon@....com wrote: > Hi Mathieu, > > On Wed, Apr 10, 2019 at 04:29:19PM -0400, Mathieu Desnoyers wrote: >> ----- On Apr 9, 2019, at 3:32 PM, Mathieu Desnoyers >> mathieu.desnoyers@...icios.com wrote: >> > 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 (e.g. thumb for arm), 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-arm.h file that updates >> > the signature value, so I can then pick it up for the glibc >> > patchset. >> >> Would the following diff work for you ? If so, can I get your >> acked-by ? > > I had a quick chat with Richard and Peter (CC'd), since they're much more > familiar with the A32 instruction set than I am and also have a better view > of what might already be in use. > > 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. So I could pick "0xe7f5def3", which would map to the following comment: /* * 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 */ #define RSEQ_SIG 0xe7f5def3 Thoughts ? Thanks! Mathieu [1] https://github.com/bminor/binutils-gdb/blob/master/gdb/arm-tdep.c#L7705-L7742 -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Powered by blists - more mailing lists