Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754638AbeALJ60 (ORCPT + 1 other); Fri, 12 Jan 2018 04:58:26 -0500 Received: from merlin.infradead.org ([205.233.59.134]:47788 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754350AbeALJ6Y (ORCPT ); Fri, 12 Jan 2018 04:58:24 -0500 Date: Fri, 12 Jan 2018 10:58:11 +0100 From: Peter Zijlstra To: David Woodhouse Cc: Ashok Raj , linux-kernel@vger.kernel.org, Thomas Gleixner , Tim Chen , Andy Lutomirski , Linus Torvalds , Greg KH , Paolo Bonzini , Dave Hansen , Andrea Arcangeli , Andi Kleen , Arjan Van De Ven , Dan Williams , Jun Nakajima , Asit Mallick Subject: Re: [PATCH 4/5] x86/svm: Direct access to MSR_IA32_SPEC_CTRL Message-ID: <20180112095811.GQ3040@hirez.programming.kicks-ass.net> References: <1515720739-43819-1-git-send-email-ashok.raj@intel.com> <1515720739-43819-5-git-send-email-ashok.raj@intel.com> <1515741833.22302.408.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1515741833.22302.408.camel@infradead.org> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Fri, Jan 12, 2018 at 07:23:53AM +0000, David Woodhouse wrote: > On Thu, 2018-01-11 at 17:32 -0800, Ashok Raj wrote: > > > > @@ -4910,6 +4935,14 @@ static void svm_vcpu_run(struct kvm_vcpu > > *vcpu) > > ? > > ????????clgi(); > > ? > > +???????if (boot_cpu_has(X86_FEATURE_SPEC_CTRL)) { > > +???????????????/* > > +??????????????? * FIXME: lockdep_assert_irqs_disabled(); > > +??????????????? */ > > +???????????????WARN_ON_ONCE(!irqs_disabled()); > > +???????????????spec_ctrl_set(svm->spec_ctrl); > > +???????} > > + > > ????????local_irq_enable(); > > ? > > Same comments here as we've had previously. If you do this without an > 'else lfence' then you need a comment showing that you've proved it's > safe. > > And I don't think even using static_cpu_has() is good enough. We don't > already "rely" on that for anything but optimisations, AFAICT. Turning > a missed GCC optimisation into a security hole is not a good idea. I disagree, and if you worry about that, we should write a testcase. But we rely on GCC for correct code generation in lots of places, this isn't different.