[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9e771f85-ed55-6a94-ad57-b6b8f93a3413@citrix.com>
Date: Thu, 18 Jan 2018 23:35:36 +0000
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: Andy Lutomirski <luto@...nel.org>,
Andrea Arcangeli <aarcange@...hat.com>
Cc: Josh Poimboeuf <jpoimboe@...hat.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Dave Hansen <dave.hansen@...el.com>,
Peter Zijlstra <peterz@...radead.org>,
David Woodhouse <dwmw2@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Ashok Raj <ashok.raj@...el.com>,
Tim Chen <tim.c.chen@...ux.intel.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg KH <gregkh@...uxfoundation.org>,
Andi Kleen <ak@...ux.intel.com>,
Arjan Van De Ven <arjan.van.de.ven@...el.com>,
Dan Williams <dan.j.williams@...el.com>,
Jun Nakajima <jun.nakajima@...el.com>,
Asit Mallick <asit.k.mallick@...el.com>,
Jason Baron <jbaron@...mai.com>
Subject: Re: [PATCH 23/35] x86/speculation: Add basic speculation control code
On 18/01/2018 23:25, Andy Lutomirski wrote:
> On Thu, Jan 18, 2018 at 11:08 AM, Andrea Arcangeli <aarcange@...hat.com> wrote:
>> On Thu, Jan 18, 2018 at 12:24:31PM -0600, Josh Poimboeuf wrote:
>>> On Thu, Jan 18, 2018 at 06:12:36PM +0100, Paolo Bonzini wrote:
>>>> On 18/01/2018 18:08, Dave Hansen wrote:
>>>>> On 01/18/2018 08:37 AM, Josh Poimboeuf wrote:
>>>>>>> --- a/Documentation/admin-guide/kernel-parameters.txt
>>>>>>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>>>>>>> @@ -3932,6 +3932,7 @@
>>>>>>> retpoline - replace indirect branches
>>>>>>> retpoline,generic - google's original retpoline
>>>>>>> retpoline,amd - AMD-specific minimal thunk
>>>>>>> + ibrs - Intel: Indirect Branch Restricted Speculation
>>>>>> Are there plans to add spectre_v2=ibrs_always to prevent SMT-based
>>>>>> attacks?
>>>>> What does "ibrs_always" mean to you?
>>> Maybe ibrs_always isn't the best name. Basically we need an option to
>>> protect user-user attacks via SMT.
>>>
>>> It could be implemented with IBRS=1, or STIBP, or as part of the
>>> mythical IBRS_ATT.
>> User stibp or user ibrs would be different things, both would be valid
>> for different use cases, and the user stibp should perform better.
>>
>> Leaving ibrs on when returning from kernel to userland (or setting
>> ibrs if kernel used retpolines instead of ibrs) achieves stronger
>> semantics than just setting SPEC_CTRL with stibp when returning to
>> userland.
> I read the whitepaper that documented the new MSRs a couple days ago
> and I'm now completely unable to find it. If anyone could send the
> link, that would be great.
https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf
~Andrew
Powered by blists - more mailing lists