[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50c5d627-8975-184b-b50f-4cc02c5816c5@intel.com>
Date: Thu, 25 Jan 2018 18:23:51 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: 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,
dwmw2@...radead.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 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.
Powered by blists - more mailing lists