From: Carlos O'Donell <codonell@redhat.com> To: Tulio Magno Quites Machado Filho <tuliom@ascii.art.br>, Alan Modra <amodra@gmail.com>, Michael Ellerman <mpe@ellerman.id.au> Cc: Florian Weimer <fweimer@redhat.com>, Michael Meissner <meissner@linux.ibm.com>, Peter Bergner <bergner@vnet.ibm.com>, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Paul Burton <paul.burton@mips.com>, Will Deacon <will.deacon@arm.com>, Boqun Feng <boqun.feng@gmail.com>, Heiko Carstens <heiko.carstens@de.ibm.com>, Vasily Gorbik <gor@linux.ibm.com>, Martin Schwidefsky <schwidefsky@de.ibm.com>, Russell King <linux@armlinux.org.uk>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org>, carlos <carlos@redhat.com>, Joseph Myers <joseph@codesourcery.com>, Szabolcs Nagy <szabolcs.nagy@arm.com>, libc-alpha <libc-alpha@sourceware.org>, Thomas Gleixner <tglx@linutronix.de>, Ben Maurer <bmaurer@fb.com>, Peter Zijlstra <peterz@infradead.org>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, Dave Watson <davejwatson@fb.com>, Paul Turner <pjt@google.com>, Rich Felker <dalias@libc.org>, linux-kernel <linux-kernel@vger.kernel.org>, linux-api <linux-api@vger.kernel.org> Subject: Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7) Date: Tue, 9 Apr 2019 10:13:03 -0400 [thread overview] Message-ID: <86030de9-862d-3ef5-d372-1695af3c8204@redhat.com> (raw) In-Reply-To: <871s2bp9f9.fsf@linux.ibm.com> On 4/9/19 9:58 AM, Tulio Magno Quites Machado Filho wrote: > Alan Modra <amodra@gmail.com> 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 speculative execution). > 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. -- Cheers, Carlos.
WARNING: multiple messages have this Message-ID (diff)
From: Carlos O'Donell <codonell@redhat.com> To: Tulio Magno Quites Machado Filho <tuliom@ascii.art.br>, Alan Modra <amodra@gmail.com>, Michael Ellerman <mpe@ellerman.id.au> Cc: Florian Weimer <fweimer@redhat.com>, Michael Meissner <meissner@linux.ibm.com>, Peter Bergner <bergner@vnet.ibm.com>, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Paul Burton <paul.burton@mips.com>, Will Deacon <will.deacon@arm.com>, Boqun Feng <boqun.feng@gmail.com>, Heiko Carstens <heiko.carstens@de.ibm.com>, Vasily Gorbik <gor@linux.ibm.com>, Martin Schwidefsky <schwidefsky@de.ibm.com>, Russell King <linux@armlinux.org.uk>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org>, carlos <carlos@redhat.com>, Joseph Myers <joseph@codesourcery.com>, Szabolcs Nagy <szabolcs.nagy@arm.com>, libc-alpha <libc-alpha@sourceware.org>, Thomas Gleixner <tglx@linutronix.de>, Ben Maurer <bmaurer@fb.com>Peter Subject: Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7) Date: Tue, 9 Apr 2019 10:13:03 -0400 [thread overview] Message-ID: <86030de9-862d-3ef5-d372-1695af3c8204@redhat.com> (raw) In-Reply-To: <871s2bp9f9.fsf@linux.ibm.com> On 4/9/19 9:58 AM, Tulio Magno Quites Machado Filho wrote: > Alan Modra <amodra@gmail.com> 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 speculative execution). > 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. -- Cheers, Carlos.
next prev parent reply other threads:[~2019-04-09 14:13 UTC|newest] Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <20190212194253.1951-1-mathieu.desnoyers@efficios.com> 2019-02-12 19:42 ` [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7) Mathieu Desnoyers 2019-03-22 20:09 ` Carlos O'Donell 2019-03-25 15:54 ` Mathieu Desnoyers 2019-03-27 9:16 ` Martin Schwidefsky 2019-03-27 9:16 ` Martin Schwidefsky 2019-03-27 20:01 ` Mathieu Desnoyers 2019-03-27 20:01 ` Mathieu Desnoyers 2019-03-27 20:38 ` Carlos O'Donell 2019-03-27 20:38 ` Carlos O'Donell 2019-03-28 7:49 ` Martin Schwidefsky 2019-03-28 7:49 ` Martin Schwidefsky 2019-03-28 15:42 ` Mathieu Desnoyers 2019-03-28 15:42 ` Mathieu Desnoyers 2019-04-02 6:02 ` Michael Ellerman 2019-04-02 7:08 ` Florian Weimer 2019-04-02 7:08 ` Florian Weimer 2019-04-04 20:32 ` Carlos O'Donell 2019-04-04 20:32 ` Carlos O'Donell 2019-04-05 9:16 ` Florian Weimer 2019-04-05 9:16 ` Florian Weimer 2019-04-05 15:40 ` Carlos O'Donell 2019-04-05 15:40 ` Carlos O'Donell 2019-04-08 19:20 ` Tulio Magno Quites Machado Filho 2019-04-08 19:20 ` Tulio Magno Quites Machado Filho 2019-04-08 21:45 ` Carlos O'Donell 2019-04-08 21:45 ` Carlos O'Donell 2019-04-09 4:23 ` Michael Ellerman 2019-04-09 4:23 ` Michael Ellerman 2019-04-09 9:29 ` Alan Modra 2019-04-09 9:29 ` Alan Modra 2019-04-09 13:58 ` Tulio Magno Quites Machado Filho 2019-04-09 14:13 ` Carlos O'Donell [this message] 2019-04-09 14:13 ` Carlos O'Donell 2019-04-09 15:45 ` Mathieu Desnoyers 2019-04-09 15:45 ` Mathieu Desnoyers 2019-04-18 15:31 ` Mathieu Desnoyers 2019-04-18 15:31 ` Mathieu Desnoyers 2019-04-09 16:33 ` Mathieu Desnoyers 2019-04-09 16:33 ` Mathieu Desnoyers 2019-04-04 20:15 ` Carlos O'Donell 2019-04-04 20:50 ` Carlos O'Donell 2019-04-04 21:41 ` Paul Burton 2019-04-04 21:41 ` Paul Burton 2019-04-09 16:40 ` Mathieu Desnoyers 2019-04-09 16:40 ` Mathieu Desnoyers 2019-04-18 18:58 ` Mathieu Desnoyers 2019-04-18 18:58 ` Mathieu Desnoyers 2019-04-24 15:05 ` Mathieu Desnoyers 2019-04-24 15:05 ` Mathieu Desnoyers 2019-04-24 23:13 ` Paul Burton 2019-04-24 23:13 ` Paul Burton 2019-04-25 0:41 ` Maciej W. Rozycki 2019-04-25 0:41 ` Maciej W. Rozycki 2019-02-12 19:42 ` [PATCH 2/4] glibc: sched_getcpu(): use rseq cpu_id TLS on Linux Mathieu Desnoyers 2019-03-22 20:13 ` Carlos O'Donell
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=86030de9-862d-3ef5-d372-1695af3c8204@redhat.com \ --to=codonell@redhat.com \ --cc=amodra@gmail.com \ --cc=benh@kernel.crashing.org \ --cc=bergner@vnet.ibm.com \ --cc=bmaurer@fb.com \ --cc=boqun.feng@gmail.com \ --cc=carlos@redhat.com \ --cc=dalias@libc.org \ --cc=davejwatson@fb.com \ --cc=fweimer@redhat.com \ --cc=gor@linux.ibm.com \ --cc=heiko.carstens@de.ibm.com \ --cc=joseph@codesourcery.com \ --cc=libc-alpha@sourceware.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=mathieu.desnoyers@efficios.com \ --cc=meissner@linux.ibm.com \ --cc=mpe@ellerman.id.au \ --cc=paul.burton@mips.com \ --cc=paulmck@linux.vnet.ibm.com \ --cc=paulus@samba.org \ --cc=peterz@infradead.org \ --cc=pjt@google.com \ --cc=schwidefsky@de.ibm.com \ --cc=szabolcs.nagy@arm.com \ --cc=tglx@linutronix.de \ --cc=tuliom@ascii.art.br \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.