Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751284AbeAEEwT convert rfc822-to-8bit (ORCPT + 1 other); Thu, 4 Jan 2018 23:52:19 -0500 Received: from mail.kernel.org ([198.145.29.99]:55926 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751194AbeAEEwS (ORCPT ); Thu, 4 Jan 2018 23:52:18 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8FBE221A1A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org X-Google-Smtp-Source: ACJfBoup+qVJ/7xa8aPSWo6oJuocfY6ukuRxHxxj15tQh4ztMrdFQ61BbGCHNIwUb3nkjnj38DFUtLFXt+yh55aTy6s= MIME-Version: 1.0 In-Reply-To: <8e382c5a-1d8d-44e6-87f4-176305493a47@intel.com> References: <0c525c4c6c817e9c42c7ed583d86dc591a86efde.1515086770.git.tim.c.chen@linux.intel.com> <20180104223321.GD32035@hirez.programming.kicks-ass.net> <8e382c5a-1d8d-44e6-87f4-176305493a47@intel.com> From: Andy Lutomirski Date: Thu, 4 Jan 2018 20:51:56 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 3/7] x86/enter: Use IBRS on syscall and interrupts To: Dave Hansen Cc: Peter Zijlstra , Tim Chen , Thomas Gleixner , Andy Lutomirski , Linus Torvalds , Greg KH , Andrea Arcangeli , Andi Kleen , Arjan Van De Ven , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Thu, Jan 4, 2018 at 4:08 PM, Dave Hansen wrote: > On 01/04/2018 02:33 PM, Peter Zijlstra wrote: >> On Thu, Jan 04, 2018 at 09:56:44AM -0800, Tim Chen wrote: >>> Set IBRS upon kernel entrance via syscall and interrupts. Clear it >>> upon exit. >> >> So not only did we add a CR3 write, we're now adding an MSR write to the >> entry/exit paths. Please tell me that these are 'fast' MSRs? Given >> people are already reporting stupid numbers with just the existing >> PTI/CR3, what kind of pain are we going to get from adding this? > > This "dynamic IBRS" that does runtime switching will not be on by > default and will be patched around by alternatives unless someone > explicitly opts in. > > If you decide you want the additional protection that it provides, you > can take the performance hit. How much is that? We've been saying that > these new MSRs are roughly as expensive as the CR3 writes. How > expensive are those? Don't take my word for it, a few folks were > talking about it today: > > Google says[1]: "We see negligible impact on performance." > Amazon says[2]: "We don’t expect meaningful performance impact." > > I chopped a few qualifiers out of there, but I think that roughly > captures the sentiment. > > 1. > https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html > 2. > http://www.businessinsider.com/google-amazon-performance-hit-meltdown-spectre-fixes-overblown-2018-1 Do we need an arch_prctl() to enable IBRS for user mode?