[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1516991212.30244.262.camel@infradead.org>
Date: Fri, 26 Jan 2018 18:26:52 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Arjan van de Ven <arjan@...ux.intel.com>,
Andi Kleen <ak@...ux.intel.com>,
Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Dave Hansen <dave.hansen@...el.com>,
Liran Alon <liran.alon@...cle.com>,
Laura Abbott <labbott@...hat.com>,
Andrew Lutomirski <luto@...nel.org>,
Janakarajan Natarajan <Janakarajan.Natarajan@....com>,
Borislav Petkov <bp@...e.de>,
"Mallick, Asit K" <asit.k.mallick@...el.com>,
Radim Krčmář <rkrcmar@...hat.com>,
KarimAllah Ahmed <karahmed@...zon.de>,
Peter Anvin <hpa@...or.com>,
Jun Nakajima <jun.nakajima@...el.com>,
Ingo Molnar <mingo@...hat.com>,
the arch/x86 maintainers <x86@...nel.org>,
Ashok Raj <ashok.raj@...el.com>,
"Van De Ven, Arjan" <arjan.van.de.ven@...el.com>,
Tim Chen <tim.c.chen@...ux.intel.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Tom Lendacky <thomas.lendacky@....com>,
Dan Williams <dan.j.williams@...el.com>,
Joerg Roedel <joro@...tes.org>,
Andrea Arcangeli <aarcange@...hat.com>,
KVM list <kvm@...r.kernel.org>
Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict
Indirect Branch Speculation
On Fri, 2018-01-26 at 10:12 -0800, Arjan van de Ven wrote:
> On 1/26/2018 10:11 AM, David Woodhouse wrote:
> >
> > I am *actively* ignoring Skylake right now. This is about per-SKL
> > userspace even with SMEP, because we think Intel's document lies to us.
>
> if you think we lie to you then I think we're done with the conversation?
>
> Please tell us then what you deploy in AWS for your customers ?
>
> or show us research that shows we lied to you?
As you know well, I mean "we think Intel's document is not correct".
The evidence which made us suspect that is fairly clear in the last few
emails in this thread — it's about the BTB/RSB only having the low bits
of the target, which would mean that userspace *can* put malicious
targets into the RSB, regardless of SMEP.
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)
Powered by blists - more mailing lists