[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180121112224.GH2269@hirez.programming.kicks-ass.net>
Date: Sun, 21 Jan 2018 12:22:24 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: KarimAllah Ahmed <karahmed@...zon.de>
Cc: linux-kernel@...r.kernel.org, Andi Kleen <ak@...ux.intel.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Andy Lutomirski <luto@...nel.org>,
Arjan van de Ven <arjan@...ux.intel.com>,
Ashok Raj <ashok.raj@...el.com>,
Asit Mallick <asit.k.mallick@...el.com>,
Borislav Petkov <bp@...e.de>,
Dan Williams <dan.j.williams@...el.com>,
Dave Hansen <dave.hansen@...el.com>,
David Woodhouse <dwmw@...zon.co.uk>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"H . Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
Janakarajan Natarajan <Janakarajan.Natarajan@....com>,
Joerg Roedel <joro@...tes.org>,
Jun Nakajima <jun.nakajima@...el.com>,
Laura Abbott <labbott@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Tim Chen <tim.c.chen@...ux.intel.com>,
Tom Lendacky <thomas.lendacky@....com>, kvm@...r.kernel.org,
x86@...nel.org
Subject: Re: [RFC 04/10] x86/mm: Only flush indirect branches when switching
into non dumpable process
On Sat, Jan 20, 2018 at 08:22:55PM +0100, KarimAllah Ahmed wrote:
> From: Tim Chen <tim.c.chen@...ux.intel.com>
>
> Flush indirect branches when switching into a process that marked
> itself non dumpable. This protects high value processes like gpg
> better, without having too high performance overhead.
So if I understand it right, this is only needed if the 'other'
executable itself is susceptible to spectre. If say someone audited gpg
for spectre-v1 and build it with retpoline, it would be safe to not
issue the IBPB, right?
So would it make sense to provide an ELF flag / personality thing such
that userspace can indicate its spectre-safe?
I realize that this is all future work, because so far auditing for v1
is a lot of pain (we need better tools), but would it be something that
makes sense in the longer term?
Powered by blists - more mailing lists