Re: [PATCH v3 3/5] x86/enter: Use IBRS on syscall and interrupts

[Tim Chen]

On 01/10/2018 10:28 AM, Peter Zijlstra wrote:
> On Wed, Jan 10, 2018 at 10:16:20AM -0800, Tim Chen wrote:
>> On 01/10/2018 02:04 AM, Peter Zijlstra wrote:
> 
>>> What this Changelog fails to address is _WHY_ we need this. What does
>>> this provide that retpoline does not.
>>>
>>
>> Ok. I mentioned that in the cover letter that IBRS is a maximum security
>> mode in the CPU itself to directly restrict all indirect branches to prevent SPECTRE v2.
>>
>> I'll also include such comments in the commit log here.
> 
> That still doesn't say anything useful. Why and where is it better than
> retpoline? Why would I ever want to use IBRS? Those are not questions
> that have clear answers here.
> 
> From what I can gather of the discussion earlier today is that pre SKL
> IBRS is no better than retpoline and a whole lot slower.
> 
> On SKL+ retpoline is mostly there, but has a few dinky holes in and it
> _might_ make sense to use IBRS.
> 
> But I feel it needs explaining what the exact holes are (pjt and dwmw2
> had a fair enumeration IIRC) such that people can judge the risk.
> 
> No wishy washy maybe nonsense, clear language.
> 

Retpoline depends on the compiler doing the right thing, finding all
instances of indirect jump/call and patching those places with
the retpoline construct to defend against spectre v2.

For IBRS, the cpu itself restricts all the indirect jumps/calls when
IBRS is set.  So this is inherently a more secure mode than the
retpoline approach.  It also helps people who don't have a gcc
that don't support retpoline.

Tim