Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
Message-ID: <7c0b0879-3448-43e4-8380-4708fc787113@default>
Date:   Thu, 25 Jan 2018 18:11:42 -0800 (PST)
From:   Liran Alon <liran.alon@oracle.com>
To:     <dave.hansen@intel.com>
Cc:     <labbott@redhat.com>, <luto@kernel.org>,
        <Janakarajan.Natarajan@amd.com>, <bp@suse.de>,
        <torvalds@linux-foundation.org>, <asit.k.mallick@intel.com>,
        <rkrcmar@redhat.com>, <karahmed@amazon.de>, <hpa@zytor.com>,
        <jun.nakajima@intel.com>, <mingo@redhat.com>, <x86@kernel.org>,
        <ashok.raj@intel.com>, <arjan.van.de.ven@intel.com>,
        <tim.c.chen@linux.intel.com>, <pbonzini@redhat.com>,
        <ak@linux.intel.com>, <linux-kernel@vger.kernel.org>,
        <dwmw2@infradead.org>, <peterz@infradead.org>,
        <tglx@linutronix.de>, <gregkh@linuxfoundation.org>,
        <mhiramat@kernel.org>, <arjan@linux.intel.com>,
        <thomas.lendacky@amd.com>, <dan.j.williams@intel.com>,
        <joro@8bytes.org>, <aarcange@redhat.com>, <kvm@vger.kernel.org>
Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict
 Indirect Branch Speculation
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


----- dave.hansen@intel.com wrote:

> 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.
>=20
> 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.
>=20
> You probably have a valid point about host->guest, though.

I see it differently.

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 unrel=
ated vulnerability to build a reliable exploit.

Security is built in layers.
The purpose of KASLR is to break the reliablity of an exploit which relies =
on vulnerability primitives such as: memory-corruption of a kernel-address,=
 hijack kernel control-flow to a kernel-address or even just read a kernel-=
address. In modern exploitation, it is common to chain multiple different v=
ulnerabilities in order to build a reliable exploit. Therefore, leaking a k=
ernel-address could be exactly the missing primitive to complete a vulnerab=
ility-chain of a reliable exploit.

I don't see a big difference between leaking a kernel-address from user-mod=
e vs. leaking a hypervisor-address from guest. They are both useful just as=
 a primitive which is part of an exploit chain.

One could argue though, that currently KASLR is fundementally broken and th=
erefore should not be considered a security boundary anymore. This argument=
 could be legit as there were some well-known techniques that could break K=
ASLR before KPTI patch-set was introduced (e.g. Timing memory accesses to k=
ernel-addresses and messure reliably by leveraging TSX). Another well-known=
 argument against KASLR is that it is a non-deterministic mitigation which =
some argue is not good enough. However, I think that if we decide KASLR is =
not a security boundary anymore, it should be made loud and clear.

In general, I think there are some info-leak vulnerabilities in our current=
 mitigation plan which doesn't seem to be addressed. I will be glad if we c=
ould address them clearly. These are all the open issues as I see them:

1) Because IBRS doesn't restrict low prediction-mode code from using BTB of=
 high prediction-mode code, It is possible to info-leak addresses from high=
 prediction-mode code to low prediciton-mode code.
This is the KASLR breakage discussed above. Again, could be ignored if we d=
iscard KASLR as a security boundary.

2) Both IBRS & retpoline don't prevent use of BHB of high prediction-mode c=
ode from being used by low prediction-mode code. Therefore, low prediction-=
mode code could deduce the conditional branches taken by high prediction-mo=
de code.

3) Similar leak to (1) exists from the fact that RSB entries of high predic=
tion-mode code could be leaked by low prediction-mode code which may reveal=
 kernel-addresses. Again, we could decide that this isn't a security bounda=
ry. An alternative to solve this could be to just stuff RSB from a fixed ad=
dress between prediction-mode transitions.

-Liran

P.S:
It seems to me that all these issues could be resolved completely at hardwa=
re in future CPUs if BTB/BHB/RSB entries were tagged with prediction-mode (=
or similar metadata). It will be nice if Intel/AMD could share if that is t=
he planned long-term solution instead of IBRS-all-the-time.