On Fri, Jan 5, 2018 at 3:32 PM, Woodhouse, David <d...@amazon.co.uk> wrote: > On Fri, 2018-01-05 at 09:28 -0800, Linus Torvalds wrote: >> >> Yes, I would suggest against expecting altinstructions to have >> relocation information. They are generated in a different place, so.. >> >> That said, I honestly like the inline version (the one that is in the >> google paper first) of the retpoline more than the out-of-line one. >> And that one shouldn't have any relocation issues, because all the >> offsets are relative. > > Note that the *only* issue with the relocation is that it pushes me to > use X86_FEATURE_NO_RETPOLINE for my feature instead of > X86_FEATURE_RETPOLINE as might be natural. And actually there's a > motivation to do that anyway, because of the way three-way alternatives > interact. > > With the existing negative flag I can do > > ALTERNATIVE_2(retpoline, K8: lfence+jmp; NO_RETPOLINE: jmp) > > But if I invert it, I think I need two feature flags to get the same > functionality — X86_FEATURE_RETPOLINE and X86_FEATURE_RETPOLINE_AMD: > > ALTERNATIVE_2(jmp, RETPOLINE: retpoline, RETPOLINE_AMD: lfence+jmp)
Another way to do it is with two consecutive alternatives: ALTERNATIVE(NOP, K8: lfence) ALTERNATIVE(jmp indirect, RETPOLINE: jmp thunk) This also avoids the issue with the relocation of the jmp target when the replacement is more than one instruction. -- Brian Gerst
