[PATCH] D35928: [XRay][X86] Use a valid instruction for the synthetic reference.

Mon Jul 31 22:26:27 PDT 2017

chandlerc added a comment.

I'd like to revisit the goal here:

Is this a performance fix by avoiding an unknown instruction that gets decoded in some cases? Or is there a correctness issue? (I think you mentioned something about linking having trouble w/ this?)

In https://reviews.llvm.org/D35928#822817, @dberris wrote:

> > I can't think of a better instruction if you need all the bits. movabsq is the only instruciton that takes a 64-bit immediate. The only other option might be one of the loads into al/ax/eax/rax from a 64-bit absolute address.
>
> I see. I think writing to the scratch register from outside of the function bodies might be more "benign" if it ever gets executed (compared to a read into one of the other registers). Although I'm not a security expert, so maybe the tradeoff here isn't as clear-cut. :/
>
> Will the x86 pipelines be happier with a store to a register than a load of an address? Or put another way, is the cost of `movabsq <immediate>,%r10` higher if it gets speculatively executed compared to say a load instruction? Or should I not even worry about this because the odds of the instruction being decoded/executed is very small (since it's aligned to 16 byte boundaries away from the end of the function)?

Emitting a load sounds really bad here. Honestly, even movabsq seems a bit bad if you're worried about performance.

To help with performance I would pad this out with nops that we know decode *fast* (as in, not into micro-ops). If you want to be defensive about ROP gadgets, I'd emit a seld of int3 instructions followed by whatever you want.

The interesting bit (as indicated above) is whether you can just guard the raw data with a nop/int3 sled, or if you actually need a valid instruction. If you *do* need a valid instruction, I'd like to understand why. We have a reasonable number of places that slap raw data above a function section...

https://reviews.llvm.org/D35928