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: <20180110121755.GD9706@redhat.com>
Date:   Wed, 10 Jan 2018 13:17:55 +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: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.

> The kernel is only protected from branch targets set in userspace
> *BEFORE* the IBRS mode was last set to 1. If you set it to 1, then
> leave it like that while you run userspace and then kernel code again,
> you are not protected.

I'm sure you've got it wrong, that would be crazy if it would be the
case.

Even from an implementation standpoint IBRS just means stop
speculating through branch prediction, there's no way they can add
this separation between ring 0 and ring 3 when it didn't exist to
begin with.

RSB had it with SMEP and in fact there's no need to do stuff_RSB with
SMEP enabled in cr4 and we alternative it out in kernel entry on host
and guest, but we still have to do that in vmexit.

IBP/BTB had nothing like, which is why user ring 3 can attack host
ring 0.

It will have it and also separating guest from host but in the future.

Plus IBRS can be set at will by guest mode, if guest kernel is
malicious it will let guest userland run with IBRS on. You can't trust
the guest kernel to begin with. So it would make IBRS totally useless
for KVM to set in vmexit if you were right about that.

In any case, we've a ibrs_enabled 0 ibpb_enabled 2 that would achieve
full security if you were right, but I think you got it all wrong
about IBRS and rings.

Second: IBRS means Indirect Branch Restricted Speculation, the
speculation through branch prediction is restricted while it's
set. It's inconceivable that they add ring knowledge to a part that is
couldn't be helped by SMEP in the first place that had at least some
ring separation when enabled.