Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932272AbeAHKJQ (ORCPT + 1 other); Mon, 8 Jan 2018 05:09:16 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:39344 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932157AbeAHKJN (ORCPT ); Mon, 8 Jan 2018 05:09:13 -0500 Date: Mon, 8 Jan 2018 11:08:36 +0100 From: Peter Zijlstra To: Dan Williams Cc: "Eric W. Biederman" , Linux Kernel Mailing List , Mark Rutland , Alan Cox , Srinivas Pandruvada , Will Deacon , Solomon Peachy , "H. Peter Anvin" , Christian Lamparter , Elena Reshetova , linux-arch@vger.kernel.org, Andi Kleen , "James E.J. Bottomley" , linux-scsi , Jonathan Corbet , X86 ML , Ingo Molnar , Alexey Kuznetsov , Zhang Rui , "Linux-media@vger.kernel.org" , Arnd Bergmann , Jan Kara , Eduardo Valentin , Al Viro , qla2xxx-upstream@qlogic.com, Thomas Gleixner , Mauro Carvalho Chehab , Arjan van de Ven , Kalle Valo , Alan Cox , "Martin K. Petersen" , Hideaki YOSHIFUJI , Greg KH , linux-wireless@vger.kernel.org, Netdev , Linus Torvalds , "David S. Miller" , Laurent Pinchart Subject: Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution Message-ID: <20180108100836.GF3040@hirez.programming.kicks-ass.net> References: <151520099201.32271.4677179499894422956.stgit@dwillia2-desk3.amr.corp.intel.com> <87y3lbpvzp.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Fri, Jan 05, 2018 at 10:30:16PM -0800, Dan Williams wrote: > On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman wrote: > > In at least one place (mpls) you are patching a fast path. Compile out > > or don't load mpls by all means. But it is not acceptable to change the > > fast path without even considering performance. > > Performance matters greatly, but I need help to identify a workload > that is representative for this fast path to see what, if any, impact > is incurred. Even better is a review that says "nope, 'index' is not > subject to arbitrary userspace control at this point, drop the patch." I think we're focussing a little too much on pure userspace. That is, we should be saying under the attackers control. Inbound network packets could equally be under the attackers control. Sure, userspace is the most direct and highest bandwidth one, but I think we should treat all (kernel) external values with the same paranoia.