This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7)
- From: Carlos O'Donell <codonell at redhat dot com>
- To: Tulio Magno Quites Machado Filho <tuliom at ascii dot art dot br>, Alan Modra <amodra at gmail dot com>, Michael Ellerman <mpe at ellerman dot id dot au>
- Cc: Florian Weimer <fweimer at redhat dot com>, Michael Meissner <meissner at linux dot ibm dot com>, Peter Bergner <bergner at vnet dot ibm dot com>, Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>, Paul Burton <paul dot burton at mips dot com>, Will Deacon <will dot deacon at arm dot com>, Boqun Feng <boqun dot feng at gmail dot com>, Heiko Carstens <heiko dot carstens at de dot ibm dot com>, Vasily Gorbik <gor at linux dot ibm dot com>, Martin Schwidefsky <schwidefsky at de dot ibm dot com>, Russell King <linux at armlinux dot org dot uk>, Benjamin Herrenschmidt <benh at kernel dot crashing dot org>, Paul Mackerras <paulus at samba dot org>, carlos <carlos at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, Szabolcs Nagy <szabolcs dot nagy at arm 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>, 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: Tue, 9 Apr 2019 10:13:03 -0400
- Subject: Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7)
- References: <email@example.com> <1965431879.7576.1553529272844.JavaMail.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <20190409092948.GA14424@bubble.grove.modra.org> <email@example.com>
On 4/9/19 9:58 AM, Tulio Magno Quites Machado Filho wrote:
Alan Modra <firstname.lastname@example.org> writes:
Yes, looks fine to me, except that in VLE mode (do we care?)
".long 0x0fe50553" disassembles as
0: 0f e5 se_cmphl r5,r30
2: 05 53 se_mullw r3,r5
No illegal/trap/privileged insn there.
".long 0x0fe5000b" might be better to cover VLE.
Looks good for me too.
The requirement that it be a valid instruction is simply to aid in the
disassembly of rseq regions which may be hand written assembly with a
thin veneer of CFI/DWARF information.
It has already been pointed out that POWER uses data in the instruction
stream for jump tables to implement switch statements, but that specific
use has compiler support and one presumes good debug information. So as
Alan says, there is already data in the insn stream, though such things
can't be good for performance (pollutes D-cache, problematic for
Actually, it better fits what Carlos O'Donnell had requested:
I think the order of preference is:
1. An uncommon insn (with random immediate values), in a literal pool, that is
not a useful ROP/JOP sequence (very uncommon)
2a. A uncommon TRAP hopefully with some immediate data encoded (maybe uncommon)
2b. A NOP to avoid affecting speculative execution (maybe uncommon)
With 2a/2b being roughly equivalent depending on speculative execution policy.
Yes, though "in a literal pool" is something that is not required, since
users might not want literal pools and so we shouldn't require that
feature (it also pollutes D-cache).
Keep in mind the insn will never execute.
If a trap insn calls out the nature of the signature more clearly then
use that instead.