[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cac69284-e76f-6081-62db-adb4dc123045@linux.intel.com>
Date: Tue, 23 Jan 2018 16:47:36 -0800
From: Tim Chen <tim.c.chen@...ux.intel.com>
To: "Woodhouse, David" <dwmw@...zon.co.uk>,
Andi Kleen <ak@...ux.intel.com>,
Tom Lendacky <thomas.lendacky@....com>
Cc: Andy Lutomirski <luto@...capital.net>,
KarimAllah Ahmed <karahmed@...zon.de>,
linux-kernel@...r.kernel.org,
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>,
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>,
Peter Zijlstra <peterz@...radead.org>,
Radim Krčmář <rkrcmar@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>, kvm@...r.kernel.org,
x86@...nel.org, Arjan Van De Ven <arjan.van.de.ven@...el.com>
Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict
Indirect Branch Speculation
On 01/23/2018 03:14 PM, Woodhouse, David wrote:
> On Tue, 2018-01-23 at 14:49 -0800, Andi Kleen wrote:
>>> Not sure. Maybe to start, the answer might be to allow it to be set for
>>> the ultra-paranoid, but in general don't enable it by default. Having it
>>> enabled would be an alternative to someone deciding to disable SMT, since
>>> that would have even more of a performance impact.
>>
>> I agree. A reasonable strategy would be to only enable it for
>> processes that have dumpable disabled. This should be already set for
>> high value processes like GPG, and allows others to opt-in if
>> they need to.
>
> That seems to make sense, and I think was the solution we were
> approaching for IBPB on context switch too, right?
>
> Are we generally agreed on dumpable as the criterion for both of those?
>
It is a reasonable approach. Let a process who needs max security
opt in with disabled dumpable. It can have a flush with IBPB clear before
starting to run, and have STIBP set while running.
Tim
Powered by blists - more mailing lists