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
