Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965121AbeAJNwX (ORCPT + 1 other); Wed, 10 Jan 2018 08:52:23 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54568 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932857AbeAJNwW (ORCPT ); Wed, 10 Jan 2018 08:52:22 -0500 Date: Wed, 10 Jan 2018 14:52:19 +0100 From: Andrea Arcangeli To: "Van De Ven, Arjan" Cc: David Woodhouse , Jiri Kosina , "Mallick, Asit K" , Peter Zijlstra , "Hansen, Dave" , Thomas Gleixner , LKML , Linus Torvalds , "x86@kernel.org" , Borislav Petkov , Tim Chen , Andi Kleen , Greg KH , Andy Lutomirski Subject: Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code Message-ID: <20180110135219.GC9417@redhat.com> References: <1515585534.22302.122.camel@infradead.org> <20180110120158.GB9706@redhat.com> <1515586174.22302.126.camel@infradead.org> <20180110121755.GD9706@redhat.com> <1515587384.22302.132.camel@infradead.org> <20180110124119.GG9706@redhat.com> <20180110125710.GH9706@redhat.com> <1515589641.22302.145.camel@infradead.org> <0575AF4FD06DD142AD198903C74E1CC87A572336@ORSMSX103.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0575AF4FD06DD142AD198903C74E1CC87A572336@ORSMSX103.amr.corp.intel.com> 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.32]); Wed, 10 Jan 2018 13:52:22 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Wed, Jan 10, 2018 at 01:45:52PM +0000, Van De Ven, Arjan wrote: > > > Andrea, what you're saying is directly contradicting what I've heard > > from Intel. > > > > The documentation already distinguishes between IBRS on current > > hardware, and IBRS_ATT on future hardware. If it was the case that IBRS > > on current hardware is a set-and-forget option and completely disables > > branch prediction, then they would say that. Rather than explicitly > > saying the *opposite*, specifically for the case of current hardware, > > as they do. > > > > Rather than continuing to debate it, perhaps it's best just to wake for > > the US to wake up, and Intel to give a definitive answer. > > On current hardware, you cannot just set IBRS always. ibrs_enabled 1: sets IBRS at vmexit and at kernel entry. clears IBRS at kernel exit (return to usermode) restores whatever IBRS value the guest was using at vmenter ibrs_enabled 2: sets IBRS always in host sets IBRS if it wasn't already set by the guest in vmexit restores whatever IBRS valeu the guest was using at vmenter This matches the semantics described here by Tim patchset on lkml: https://marc.info/?l=linux-kernel&m=151520606320646 If you what you say is correct, then you should discuss with Tim what "echo 2 > /sys/kernel/debug/x86/ibrs_enabled will turn on IBRS in both userspace and kernel" is doing or is supposed to achieve. > (In practice, on some you might get lucky if you try. Intel does not guarantee it. Intel does not test it. The model is to write the msr on privilege change, e.g. ring transition) ibrs_enabled 1 is the default always with SPEC_CTRL in cpuid. The question is ibrs_enabled 2 optional mode but what is implemented matches the semantics of the above patchset in link from Tim so again you should talk with Tim and adjourn on the status of leaving IBRS always on with current silicon. I can tell in practice it works as I described in all microcodes I tested. Thanks, Andrea