From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Weimer Subject: Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call Date: Fri, 13 Oct 2017 14:50:13 +0200 Message-ID: <19edaac0-98d7-e7a0-aceb-b861a2befce4@redhat.com> References: <20171012230326.19984-1-mathieu.desnoyers@efficios.com> <20171012230326.19984-2-mathieu.desnoyers@efficios.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20171012230326.19984-2-mathieu.desnoyers@efficios.com> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Mathieu Desnoyers , "Paul E. McKenney" , Boqun Feng , Peter Zijlstra , Paul Turner , Andrew Hunter , Andy Lutomirski , Dave Watson , Josh Triplett , Will Deacon Cc: linux-kernel@vger.kernel.org, Thomas Gleixner , Andi Kleen , Chris Lameter , Ingo Molnar , "H. Peter Anvin" , Ben Maurer , Steven Rostedt , Linus Torvalds , Andrew Morton , Russell King , Catalin Marinas , Michael Kerrisk , Alexander Viro , linux-api@vger.kernel.org List-Id: linux-api@vger.kernel.org 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. 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. 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? Thanks, Florian