Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934485AbeAJM5N (ORCPT + 1 other); Wed, 10 Jan 2018 07:57:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56536 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933931AbeAJM5M (ORCPT ); Wed, 10 Jan 2018 07:57:12 -0500 Date: Wed, 10 Jan 2018 13:57:10 +0100 From: Andrea Arcangeli To: Jiri Kosina Cc: David Woodhouse , Peter Zijlstra , Dave Hansen , Thomas Gleixner , LKML , Linus Torvalds , x86@kernel.org, Borislav Petkov , Tim Chen , Andi Kleen , Greg KH , Andy Lutomirski , Arjan Van De Ven Subject: Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code Message-ID: <20180110125710.GH9706@redhat.com> References: <20180110092234.GY29822@worktop.programming.kicks-ass.net> <1515576479.22302.81.camel@infradead.org> <20180110115419.GA9706@redhat.com> <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> 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.28]); Wed, 10 Jan 2018 12:57:12 +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:47:22PM +0100, Jiri Kosina wrote: > On Wed, 10 Jan 2018, Andrea Arcangeli wrote: > > > Perhaps the confusing come from "less privileged prediction mode" and > > you thought that meant "less privileged ring mode". It says "predction > > mode" not ring 3. > > Well, prediction mode is defined by "CPL3 vs CPL0-2" and "VMX root vs VMX > non-root", with obvious ordering of privileges. > > So if IBRS is set, branch predictor will not allow the predicted target to > be influenced by code that executed in less privileged prediction mode > before value of '1' IBRS mode was last written to, and that's pretty much > it. Which in current silicon IBP speculation is turned off always, and the above specification really is to provide more finegrined semantics for future silicon where it'll perform best to leave it always on and it'll be still as secure as it is now despite the IBP speculation may not always be turned off like it happens right now. With all the prediction modes ordered right for the respective guest/ring and CPUID will tell us when it's higher perf to enable ibrs_enabled 2 ibpb_enabled 1 by default. Again I see zero issues with leaving IBRS always on in current and future silicon and I see absolutely zero problems in setting IBRS in vmexit to prevent the whole guest mode to attack the kernel memory, and in fact ibrs_enabled 2 will even more secure and it'll prevent the gust mode userland even to attack the host qemu userland through spectre variant#2. As long as the "with obvious ordering of privileges" is maintained when IBRS is not a total turn off of IBP speculation, everything works as intended.