There's an interesting hack described at:

https://blog.can.ac/2021/03/22/speculating-x86-64-isa-with-one-weird-trick/

where the author causes a misprediction in order to force the processor
to "execute" arbitrary code safely (relying on the speculation mechanism
to keep the code perfectly safe by undoing its effect (save for the
impact on the internal event counters, which is presumably the only
remaining traces of what happened)).

The code he uses to trick the processor into executing code
speculatively is the following:

call x
<speculated code>
x:
lea rax, [rip+z]
xchg [rsp], rax
ret
z:

I can see why the processor would speculatively execute the code after
the `call`, because the `ret`s destination is predicted by the return
address predictor, but given that the prediction for this `ret` will
always fail, I'm surprised there isn't some meta-predictor that
kicks in.

The author also say that the XCHG is important because "if you try the
same with MOV or ADD at the callee site you’ll notice that it doesn’t
work anymore. Could just be the stall caused by the memory locking
implied by XCHG". Which suggests that the processor pays attention
to stack accesses that might invalidate the return address stack
predictor (and just happens not to do that effort for XCHG).

Does anyone know a bit more about what can be expected in terms of when
the return stack predictor is used and when it is not and/or when it is
invalidated?

Stefan

On Friday, May 14, 2021 at 10:37:33 AM UTC-5, Stefan Monnier wrote:
> There's an interesting hack described at:
>
> https://blog.can.ac/2021/03/22/speculating-x86-64-isa-with-one-weird-trick/
>
> where the author causes a misprediction in order to force the processor
> to "execute" arbitrary code safely (relying on the speculation mechanism
> to keep the code perfectly safe by undoing its effect (save for the
> impact on the internal event counters, which is presumably the only
> remaining traces of what happened)).
>
> The code he uses to trick the processor into executing code
> speculatively is the following:
>
> call x
> <speculated code>
> x:
> lea rax, [rip+z]
> xchg [rsp], rax
> ret
> z:
>
> I can see why the processor would speculatively execute the code after
> the `call`, because the `ret`s destination is predicted by the return
> address predictor, but given that the prediction for this `ret` will
> always fail, I'm surprised there isn't some meta-predictor that
> kicks in.
>
> The author also say that the XCHG is important because "if you try the
> same with MOV or ADD at the callee site you’ll notice that it doesn’t
> work anymore. Could just be the stall caused by the memory locking
> implied by XCHG". Which suggests that the processor pays attention
> to stack accesses that might invalidate the return address stack
> predictor (and just happens not to do that effort for XCHG).
>
> Does anyone know a bit more about what can be expected in terms of when
> the return stack predictor is used and when it is not and/or when it is
> invalidated?
<
I know back in the Opteron days that the Call Return Stack was a linked list of
return information. We kept it in linked list form* because RETs were speculated
and might have to be recovered and in this case we would downdate the pointers
recover the stack. There was no stack flushing, but if you got out of sequence
it would always mispredict and fall back on HW to recover.

(*) when a CALL was performed, we pushed a SCR entry on the stack using the
front of the CRS free pool and when we returned we pushed the free entry on the
back of the free pool so it had a chance of being recovered.

This was all done with 4-bit pointers which we wrote 8-bits at a time (->next and
->previous)
>
>
> Stefan