Missing mianipulation of return address

Posted Jun 26, 2018 3:15 UTC (Tue) by jreiser (subscriber, #11027)
Parent article: Kernel support for control-flow enforcement

If Intel (and AMD?) are going to trouble of implementing CET, perhaps they could be persuaded to implement two related missing instructions? PUSHRA (push return address) and POPRA (pop return address) are the same as ordinary PUSH and POP, except for the explicit hint that the data item is a return address, and thus the side stack (cache) of return addresses should be manipulated accordingly. Such instructions would enable a measurable speed improvement (> 1%) for some mixed compiled+interpreted language runtime systems, by reducing the overhead from a mis-predicted branch when a compiled RET encounters a mismatch between the side stack and the real stack because the interpreter was in control at the time of the PUSHRA. PUSHRA is 0xFF/7 (hex 0xFF followed by modR/M of octal 0m7r) and POPRA is 0x8F/1 (hex 0x8F followed by modR/M of octal 0m1r).

to post comments

Missing mianipulation of return address

Posted Jun 26, 2018 5:10 UTC (Tue) by luto (subscriber, #39314) [Link]

Where does your 1% number come from?

Implementing PUSHRA may require special hardware. Consider PUSHRA mem; CALL. The CPU wants to speculatively execute CALL before the PUSHRA argument becomes available. To do that, either the CPU can push garbage to the return stack, in which case the instruction would be almost useless, or PUSHRA would need to reserve a return stack slot and fill it later. The latter might be fairly intrusive to a CPU design.

POPRA reg/mem seems silly. A POPRA that simply discards a return stack entry and has no effect on RSP seems better. Also, speculative execution of PUSHRA might not even be supportable by conventional return stack hardware.

Also, why are you assigning your hypothetical instructions opcodes at all, let alone single-byte opcodes?