Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752562AbeADSFJ (ORCPT + 1 other); Thu, 4 Jan 2018 13:05:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38702 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750924AbeADSFI (ORCPT ); Thu, 4 Jan 2018 13:05:08 -0500 Date: Thu, 4 Jan 2018 19:05:06 +0100 From: Andrea Arcangeli To: Paolo Bonzini Cc: Dave Hansen , Andrew Cooper , "Woodhouse, David" , "pavel@ucw.cz" , "tim.c.chen@linux.intel.com" , "linux-kernel@vger.kernel.org" , "torvalds@linux-foundation.org" , "tglx@linutronix.de" , "andi@firstfloor.org" , "gnomes@lxorguk.ukuu.org.uk" , "gregkh@linux-foundation.org" Subject: Re: Avoid speculative indirect calls in kernel Message-ID: <20180104180506.GI13348@redhat.com> References: <20180104114231.GB1702@amd> <1515066469.12987.112.camel@amazon.co.uk> <94b12025-b27c-04d2-8726-c07a3af6b265@redhat.com> <7a3584c6-0c00-d807-5130-13d1f4b34102@citrix.com> <20180104162541.GD13348@redhat.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) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 04 Jan 2018 18:05:08 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: Hello, On Thu, Jan 04, 2018 at 06:15:01PM +0100, Paolo Bonzini wrote: > On 04/01/2018 18:13, Dave Hansen wrote: > > On 01/04/2018 08:25 AM, Andrea Arcangeli wrote: > >> It's only where SPEC_CTRL is missing and only IBPB_SUPPORT is > >> available, that ibrs 0 ibpb 2 is the only option to fix variant#2 for > >> good. > > > > Could you help us decode what "ibrs 0 ibpb 2" means to you? > > IBRS 0 = disabled > IBRS 1 = only kernel sets IBRS=1 > IBRS 2 = indirect branch prediction fully disabled, or do the right > thing on future processors > > IBPB 0 = disabled > IBPB 1 = on context switch > IBPB 2 = on every kernel or hypervisor entry Yes. ibrs 0 ibpb 2 kernel entry and vmexit. ibpb 2 if set, is forcing ibrs to 0 (it's sharing the same branch in the kernel entry points and it wouldn't make sense anyway to enable ibrs with ibpb 2). ibrs 0 ibpb 2 is only ever activated if SPEC_CTRL is missing but IBPB_SUPPORT is present and it does the same as stuff_RSB, imagine it like a stuff_IBP where stuff_RSB is already called.