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] [day] [month] [year] [list]

Message-ID: <199a5883-42c7-d25c-0756-c3d4dcdc63ff@intel.com>
Date:   Thu, 25 Jan 2018 14:20:49 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Liran Alon <liran.alon@...cle.com>, dwmw2@...radead.org
Cc:     labbott@...hat.com, luto@...nel.org, Janakarajan.Natarajan@....com,
        torvalds@...ux-foundation.org, bp@...e.de,
        asit.k.mallick@...el.com, rkrcmar@...hat.com, karahmed@...zon.de,
        hpa@...or.com, mingo@...hat.com, jun.nakajima@...el.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, kvm@...r.kernel.org,
        aarcange@...hat.com
Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict
 Indirect Branch Speculation

On 01/23/2018 03:13 AM, Liran Alon wrote:
> Therefore, breaking KASLR. In order to handle this, every exit from
> kernel-mode to user-mode should stuff RSB. In addition, this stuffing
> of RSB may need to be done from a fixed address to avoid leaking the
> address of the RSB stuffing itself.

With PTI alone in place, I don't see how userspace could do anything
with this information.  Even if userspace started to speculate to a
kernel address, there is nothing at the kernel address to execute: no
TLB entry, no PTE to load, nothing.

You probably have a valid point about host->guest, though.