linux-kernel - Re: [PATCH v2 4/8] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC

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: <20180106214138.GL19213@char.us.oracle.com>
Date:   Sat, 6 Jan 2018 16:41:38 -0500
From:   Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:     "Van De Ven, Arjan" <arjan.van.de.ven@...el.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        Konrad Rzeszutek Wilk <konrad@...nel.org>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Andi Kleen <ak@...ux.intel.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 4/8] x86/spec_ctrl: Add sysctl knobs to enable/disable
 SPEC_CTRL feature

On Sat, Jan 06, 2018 at 09:34:01PM +0000, Van De Ven, Arjan wrote:
> > I agree. But this is what customers are told to inspect to see if they
> > are impacted. And if in the future versions this goes away or such - they
> > will freak out and cause needless escalations.
> 
> 
> it's a mistake though... retpoline is what people should be using ....
> ... and only in super exception cases should IBRS even be considered

Like on certain Skylake and Broadwell where using the retpoline won't suffice?

As you can imagine having an heuristic that will figure out if:
 - The CPU is doing the correct thing, retpoline or IBRS is not needed at all.
 - The CPU can do retpoline, use that instead.
 - The CPU is unsafe to do retpoline, use IBRS.
 - The CPU can do retpoline, but MSRS are faster (is that even the case?)
 - The CPU hasn't been updated, the retpolines are unsafe, the only solution is to buy a new CPU.

And have all of this nicely rolled out to customers in an 'sysfs' that will
tell the customers - yes your are safe. 

All I m saying is that the 'ibrs_enabled' is a bad name, it should be something else
altogether.