From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> To: Florian Weimer <fweimer@redhat.com> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, Boqun Feng <boqun.feng@gmail.com>, Peter Zijlstra <peterz@infradead.org>, Paul Turner <pjt@google.com>, Andrew Hunter <ahh@google.com>, Andy Lutomirski <luto@amacapital.net>, Dave Watson <davejwatson@fb.com>, Josh Triplett <josh@joshtriplett.org>, Will Deacon <will.deacon@arm.com>, linux-kernel <linux-kernel@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Andi Kleen <andi@firstfloor.org>, Chris Lameter <cl@linux.com>, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, Ben Maurer <bmaurer@fb.com>, rostedt <rostedt@goodmis.org>, Linus Torvalds <torvalds@linux-foundation.org>, Andrew Morton <akpm@linux-foundation.org>, Russell King <linux@arm.linux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, Michael Kerrisk <mtk.manpages@gmail.com>, Alexander Viro <viro@zeniv.linux.org.uk>, linux-api <linux-api@vger.kernel.org> Subject: Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call Date: Fri, 13 Oct 2017 13:40:16 +0000 (UTC) [thread overview] Message-ID: <695804241.40580.1507902016119.JavaMail.zimbra@efficios.com> (raw) In-Reply-To: <19edaac0-98d7-e7a0-aceb-b861a2befce4@redhat.com> ----- On Oct 13, 2017, at 8:50 AM, Florian Weimer fweimer@redhat.com wrote: > On 10/13/2017 01:03 AM, Mathieu Desnoyers wrote: >> Expose a new system call allowing each thread to register one userspace >> memory area to be used as an ABI between kernel and user-space for two >> purposes: user-space restartable sequences and quick access to read the >> current CPU number value from user-space. >> >> * Restartable sequences (per-cpu atomics) >> >> Restartables sequences allow user-space to perform update operations on >> per-cpu data without requiring heavy-weight atomic operations. >> >> The restartable critical sections (percpu atomics) work has been started >> by Paul Turner and Andrew Hunter. It lets the kernel handle restart of >> critical sections. [1] [2] The re-implementation proposed here brings a >> few simplifications to the ABI which facilitates porting to other >> architectures and speeds up the user-space fast path. This part: >> A locking-based >> fall-back, purely implemented in user-space, is proposed here to deal >> with debugger single-stepping. This fallback interacts with rseq_start() >> and rseq_finish(), which force retries in response to concurrent >> lock-based activity. should have been updated in this series to: A second system call, cpu_opv(), is proposed as fallback to deal with debugger single-stepping. cpu_opv() executes a sequence of operations on behalf of user-space with preemption disabled. > This functionality essentially relies on writable function pointers (or > pointers to data containing function pointers), right? Is there a way > to make this a less attractive target for exploit writers? The proposed ABI does not require to store any function pointer. For a given rseq_finish() critical section, pointers to specific instructions (within a function) are emitted at link-time into a struct rseq_cs: struct rseq_cs { RSEQ_FIELD_u32_u64(start_ip); RSEQ_FIELD_u32_u64(post_commit_ip); RSEQ_FIELD_u32_u64(abort_ip); uint32_t flags; } __attribute__((aligned(4 * sizeof(uint64_t)))); Then, at runtime, the fast-path stores the address of that struct rseq_cs into the TLS struct rseq "rseq_cs" field. So all we store at runtime is a pointer to data, not a pointer to functions. But you seem to hint that having a pointer to data containing pointers to code may still be making it easier for exploit writers. Can you elaborate on the scenario ? Thanks, Mathieu > > Thanks, > Florian -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> To: Florian Weimer <fweimer@redhat.com> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, Boqun Feng <boqun.feng@gmail.com>, Peter Zijlstra <peterz@infradead.org>, Paul Turner <pjt@google.com>, Andrew Hunter <ahh@google.com>, Andy Lutomirski <luto@amacapital.net>, Dave Watson <davejwatson@fb.com>, Josh Triplett <josh@joshtriplett.org>, Will Deacon <will.deacon@arm.com>, linux-kernel <linux-kernel@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Andi Kleen <andi@firstfloor.org>, Chris Lameter <cl@linux.com>, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, Ben Maurer <bmaurer@fb.com>, rostedt <rostedt@goodmis.org>, Linus Torvalds <torvalds@linux-foundation.org>, Andrew Morton <akpm@linux-foundation.org>, Russell King <linux@arm.linux.org.uk>, Catalin Marinas <catalin.> Subject: Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call Date: Fri, 13 Oct 2017 13:40:16 +0000 (UTC) [thread overview] Message-ID: <695804241.40580.1507902016119.JavaMail.zimbra@efficios.com> (raw) In-Reply-To: <19edaac0-98d7-e7a0-aceb-b861a2befce4@redhat.com> ----- On Oct 13, 2017, at 8:50 AM, Florian Weimer fweimer@redhat.com wrote: > On 10/13/2017 01:03 AM, Mathieu Desnoyers wrote: >> Expose a new system call allowing each thread to register one userspace >> memory area to be used as an ABI between kernel and user-space for two >> purposes: user-space restartable sequences and quick access to read the >> current CPU number value from user-space. >> >> * Restartable sequences (per-cpu atomics) >> >> Restartables sequences allow user-space to perform update operations on >> per-cpu data without requiring heavy-weight atomic operations. >> >> The restartable critical sections (percpu atomics) work has been started >> by Paul Turner and Andrew Hunter. It lets the kernel handle restart of >> critical sections. [1] [2] The re-implementation proposed here brings a >> few simplifications to the ABI which facilitates porting to other >> architectures and speeds up the user-space fast path. This part: >> A locking-based >> fall-back, purely implemented in user-space, is proposed here to deal >> with debugger single-stepping. This fallback interacts with rseq_start() >> and rseq_finish(), which force retries in response to concurrent >> lock-based activity. should have been updated in this series to: A second system call, cpu_opv(), is proposed as fallback to deal with debugger single-stepping. cpu_opv() executes a sequence of operations on behalf of user-space with preemption disabled. > This functionality essentially relies on writable function pointers (or > pointers to data containing function pointers), right? Is there a way > to make this a less attractive target for exploit writers? The proposed ABI does not require to store any function pointer. For a given rseq_finish() critical section, pointers to specific instructions (within a function) are emitted at link-time into a struct rseq_cs: struct rseq_cs { RSEQ_FIELD_u32_u64(start_ip); RSEQ_FIELD_u32_u64(post_commit_ip); RSEQ_FIELD_u32_u64(abort_ip); uint32_t flags; } __attribute__((aligned(4 * sizeof(uint64_t)))); Then, at runtime, the fast-path stores the address of that struct rseq_cs into the TLS struct rseq "rseq_cs" field. So all we store at runtime is a pointer to data, not a pointer to functions. But you seem to hint that having a pointer to data containing pointers to code may still be making it easier for exploit writers. Can you elaborate on the scenario ? Thanks, Mathieu > > Thanks, > Florian -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
next prev parent reply other threads:[~2017-10-13 13:38 UTC|newest] Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-10-12 23:03 [RFC PATCH v9 for 4.15 00/14] Restartable sequences and CPU op vector system calls Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call Mathieu Desnoyers 2017-10-13 0:36 ` Linus Torvalds 2017-10-13 0:36 ` Linus Torvalds 2017-10-13 9:35 ` Ben Maurer 2017-10-13 9:35 ` Ben Maurer 2017-10-13 18:30 ` Linus Torvalds 2017-10-13 18:30 ` Linus Torvalds 2017-10-13 20:54 ` Paul E. McKenney 2017-10-13 20:54 ` Paul E. McKenney 2017-10-13 21:05 ` Linus Torvalds 2017-10-13 21:05 ` Linus Torvalds 2017-10-13 21:21 ` Paul E. McKenney 2017-10-13 21:21 ` Paul E. McKenney 2017-10-13 21:36 ` Mathieu Desnoyers 2017-10-13 21:36 ` Mathieu Desnoyers 2017-10-16 16:04 ` Carlos O'Donell 2017-10-16 16:04 ` Carlos O'Donell 2017-10-16 16:46 ` Andi Kleen 2017-10-16 16:46 ` Andi Kleen 2017-10-16 22:17 ` Mathieu Desnoyers 2017-10-16 22:17 ` Mathieu Desnoyers 2017-10-17 16:19 ` Ben Maurer 2017-10-17 16:19 ` Ben Maurer 2017-10-17 16:33 ` Mathieu Desnoyers 2017-10-17 16:33 ` Mathieu Desnoyers 2017-10-17 16:41 ` Ben Maurer 2017-10-17 16:41 ` Ben Maurer 2017-10-17 17:48 ` Mathieu Desnoyers 2017-10-17 17:48 ` Mathieu Desnoyers 2017-10-18 6:22 ` Greg KH 2017-10-18 6:22 ` Greg KH 2017-10-18 16:28 ` Mathieu Desnoyers 2017-10-18 16:28 ` Mathieu Desnoyers 2017-10-14 3:01 ` Andi Kleen 2017-10-14 3:01 ` Andi Kleen 2017-10-14 4:05 ` Linus Torvalds 2017-10-14 4:05 ` Linus Torvalds 2017-10-14 11:37 ` Mathieu Desnoyers 2017-10-14 11:37 ` Mathieu Desnoyers 2017-10-13 12:50 ` Florian Weimer 2017-10-13 13:40 ` Mathieu Desnoyers [this message] 2017-10-13 13:40 ` Mathieu Desnoyers 2017-10-13 13:56 ` Florian Weimer 2017-10-13 13:56 ` Florian Weimer 2017-10-13 14:27 ` Mathieu Desnoyers 2017-10-13 14:27 ` Mathieu Desnoyers 2017-10-13 17:24 ` Andy Lutomirski 2017-10-13 17:24 ` Andy Lutomirski 2017-10-13 17:53 ` Florian Weimer 2017-10-13 17:53 ` Florian Weimer 2017-10-13 18:17 ` Andy Lutomirski 2017-10-13 18:17 ` Andy Lutomirski 2017-10-14 11:53 ` Mathieu Desnoyers 2017-10-14 11:53 ` Mathieu Desnoyers 2017-10-18 16:41 ` Ben Maurer 2017-10-18 18:11 ` Mathieu Desnoyers 2017-10-18 18:11 ` Mathieu Desnoyers 2017-10-19 11:35 ` Mathieu Desnoyers 2017-10-19 11:35 ` Mathieu Desnoyers 2017-10-19 17:01 ` Florian Weimer 2017-10-19 17:01 ` Florian Weimer 2017-10-23 17:30 ` Ben Maurer 2017-10-23 17:30 ` Ben Maurer 2017-10-23 20:44 ` Mathieu Desnoyers 2017-10-23 20:44 ` Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 02/14] tracing: instrument restartable sequences Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 03/14] Restartable sequences: ARM 32 architecture support Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 04/14] Restartable sequences: wire up ARM 32 system call Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 05/14] Restartable sequences: x86 32/64 architecture support Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 06/14] Restartable sequences: wire up x86 32/64 system call Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 07/14] Restartable sequences: powerpc architecture support Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 08/14] Restartable sequences: Wire up powerpc system call Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 09/14] Provide cpu_opv " Mathieu Desnoyers 2017-10-13 13:57 ` Alan Cox 2017-10-13 13:57 ` Alan Cox 2017-10-13 14:50 ` Mathieu Desnoyers 2017-10-13 14:50 ` Mathieu Desnoyers 2017-10-14 14:22 ` Mathieu Desnoyers 2017-10-14 14:22 ` Mathieu Desnoyers 2017-10-13 17:20 ` Andy Lutomirski 2017-10-13 17:20 ` Andy Lutomirski 2017-10-14 2:50 ` Andi Kleen 2017-10-14 2:50 ` Andi Kleen 2017-10-14 13:35 ` Mathieu Desnoyers 2017-10-14 13:35 ` Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 10/14] cpu_opv: Wire up x86 32/64 " Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 11/14] cpu_opv: Wire up powerpc " Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 12/14] cpu_opv: Wire up ARM32 " Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 13/14] cpu_opv: Implement selftests Mathieu Desnoyers 2017-10-12 23:03 ` [RFC PATCH for 4.15 14/14] Restartable sequences: Provide self-tests Mathieu Desnoyers 2017-10-16 2:51 ` Michael Ellerman 2017-10-16 2:51 ` Michael Ellerman 2017-10-16 14:23 ` Mathieu Desnoyers 2017-10-16 14:23 ` Mathieu Desnoyers 2017-10-17 10:38 ` Michael Ellerman 2017-10-17 10:38 ` Michael Ellerman 2017-10-17 13:50 ` Mathieu Desnoyers 2017-10-17 13:50 ` Mathieu Desnoyers 2017-10-16 18:50 ` Mathieu Desnoyers 2017-10-16 18:50 ` Mathieu Desnoyers 2017-10-17 10:36 ` Michael Ellerman 2017-10-17 10:36 ` Michael Ellerman 2017-10-17 13:50 ` Mathieu Desnoyers 2017-10-17 13:50 ` Mathieu Desnoyers 2017-10-18 5:45 ` Michael Ellerman 2017-10-18 5:45 ` Michael Ellerman 2017-10-16 3:00 ` Michael Ellerman 2017-10-16 3:00 ` Michael Ellerman 2017-10-16 3:48 ` Boqun Feng 2017-10-16 3:48 ` Boqun Feng 2017-10-16 11:48 ` Michael Ellerman 2017-10-16 11:48 ` Michael Ellerman
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=695804241.40580.1507902016119.JavaMail.zimbra@efficios.com \ --to=mathieu.desnoyers@efficios.com \ --cc=ahh@google.com \ --cc=akpm@linux-foundation.org \ --cc=andi@firstfloor.org \ --cc=bmaurer@fb.com \ --cc=boqun.feng@gmail.com \ --cc=catalin.marinas@arm.com \ --cc=cl@linux.com \ --cc=davejwatson@fb.com \ --cc=fweimer@redhat.com \ --cc=hpa@zytor.com \ --cc=josh@joshtriplett.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=luto@amacapital.net \ --cc=mingo@redhat.com \ --cc=mtk.manpages@gmail.com \ --cc=paulmck@linux.vnet.ibm.com \ --cc=peterz@infradead.org \ --cc=pjt@google.com \ --cc=rostedt@goodmis.org \ --cc=tglx@linutronix.de \ --cc=torvalds@linux-foundation.org \ --cc=viro@zeniv.linux.org.uk \ --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.