This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v8)
- From: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- To: Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>
- Cc: nd <nd at arm dot com>, Joseph Myers <joseph at codesourcery dot com>, Will Deacon <Will dot Deacon at arm dot com>, carlos <carlos at redhat dot com>, Florian Weimer <fweimer at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>, Thomas Gleixner <tglx at linutronix dot de>, Ben Maurer <bmaurer at fb dot com>, Peter Zijlstra <peterz at infradead dot org>, "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>, Boqun Feng <boqun dot feng at gmail dot com>, Dave Watson <davejwatson at fb dot com>, Paul Turner <pjt at google dot com>, Rich Felker <dalias at libc dot org>, linux-kernel <linux-kernel at vger dot kernel dot org>, linux-api <linux-api at vger dot kernel dot org>
- Date: Thu, 18 Apr 2019 16:07:39 +0000
- Subject: Re: [PATCH 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v8)
- References: <email@example.com> <firstname.lastname@example.org> <364803063.586.1555516769056.JavaMail.email@example.com> <alpine.DEB.firstname.lastname@example.org> <1770787324.668.1555530989646.JavaMail.email@example.com> <1066731871.915.1555593471194.JavaMail.firstname.lastname@example.org> <email@example.com> <1055153722.1072.1555602067220.JavaMail.firstname.lastname@example.org>
On 18/04/2019 16:41, Mathieu Desnoyers wrote:
> ----- On Apr 18, 2019, at 11:33 AM, Szabolcs Nagy Szabolcs.Nagy@arm.com wrote:
>> On 18/04/2019 14:17, Mathieu Desnoyers wrote:
>>> ----- On Apr 17, 2019, at 3:56 PM, Mathieu Desnoyers
>>> email@example.com wrote:
>>>> ----- On Apr 17, 2019, at 12:17 PM, Joseph Myers firstname.lastname@example.org wrote:
>>>>> On Wed, 17 Apr 2019, Mathieu Desnoyers wrote:
>>>>>>> +/* RSEQ_SIG is a signature required before each abort handler code.
>>>>>>> + It is a 32-bit value that maps to actual architecture code compiled
>>>>>>> + into applications and libraries. It needs to be defined for each
>>>>>>> + architecture. When choosing this value, it needs to be taken into
>>>>>>> + account that generating invalid instructions may have ill effects on
>>>>>>> + tools like objdump, and may also have impact on the CPU speculative
>>>>>>> + execution efficiency in some cases. */
>>>>>>> +#define RSEQ_SIG 0xd428bc00 /* BRK #0x45E0. */
>>>>>> After further investigation, we should probably do the following
>>>>>> to handle compiling with -mbig-endian on aarch64, which generates
>>>>>> binaries with mixed code vs data endianness (little endian code,
>>>>>> big endian data):
>>>>> First, the comment on RSEQ_SIG should specify whether it is to be
>>>>> interpreted in the code or the data endianness.
>>>> Right. The signature passed as argument to the rseq registration
>>>> system call needs to be in data endianness (currently exposed kernel
>>>> Ideally for userspace, we want to define a signature in code endianness
>>>> that happens to nicely match specific code patterns.
>>> For aarch64, I think we can simply do:
>>> * aarch64 -mbig-endian generates mixed endianness code vs data:
>>> * little-endian code and big-endian data. Ensure the RSEQ_SIG signature
>>> * matches code endianness.
>>> #define RSEQ_SIG_CODE 0xd428bc00 /* BRK #0x45E0. */
>>> #ifdef __ARM_BIG_ENDIAN
>>> #define RSEQ_SIG_DATA 0x00bc28d4 /* BRK #0x45E0. */
>>> #define RSEQ_SIG_DATA RSEQ_SIG_CODE
>>> #define RSEQ_SIG RSEQ_SIG_DATA
>>> Feedback is most welcome,
>> so the RSEQ_SIG value is supposed to be used with .word
>> in asm instead of .inst?
> We want a .inst so it translates into a valid trap instruction.
> It's better to trap in case program execution reaches this
> by mistake (makes debugging easier).
that does not make sense to me.
".inst" is an asm directive that requires a the value to
be the same on BE and LE (normal insn encoding).
".word" is an asm directive that requires the value to
use swapped encoding on BE (if it's used in the instruction
stream it will create a data mapping symbol and disasm to
.word value instead of the instruction mnemonics).
so which one is it?
>> i don't think we use __ARM_* in public headers currently,
>> but hopefully aarch64_be compilers implement it.
> Can I use #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ then ?
hm, i'd either use #ifdef __AARCH64EB__ (since we already use it)
or the portable #include endian.h and __BYTE_ORDER == __BIG_ENDIAN