Related implementations are available in Clang, Microsoft's Control Flow Guard and Return Flow Guard, Google's Indirect Function-Call Checks and Reuse Attack Protector (RAP).
Clang and Google Android
This section needs expansion. You can help by adding to it. (September 2020)
Intel Control-flow Enforcement Technology
This section needs expansion. You can help by adding to it. (January 2021)
The shadow stack stores a copy of the return address of each CALL in a specially-protected shadow stack. On a RET, the processor checks if the return address stored in the normal stack and shadow stack are equal. If the addresses are not equal, the processor generates an INT #21 (Control Flow Protection Fault).
Indirect branch tracking detects indirect JMP or CALL instructions with unauthorized targets. It is implemented by adding a new internal state machine in the processor. The behavior of indirect JMP and CALL instructions is changed so that they switch the state machine from IDLE to WAIT_FOR_ENDBRANCH. In the WAIT_FOR_ENDBRANCH state, the next instruction to be executed is required to be the new ENDBRANCH instruction (ENDBR32 in 32-bit mode or ENDBR64 in 64-bit mode), which changes the internal state machine from WAIT_FOR_ENDBRANCH back to IDLE. Thus every authorized target of an indirect JMP or CALL must begin with ENDBRANCH. If the processor is in a WAIT_FOR_ENDBRANCH state (meaning, the previous instruction was an indirect JMP or CALL), and the next instruction is not an ENDBRANCH instruction, the processor generates an INT #21 (Control Flow Protection Fault). On processors not supporting CET indirect branch tracking, ENDBRANCH instructions are interpreted as NOPs and have no effect.
Microsoft Control Flow Guard
Control Flow Guard (CFG) was first released for Windows 8.1 Update 3 (KB3000850) in November 2014. Developers can add CFG to their programs by adding the
/guard:cf linker flag before program linking in Visual Studio 2015 or newer.
As of Windows 10 Creators Update (Windows 10 version 1703), the Windows kernel is compiled with CFG. The Windows kernel uses Hyper-V to prevent malicious kernel code from overwriting the CFG bitmap.
CFG operates by creating a per-process bitmap, where a set bit indicates that the address is a valid destination. Before performing each indirect function call, the application checks if the destination address is in the bitmap. If the destination address is not in the bitmap, the program terminates. This makes it more difficult for an attacker to exploit a use-after-free by replacing an object's contents and then using an indirect function call to execute a payload.
For all protected indirect function calls, the
_guard_check_icall function is called, which performs the following steps:
- Convert the target address to an offset and bit number in the bitmap.
- The highest 3 bytes are the byte offset in the bitmap
- The bit offset is a 5-bit value. The first four bits are the 4th through 8th low-order bits of the address.
- The 5th bit of the bit offset is set to 0 if the destination address is aligned with 0x10 (last four bits are 0), and 1 if it is not.
- Examine the target's address value in the bitmap
- If the target address is in the bitmap, return without an error.
- If the target address is not in the bitmap, terminate the program.
There are several generic techniques for bypassing CFG:
- Set the destination to code located in a non-CFG module loaded in the same process.
- Find an indirect call that was not protected by CFG (either CALL or JMP).
- Use a function call with a different number of arguments than the call is designed for, causing a stack misalignment, and code execution after the function returns (patched in Windows 10).
- Use a function call with the same number of arguments, but one of pointers passed is treated as an object and writes to a pointer-based offset, allowing overwriting a return address.
- Overwrite the function call used by CFG to validate the address (patched in March 2015)
- Set the CFG bitmap to all 1's, allowing all indirect function calls
- Use a controlled-write primitive to overwrite an address on the stack (since the stack is not protected by CFG) 
Microsoft eXtended Flow Guard
eXtended Flow Guard (XFG) has not been officially released yet, but is available in the Windows Insider preview and was publicly presented at Bluehat Shanghai in 2019.
XFG extends CFG by validating function call signatures to ensure that indirect function calls are only to the subset of functions with the same signature. Function call signature validation is implemented by adding instructions to store the target function's hash in register r10 immediately prior to the indirect call and storing the calculated function hash in the memory immediately preceding the target address's code. When the indirect call is made, the XFG validation function compares the value in r10 to the target function's stored hash. 
- Payer, Mathias; Kuznetsov, Volodymyr. "On differences between the CFI, CPS, and CPI properties". nebelwelt.net. Retrieved 2016-06-01.
- "Adobe Flash Bug Discovery Leads To New Attack Mitigation Method". Dark Reading. 10 November 2015. Retrieved 2016-06-01.
- Endgame. "Endgame to Present at Black Hat USA 2016". www.prnewswire.com. Retrieved 2016-06-01.
- "Control Flow Integrity — Clang 3.9 documentation". clang.llvm.org. Retrieved 2016-06-01.
- Pauli, Darren. "Microsoft's malware mitigator refreshed, but even Redmond says it's no longer needed". The Register. Retrieved 2016-06-01.
- Mimoso, Michael (2015-09-22). "Bypass Developed for Microsoft Memory Protection, Control Flow Guard". Threatpost | The first stop for security news. Retrieved 2016-06-01.
- Smith, Ms. (23 September 2015). "DerbyCon: Former BlueHat prize winner will bypass Control Flow Guard in Windows 10". Network World. Retrieved 2016-06-01.
- "Return Flow Guard". Tencent. Retrieved 2017-01-19.
- Tice, Caroline; Roeder, Tom; Collingbourne, Peter; Checkoway, Stephen; Erlingsson, Úlfar; Lozano, Luis; Pike, Geoff (2014-01-01). Enforcing Forward-Edge Control-Flow Integrity in GCC & LLVM. pp. 941–955. ISBN 9781931971157.
- Security, heise. "PaX Team stellt Schutz vor Code Reuse Exploits vor". Security (in German). Retrieved 2016-06-01.
- "Frequently Asked Questions About RAP". Retrieved 2016-06-01.
- "Clang LTO Patches Updated for the Linux Kernel - Phoronix".
- "Control-flow Enforcement Technology Specification" (PDF). Intel Developer Zone. Retrieved 2021-01-05.[dead link]
- "R.I.P ROP: CET Internals in Windows 20H1". Winsider Seminars & Solutions Inc. Retrieved 2021-01-05.
- "Control Flow Guard". MSDN. Retrieved 2017-01-19.
- "Analysis of the Shadow Brokers release and mitigation with Windows 10 virtualization-based security". Microsoft Technet. 16 June 2017. Retrieved 2017-06-20.
- "Universally Bypassing CFG Through Mutability Abuse" (PDF). Alex Ionescu's Blog. Retrieved 2017-07-07.
- Falcón, Francisco (2015-03-25). "Exploiting CVE-2015-0311, Part II: Bypassing Control Flow Guard on Windows 8.1 Update 3". Core Security. Retrieved 2017-01-19.
- "Control Flow Guard" (PDF). Trend Micro. Retrieved 2017-01-19.
- "Windows 10 Control Flow Guard Internals" (PDF). Power of Community. Retrieved 2017-01-19.
- "Bypass Control Flow Guard Comprehensively" (PDF). BlackHat. Retrieved 2017-01-19.
- "An interesting detail about Control Flow Guard". Bromium. Retrieved 2017-01-19.
- Thomas, Sam (18 August 2016). "Object Oriented Exploitation: New techniques in Windows mitigation bypass". Slideshare. Retrieved 2017-01-19.
- "Advancing Windows Security". Retrieved 2021-05-19.
- "EXTENDED FLOW GUARD UNDER THE MICROSCOPE". Retrieved 2021-05-19.
- "Exploit Development: Between a Rock and a (Xtended Flow) Guard Place: Examining XFG". 23 August 2020. Retrieved 2021-05-19.