Date: Wed, 10 Jan 2018 13:41:19 +0100
From: Andrea Arcangeli <aarcange@redhat.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
        Dave Hansen <dave.hansen@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linuxfoundation.org>, x86@kernel.org,
        Borislav Petkov <bp@alien8.de>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Andi Kleen <ak@linux.intel.com>,
        Greg KH <gregkh@linuxfoundation.org>,
        Andy Lutomirski <luto@kernel.org>,
        Arjan Van De Ven <arjan.van.de.ven@intel.com>
Subject: Re: [patch RFC 5/5] x86/speculation: Add basic speculation control
 code
Message-ID: <20180110124119.GG9706@redhat.com>
References: <20180110011350.855878109@linutronix.de>
 <ce6c99be-b8ea-f789-ca7c-625c99b2a7a2@intel.com>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1515587384.22302.132.camel@infradead.org>
User-Agent: Mutt/1.9.2 (2017-12-15)
Sender: linux-kernel-owner@vger.kernel.org

On Wed, Jan 10, 2018 at 12:29:44PM +0000, David Woodhouse wrote:
> On Wed, 2018-01-10 at 13:17 +0100, Andrea Arcangeli wrote:
> > On Wed, Jan 10, 2018 at 12:09:34PM +0000, David Woodhouse wrote:
> > > That is not consistent with the documentation I've seen, which Intel
> > > have so far utterly failed to publish AFAICT.
> > >?
> > > "a near indirect jump/call/return may be affected by code in a less privileged
> > > prediction mode that executed AFTER IBRS mode was last written with a value of 1"
> > 
> > You must have misunderstood the context there, or the above text is
> > wrong to begin with.
> 
> That's a quote from the Intel documentation for the IBRS feature.
> Go read it, please.

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.

Frankly I found that documentation very confusing like the inversion
of IBRS enabled really meaning IBP speculation disabled like Ingo
pointed out.

It's clear all done in a rush but we've to live with it. After all the
electric current also really flows in the opposite direction of the
arrow..

> Andrea, what part of this whole fucking mess isn't entirely batshit
> insane to start with? :)

Absolutely :).

> I think you are confused with the future IBRS_ATT option which will
> exist on new hardware.?

No, the only difference is that such option will perform best.

This is why the current default ibrs_enabled 1 ibpb_enabled 1.

That future CPUID bit will simply make the kernel boot by default with
ibrs_enabled 2 ibpb_enabled 1 and it'll perform best as it won't have
to write to SPEC_CTRL in kernel entry kernel exit vmenter/vmexit like
it commonly has to do with ibrs_enabled 1.

The only difference is that ibrs_enabled 2 will perform best, while
currently ibrs_enabled 1 performs best.

> Right now, IBRS works as I described it because that's the best they
> could do with microcode.

It works as I described but instead of arguing about specs above,
Intel should clarify that IBRS can already be set 100% of the time, be
left alone and set always, with all CPUs with SPEC_CTRL, and it's the
most secure mode available and matches the IBRS patchset with
ibrs_enabled 2.

Hope this helps clarify and of course this is so complex it's
perfectly normal to misunderstand something, but I'm confident it's
not me who misunderstood because if I did, the whole ibrs_enabled 2
that was just posted would make zero sense, that is for current CPUs
and it's the most secure option available (not less secure as you
seem to think).

Thanks,
Andrea