From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Cox Subject: Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier Date: Thu, 4 Jan 2018 20:32:46 +0000 Message-ID: <20180104203246.5ff65328@alans-desktop> References: <20180103223827.39601-1-mark.rutland@arm.com> <151502463248.33513.5960736946233335087.stgit@dwillia2-desk3.amr.corp.intel.com> <20180104010754.22ca6a74@alans-desktop> <20180104014100.3786e686@alans-desktop> <20180104193936.GB10427@amd> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20180104193936.GB10427@amd> Sender: linux-kernel-owner@vger.kernel.org To: Pavel Machek Cc: Jiri Kosina , Linus Torvalds , Dan Williams , Linux Kernel Mailing List , Mark Rutland , linux-arch@vger.kernel.org, Peter Zijlstra , Greg KH , Thomas Gleixner , Elena Reshetova List-Id: linux-arch.vger.kernel.org > For kernel, we may be able to annonate "tainted" pointers. But then > there's quite a lot of code in userspace... What will need to be > modified? Just JITs? Setuid programs? You never go from one user process to another except via the kernel. We have no hardware scheduling going on. That means that if the kernel and/or CPU imposes the correct speculation barriers you can't attack anyone but yourself. Sandboxes and JITs are the critical components where the issue matters. That IMHO is also an argument for why once the basics are in place there is a good argument for a prctl and maybe cgroup support to run some groups of processes with different trust levels. For example there's not much point protecting a user process from root, or a process from another process that could use ptrace on it instead. > And we can get part of the performance back by adding more of > SMT... AFAICT. The current evidence is not because most workloads are not sufficiently parallelisable. Likewise doing the speculation in the compiler doesn't appear to have been the success people hoped for (IA64). Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from www.llwyncelyn.cymru ([82.70.14.225]:47256 "EHLO fuzix.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751829AbeADUdS (ORCPT ); Thu, 4 Jan 2018 15:33:18 -0500 Date: Thu, 4 Jan 2018 20:32:46 +0000 From: Alan Cox Subject: Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier Message-ID: <20180104203246.5ff65328@alans-desktop> In-Reply-To: <20180104193936.GB10427@amd> References: <20180103223827.39601-1-mark.rutland@arm.com> <151502463248.33513.5960736946233335087.stgit@dwillia2-desk3.amr.corp.intel.com> <20180104010754.22ca6a74@alans-desktop> <20180104014100.3786e686@alans-desktop> <20180104193936.GB10427@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Pavel Machek Cc: Jiri Kosina , Linus Torvalds , Dan Williams , Linux Kernel Mailing List , Mark Rutland , linux-arch@vger.kernel.org, Peter Zijlstra , Greg KH , Thomas Gleixner , Elena Reshetova Message-ID: <20180104203246.Ib02DMcpjl-3xQC5Wf_peAioSbf4gRoiq0gaIwCOSSc@z> > For kernel, we may be able to annonate "tainted" pointers. But then > there's quite a lot of code in userspace... What will need to be > modified? Just JITs? Setuid programs? You never go from one user process to another except via the kernel. We have no hardware scheduling going on. That means that if the kernel and/or CPU imposes the correct speculation barriers you can't attack anyone but yourself. Sandboxes and JITs are the critical components where the issue matters. That IMHO is also an argument for why once the basics are in place there is a good argument for a prctl and maybe cgroup support to run some groups of processes with different trust levels. For example there's not much point protecting a user process from root, or a process from another process that could use ptrace on it instead. > And we can get part of the performance back by adding more of > SMT... AFAICT. The current evidence is not because most workloads are not sufficiently parallelisable. Likewise doing the speculation in the compiler doesn't appear to have been the success people hoped for (IA64). Alan