search for: _retpoline_push

Displaying 4 results from an estimated 4 matches for "_retpoline_push".

2018 Feb 09
3
retpoline mitigation and 6.0
...agree it looks like a bug. It was too much to hope that later passes weren't going to mess with the PUSH instruction. :( While I was trying to reproduce your problem, I think I found another one that looks like this: $ clang -S -O2 -m32 -mregparm=3 -mretpoline spill_across_rp.cpp -o - | grep _retpoline_push -B2 ... movl %eax, 8(%esp) # 4-byte Spill ... pushl %edi movl 8(%esp), %edi # 4-byte Reload calll __llvm_retpoline_push That's obviously broken, it doesn't account for the SP adjustment in the push. It's weird, because it...
2018 Feb 19
0
retpoline mitigation and 6.0
...> much to hope that later passes weren't going to mess with the PUSH > instruction. :( > > While I was trying to reproduce your problem, I think I found another one > that looks like this: > > $ clang -S -O2 -m32 -mregparm=3 -mretpoline spill_across_rp.cpp -o - | grep > _retpoline_push -B2 > ... > movl %eax, 8(%esp) # 4-byte Spill > ... > pushl %edi > movl 8(%esp), %edi # 4-byte Reload > calll __llvm_retpoline_push > > That's obviously broken, it doesn't account for the SP adjustment in...
2018 Feb 09
0
retpoline mitigation and 6.0
On Fri, 2018-02-09 at 11:24 -0800, Reid Kleckner wrote: > I haven't read the all the emails in full detail, but it seems pretty > clear that  __x86_indirect_thunk and __llvm_retpoline_push do not do > the same things. It sounds like __llvm_retpoline_push is equivalent > to __x86_indirect_thunk except first it swaps the two words on the > top of the stack. > > I arranged it this way because the x86 call instruction puts the > intended return address on the top of th...
2018 Feb 09
3
retpoline mitigation and 6.0
I haven't read the all the emails in full detail, but it seems pretty clear that __x86_indirect_thunk and __llvm_retpoline_push do not do the same things. It sounds like __llvm_retpoline_push is equivalent to __x86_indirect_thunk except first it swaps the two words on the top of the stack. I arranged it this way because the x86 call instruction puts the intended return address on the top of the stack, and there's no ea...