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
Date: Thu, 25 Jan 2018 18:11:42 -0800 (PST) [thread overview]
Message-ID: <7c0b0879-3448-43e4-8380-4708fc787113@default> (raw)
----- 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.
>
> 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.
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 unrelated 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 vulnerabilities in order to build a reliable exploit. Therefore, leaking a kernel-address could be exactly the missing primitive to complete a vulnerability-chain of a reliable exploit.
I don't see a big difference between leaking a kernel-address from user-mode 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 therefore should not be considered a security boundary anymore. This argument could be legit as there were some well-known techniques that could break KASLR before KPTI patch-set was introduced (e.g. Timing memory accesses to kernel-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 could 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 discard KASLR as a security boundary.
2) Both IBRS & retpoline don't prevent use of BHB of high prediction-mode code from being used by low prediction-mode code. Therefore, low prediction-mode code could deduce the conditional branches taken by high prediction-mode code.
3) Similar leak to (1) exists from the fact that RSB entries of high prediction-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 boundary. An alternative to solve this could be to just stuff RSB from a fixed address between prediction-mode transitions.
-Liran
P.S:
It seems to me that all these issues could be resolved completely at hardware 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 the planned long-term solution instead of IBRS-all-the-time.
next reply other threads:[~2018-01-26 2:11 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-26 2:11 Liran Alon [this message]
2018-01-26 2:23 ` [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation Dave Hansen
2018-01-26 9:11 ` David Woodhouse
2018-01-26 17:19 ` Linus Torvalds
2018-01-26 17:27 ` Borislav Petkov
2018-01-26 17:29 ` David Woodhouse
2018-01-26 17:31 ` David Woodhouse
2018-01-26 17:59 ` Andi Kleen
2018-01-26 18:11 ` David Woodhouse
2018-01-26 18:12 ` Arjan van de Ven
2018-01-26 18:26 ` David Woodhouse
2018-01-26 18:28 ` Van De Ven, Arjan
2018-01-26 18:43 ` David Woodhouse
2018-01-26 18:44 ` Van De Ven, Arjan
2018-01-26 18:53 ` David Woodhouse
2018-01-26 19:02 ` Konrad Rzeszutek Wilk
2018-01-26 19:11 ` Hansen, Dave
2018-01-27 13:42 ` Konrad Rzeszutek Wilk
2018-01-27 15:55 ` Dave Hansen
2018-01-26 19:11 ` David Woodhouse
2018-01-26 8:46 ` David Woodhouse
-- strict thread matches above, loose matches on Subject: below --
2018-01-26 2:50 Liran Alon
2018-01-26 2:55 ` Van De Ven, Arjan
2018-01-23 11:13 Liran Alon
2018-01-25 22:20 ` Dave Hansen
2018-01-22 22:15 Luke Kenneth Casson Leighton
2018-01-20 19:22 [RFC 00/10] Speculation Control feature support KarimAllah Ahmed
2018-01-20 19:23 ` [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation KarimAllah Ahmed
2018-01-21 19:14 ` Andy Lutomirski
2018-01-23 16:12 ` Tom Lendacky
2018-01-23 16:20 ` Woodhouse, David
2018-01-23 22:37 ` Tom Lendacky
2018-01-23 22:49 ` Andi Kleen
2018-01-23 23:14 ` Woodhouse, David
2018-01-23 23:22 ` Andi Kleen
2018-01-24 0:47 ` Tim Chen
2018-01-24 1:00 ` Andy Lutomirski
2018-01-24 1:22 ` David Woodhouse
2018-01-24 1:59 ` Van De Ven, Arjan
2018-01-24 3:25 ` Andy Lutomirski
2018-01-21 19:34 ` Linus Torvalds
2018-01-21 20:28 ` David Woodhouse
2018-01-21 21:35 ` Linus Torvalds
2018-01-21 22:00 ` David Woodhouse
2018-01-21 22:27 ` Linus Torvalds
2018-01-22 16:27 ` David Woodhouse
2018-01-23 7:29 ` Ingo Molnar
2018-01-23 7:53 ` Ingo Molnar
2018-01-23 9:27 ` Ingo Molnar
2018-01-23 9:37 ` David Woodhouse
2018-01-23 15:01 ` Dave Hansen
2018-01-23 9:30 ` David Woodhouse
2018-01-23 10:15 ` Ingo Molnar
2018-01-23 10:27 ` David Woodhouse
2018-01-23 10:44 ` Ingo Molnar
2018-01-23 10:57 ` David Woodhouse
2018-01-23 10:23 ` Ingo Molnar
2018-01-23 10:35 ` David Woodhouse
2018-02-04 18:43 ` Thomas Gleixner
2018-02-04 20:22 ` David Woodhouse
2018-02-06 9:14 ` David Woodhouse
2018-01-25 16:19 ` Mason
2018-01-25 17:16 ` Greg Kroah-Hartman
2018-01-29 11:59 ` Mason
2018-01-24 0:05 ` Andi Kleen
2018-01-23 20:16 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7c0b0879-3448-43e4-8380-4708fc787113@default \
--to=liran.alon@oracle.com \
--cc=Janakarajan.Natarajan@amd.com \
--cc=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=arjan.van.de.ven@intel.com \
--cc=arjan@linux.intel.com \
--cc=ashok.raj@intel.com \
--cc=asit.k.mallick@intel.com \
--cc=bp@suse.de \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=dwmw2@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=joro@8bytes.org \
--cc=jun.nakajima@intel.com \
--cc=karahmed@amazon.de \
--cc=kvm@vger.kernel.org \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rkrcmar@redhat.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tim.c.chen@linux.intel.com \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).