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]

Date:   Wed, 10 Jan 2018 13:57:10 +0100
From:   Andrea Arcangeli <aarcange@...hat.com>
To:     Jiri Kosina <jikos@...nel.org>
Cc:     David Woodhouse <dwmw2@...radead.org>,
        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 01:47:22PM +0100, Jiri Kosina wrote:
> On Wed, 10 Jan 2018, Andrea Arcangeli wrote:
> 
> > 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.
> 
> Well, prediction mode is defined by "CPL3 vs CPL0-2" and "VMX root vs VMX 
> non-root", with obvious ordering of privileges.
> 
> So if IBRS is set, branch predictor will not allow the predicted target to 
> be influenced by code that executed in less privileged prediction mode 
> before value of '1' IBRS mode was last written to, and that's pretty much 
> it.

Which in current silicon IBP speculation is turned off always, and the
above specification really is to provide more finegrined semantics
for future silicon where it'll perform best to leave it always on and
it'll be still as secure as it is now despite the IBP speculation may
not always be turned off like it happens right now.

With all the prediction modes ordered right for the respective
guest/ring and CPUID will tell us when it's higher perf to enable
ibrs_enabled 2 ibpb_enabled 1 by default.

Again I see zero issues with leaving IBRS always on in current and
future silicon and I see absolutely zero problems in setting IBRS in
vmexit to prevent the whole guest mode to attack the kernel memory,
and in fact ibrs_enabled 2 will even more secure and it'll prevent the
gust mode userland even to attack the host qemu userland through
spectre variant#2.

As long as the "with obvious ordering of privileges" is maintained
when IBRS is not a total turn off of IBP speculation, everything works
as intended.