On Sun, 2018-01-07 at 15:03 +0100, Borislav Petkov wrote: > > My fear is if some funky compiler changes the sizes of the insns in > RETPOLINE_CALL/JMP and then the padding becomes wrong. But looking at the > labels, they're all close so you have a 2-byte jmp already and the > > call 1112f > > should be ok. The MOV is reg,(reg) which should not change size of 4... > > But I'm remaining cautious here.
Right. I forget the specifics, but I've *watched* LLVM break carefully hand-crafted asm code by emitting 4-byte variants when we expected 2- byte, etc. On the whole, I'm sufficiently unhappy with making such assumptions, that I think the cure is worse than the disease. We can live with that *one* out-of-line call to the thunk in the syscall case, and that was the *only* one that really needed the call to be at the end. Note that in the alternative case there, we don't even need to load it into a register at all. We could do our own alternatives specially for that case, and hand-tune the lengths only for them. But *with* a sanity check to break the build on mismatch. I don't think it's worth it at this point though.
smime.p7s
Description: S/MIME cryptographic signature