linux-kernel - Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180110124119.GG9706@redhat.com>
Date:   Wed, 10 Jan 2018 13:41:19 +0100
From:   Andrea Arcangeli <aarcange@...hat.com>
To:     David Woodhouse <dwmw2@...radead.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...uxfoundation.org>, x86@...nel.org,
        Borislav Petkov <bp@...en8.de>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Andy Lutomirski <luto@...nel.org>,
        Arjan Van De Ven <arjan.van.de.ven@...el.com>
Subject: Re: [patch RFC 5/5] x86/speculation: Add basic speculation control
 code

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