Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934649AbeAJNCN (ORCPT + 1 other); Wed, 10 Jan 2018 08:02:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60002 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932407AbeAJNCL (ORCPT ); Wed, 10 Jan 2018 08:02:11 -0500 Date: Wed, 10 Jan 2018 14:02:02 +0100 From: Andrea Arcangeli To: David Woodhouse Cc: Jiri Kosina , 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: <20180110130202.GI9706@redhat.com> References: <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> <1515588673.22302.139.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1515588673.22302.139.camel@infradead.org> 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 13:02:11 +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 12:51:13PM +0000, David Woodhouse wrote: > If it worked as Andrea suggests, then there would be absolutely no > point in the patches we've seen which add the IBRS-frobbing on syscall > entry and vmexit. This is perhaps what you're missing I think, there is a huge point: performance. ibrs_enabled 1 ibpb_enabled 1 is much faster than ibrs_enabled 2 ibpb_enabled 1. The current IBRS is disabling IBP, it can't do the "finegrined" thing that leaves IBP speculation enabled. Kernel is not a 100% C++ virtual template, so for kernel IBRS enabled is not as a big deal as userland with IBRS enabled. Once the new CPUid bit will be set it'll tell us IBRS is really restricting speculation in a finegrined way with all privilege levels ordered, so it simply tells is ibrs_enabled 2 ibpb_enabled 1 will be faster than ibrs_enabled 1 ibpb_enabled 1, so the only thing we've to do with the new CPUID bit you're talking about from the future, is to change the default to ibrs_enabled 2 and it'll perform even better with zero overhead in kernel entry points. We already optimized for the future silicon, we've only to add a tweak to detect cpuid and set the default ibrs_enabled to 2. > The "IBRS all the time" feature is something we get on *future* > hardware, not current hardware. No, for current hardware it's the most secure option available and required in fact if you want to fix guest userland attack on host userland with math certainty which can matter for some customer.