From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758304AbdJMN6c (ORCPT ); Fri, 13 Oct 2017 09:58:32 -0400 Received: from www.llwyncelyn.cymru ([82.70.14.225]:52076 "EHLO fuzix.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753466AbdJMN6a (ORCPT ); Fri, 13 Oct 2017 09:58:30 -0400 Date: Fri, 13 Oct 2017 14:57:10 +0100 From: Alan Cox To: Mathieu Desnoyers Cc: "Paul E. McKenney" , Boqun Feng , Peter Zijlstra , Paul Turner , Andrew Hunter , Andy Lutomirski , Dave Watson , Josh Triplett , Will Deacon , 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 , linux-api@vger.kernel.org Subject: Re: [RFC PATCH for 4.15 09/14] Provide cpu_opv system call Message-ID: <20171013145710.4430583f@alans-desktop> In-Reply-To: <20171012230326.19984-10-mathieu.desnoyers@efficios.com> References: <20171012230326.19984-1-mathieu.desnoyers@efficios.com> <20171012230326.19984-10-mathieu.desnoyers@efficios.com> Organization: Intel Corporation X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > A maximum limit of 16 operations per cpu_opv syscall invocation is > enforced, so user-space cannot generate a too long preempt-off critical > section. Except that all the operations could be going to mmapped I/O space and if I pick the right targets could take quite a long time to complete. It's still only 16 operations - But 160ms is a lot worse than 10ms. In fact with compare_iter I could make it much much worse still as I get 2 x TMP_BUFLEN x 16 x worst case latency in my attack. That's enough to screw up plenty of things. So it seems to me at minimum it needs to be restricted to genuine RAM user pages, and in fact would be far far simpler code as well if it were limited to a single page for a given invocation or if like futexes you had to specifically create a per_cpu_opv mapping. Alan From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Cox Subject: Re: [RFC PATCH for 4.15 09/14] Provide cpu_opv system call Date: Fri, 13 Oct 2017 14:57:10 +0100 Message-ID: <20171013145710.4430583f@alans-desktop> References: <20171012230326.19984-1-mathieu.desnoyers@efficios.com> <20171012230326.19984-10-mathieu.desnoyers@efficios.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20171012230326.19984-10-mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Mathieu Desnoyers Cc: "Paul E. McKenney" , Boqun Feng , Peter Zijlstra , Paul Turner , Andrew Hunter , Andy Lutomirski , Dave Watson , Josh Triplett , Will Deacon , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Thomas Gleixner , Andi Kleen , Chris Lameter , Ingo Molnar , "H. Peter Anvin" , Ben Maurer , Steven Rostedt , Linus Torvalds , Andrew Morton , Russell King , Catalin Marinas List-Id: linux-api@vger.kernel.org > A maximum limit of 16 operations per cpu_opv syscall invocation is > enforced, so user-space cannot generate a too long preempt-off critical > section. Except that all the operations could be going to mmapped I/O space and if I pick the right targets could take quite a long time to complete. It's still only 16 operations - But 160ms is a lot worse than 10ms. In fact with compare_iter I could make it much much worse still as I get 2 x TMP_BUFLEN x 16 x worst case latency in my attack. That's enough to screw up plenty of things. So it seems to me at minimum it needs to be restricted to genuine RAM user pages, and in fact would be far far simpler code as well if it were limited to a single page for a given invocation or if like futexes you had to specifically create a per_cpu_opv mapping. Alan