linux-kernel - Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1516957886.30244.161.camel@infradead.org>
Date:   Fri, 26 Jan 2018 09:11:26 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     Dave Hansen <dave.hansen@...el.com>,
        Liran Alon <liran.alon@...cle.com>
Cc:     labbott@...hat.com, luto@...nel.org, Janakarajan.Natarajan@....com,
        bp@...e.de, torvalds@...ux-foundation.org,
        asit.k.mallick@...el.com, rkrcmar@...hat.com, karahmed@...zon.de,
        hpa@...or.com, jun.nakajima@...el.com, mingo@...hat.com,
        x86@...nel.org, ashok.raj@...el.com, arjan.van.de.ven@...el.com,
        tim.c.chen@...ux.intel.com, pbonzini@...hat.com,
        ak@...ux.intel.com, linux-kernel@...r.kernel.org,
        peterz@...radead.org, tglx@...utronix.de,
        gregkh@...uxfoundation.org, mhiramat@...nel.org,
        arjan@...ux.intel.com, thomas.lendacky@....com,
        dan.j.williams@...el.com, joro@...tes.org, aarcange@...hat.com,
        kvm@...r.kernel.org
Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict
 Indirect Branch Speculation

On Thu, 2018-01-25 at 18:23 -0800, Dave Hansen wrote:
> On 01/25/2018 06:11 PM, Liran Alon wrote:
> > 
> > It is true that attacker cannot speculate to a kernel-address, but it
> > doesn't mean it cannot use the leaked kernel-address together with
> > another unrelated vulnerability to build a reliable exploit.
>
> The address doesn't leak if you can't execute there.  It's the same
> reason that we don't worry about speculation to user addresses from the
> kernel when SMEP is in play.

If both tags and target in the BTB are only 31 bits, then surely a
user-learned prediction of a branch from

  0x01234567 → 0x07654321

would be equivalent to a kernel-mode branch from

 0xffffffff81234567 → 0xffffffff87654321

... and interpreted in kernel mode as the latter? So I'm not sure why
SMEP saves us there?

Likewise if the RSB only stores the low 31 bits of the target, SMEP
isn't much help there either.

Do we need to look again at the fact that we've disabled the RSB-
stuffing for SMEP?
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)