Hubbry Logo
Control-flow integrityControl-flow integrityMain
Open search
Control-flow integrity
Community hub
Control-flow integrity
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Control-flow integrity
Control-flow integrity
Control-flow integrity
View on Wikipedia
from Wikipedia

Control-flow integrity (CFI) is a general term for computer security techniques that prevent a wide variety of malware attacks from redirecting the flow of execution (the control flow) of a program.

Background

[edit]

A computer program commonly changes its control flow to make decisions and use different parts of the code. Such transfers may be direct, in that the target address is written in the code itself, or indirect, in that the target address itself is a variable in memory or a CPU register. In a typical function call, the program performs a direct call, but returns to the caller function using the stack – an indirect backward-edge transfer. When a function pointer is called, such as from a virtual table, we say there is an indirect forward-edge transfer.[1][2]

Attackers seek to inject code into a program to make use of its privileges or to extract data from its memory space. Before executable code was commonly made read-only, an attacker could arbitrarily change the code as it is run, targeting direct transfers or even do with no transfers at all. After W^X became widespread, an attacker wants to instead redirect execution to a separate, unprotected area containing the code to be run, making use of indirect transfers: one could overwrite the virtual table for a forward-edge attack or change the call stack for a backward-edge attack (return-oriented programming). CFI is designed to protect indirect transfers from going to unintended locations.[1]

Techniques

[edit]

Associated techniques include code-pointer separation (CPS), code-pointer integrity (CPI), stack canaries, shadow stacks, and vtable pointer verification.[3][4][5] These protections can be classified into either coarse-grained or fine-grained based on the number of targets restricted. A coarse-grained forward-edge CFI implementation, could, for example, restrict the set of indirect call targets to any function that may be indirectly called in the program, while a fine-grained one would restrict each indirect call site to functions that have the same type as the function to be called. Similarly, for a backward edge scheme protecting returns, a coarse-grained implementation would only allow the procedure to return to a function of the same type (of which there could be many, especially for common prototypes), while a fine-grained one would enforce precise return matching (so it can return only to the function that called it).

Implementations

[edit]

Related implementations are available in Clang (LLVM in general),[6] Microsoft's Control Flow Guard[7][8][9] and Return Flow Guard,[10] Google's Indirect Function-Call Checks[11] and Reuse Attack Protector (RAP).[12][13]

LLVM/Clang

[edit]

LLVM/Clang provides a "CFI" option that works in the forward edge by checking for errors in virtual tables and type casts. It depends on link-time optimization (LTO) to know what functions are supposed to be called in normal cases.[14] There is a separate "shadow call stack" scheme that defends on the backward edge by checking for call stack modifications, available only for aarch64.[15]

Google has shipped Android with the Linux kernel compiled by Clang with link-time optimization (LTO) and CFI since 2018.[16] SCS is available for Linux kernel as an option, including on Android.[17]

Intel Control-flow Enforcement Technology

[edit]

Intel Control-flow Enforcement Technology (CET) detects compromises to control flow integrity with a shadow stack (SS) and indirect branch tracking (IBT).[18][19]

The kernel must map a region of memory for the shadow stack not writable to user space programs except by special instructions. The shadow stack stores a copy of the return address of each CALL. 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 to 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

[edit]

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.[20]

As of Windows 10 Creators Update (Windows 10 version 1703), the Windows kernel is compiled with CFG.[21] The Windows kernel uses Hyper-V to prevent malicious kernel code from overwriting the CFG bitmap.[22]

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.[20] 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.[23]

Implementation details

[edit]

For all protected indirect function calls, the _guard_check_icall function is called, which performs the following steps:[24]

  1. Convert the target address to an offset and bit number in the bitmap.
    1. The highest 3 bytes are the byte offset in the bitmap
    2. The bit offset is a 5-bit value. The first four bits are the 4th through 8th low-order bits of the address.
    3. 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.
  2. Examine the target's address value in the bitmap
    1. If the target address is in the bitmap, return without an error.
    2. If the target address is not in the bitmap, terminate the program.

Bypass techniques

[edit]

There are several generic techniques for bypassing CFG:

  • Set the destination to code located in a non-CFG module loaded in the same process.[23][25]
  • Find an indirect call that was not protected by CFG (either CALL or JMP).[23][25][26]
  • 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).[27]
  • 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.[28]
  • Overwrite the function call used by the CFG to validate the address (patched in March 2015)[26]
  • Set the CFG bitmap to all 1's, allowing all indirect function calls[26]
  • Use a controlled-write primitive to overwrite an address on the stack (since the stack is not protected by CFG) [26]

Microsoft eXtended Flow Guard

[edit]

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.[29]

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. [30][31]

See also

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Control-flow integrity

View on Grokipedia
from Grokipedia
Control-flow integrity (CFI) is a mechanism that enforces a program's to adhere strictly to a predefined (CFG), thereby preventing attacks that attempt to hijack execution by redirecting control transfers to unauthorized locations. This technique mitigates a wide range of exploits, such as buffer overflows and code-reuse attacks like (ROP), by ensuring that indirect control transfers—such as jumps, calls, and returns—only target valid destinations as specified in the CFG. Introduced in 2005 by Martin Abadi and colleagues, CFI builds on earlier defenses like stack canaries and software fault isolation but provides a more comprehensive policy for aligning low-level machine-code behavior with high-level program intent. The core approach involves two phases: static analysis to compute a CFG representing all legitimate control transfers in the program, followed by binary instrumentation or compiler modifications to insert runtime checks that validate each transfer against the CFG, halting execution if a violation is detected. Early implementations, such as those for x86 Windows binaries, demonstrated an average performance overhead of about 16% on benchmarks like SPEC2000, while effectively blocking exploits in real-world malware like the Blaster and Slammer worms. Over the subsequent two decades, CFI has evolved from primarily software-based solutions to include hardware-assisted variants, addressing challenges like performance overhead and precision in CFG policies. Software implementations often focus on protecting code pointers and forward/backward edges through techniques like shadow stacks for returns and context-sensitive checks for indirect jumps, with notable advancements in modular CFI for separate compilation and fine-grained policies to counter advanced attacks like counterfeited control-flow (CFB). Hardware-based CFI, surveyed in over 20 architectures by 2017, leverages processor features such as Intel's Control-flow Enforcement Technology (CET)—which includes shadow stacks and endbranch instructions—and ARM's Pointer Authentication Codes (PACs) to enforce protections with lower runtime costs. By 2025, adoption remains uneven: approximately 28.7% of binaries in incorporate CFI for both forward- and backward-edge protection, up from 2.7% in Android 8.1, driven by priorities, while distributions like and show less than 1% prevalence due to implementation complexities and overhead concerns. Ongoing research continues to refine CFI for embedded systems, real-time environments, and integration with , emphasizing renewable policies to adapt to dynamic code changes.

Introduction

Definition and Purpose

Control-flow integrity (CFI) is a mechanism that ensures a program's adheres to a precomputed policy derived from its (CFG), thereby restricting indirect branches to only valid targets identified through static analysis. This enforcement prevents unauthorized alterations to the program's execution path by verifying that runtime control transfers match the static model at key points, such as indirect jumps and calls. The primary purpose of CFI is to mitigate control-flow hijacking attacks, where vulnerabilities like buffer overflows allow adversaries to redirect execution to unintended code. Introduced by Martin Abadi, Mihai Budiu, Úlfar Erlingsson, and Jay Ligatti in their seminal 2005 paper, CFI provides a robust defense by limiting the scope of exploits to predefined paths, offering stronger security guarantees compared to earlier techniques that address only specific vulnerability classes. CFI reduces the for code-reuse attacks by confining execution to legitimate sequences within the CFG, without requiring changes. It is particularly valuable for legacy software, as it can be retrofitted via binary rewriting to instrument existing binaries. The original enforcement approach relies on software fault isolation, which inserts lightweight runtime checks to validate efficiently while maintaining performance.

Historical Context

Control-flow integrity (CFI) was first proposed in 2005 by researchers Martin Abadi, Mihai Budiu, Úlfar Erlingsson, and Jay Ligatti as a defense against control-flow hijacking attacks, such as buffer overflows and return-to-libc exploits. The seminal paper introduced CFI as a security property enforcing that program execution adheres to a precomputed , preventing deviations that could enable malicious behavior. An initial prototype was implemented using the compiler infrastructure, demonstrating feasibility for programs with acceptable overhead in controlled experiments; the work also included binary rewriting for x86 Windows binaries to support legacy software without source access. A revised version of the original work appeared in , providing deeper analysis of CFI principles, implementations, and applications, which solidified its theoretical foundations. Subsequent refined binary-level , exemplified by bin-CFI in 2013, which extended CFI to commercial off-the-shelf (COTS) binaries on x86/ without requiring source access or recompilation. In 2014, introduced Guard (CFG), a coarse-grained CFI variant, into to mitigate indirect call hijacking in user-mode applications. This was followed in 2016 by Intel's announcement of Control-flow Enforcement Technology (CET), a hardware extension offering shadow stacks and indirect branch tracking to support fine-grained CFI with minimal software overhead. Adoption of CFI gained momentum after high-profile vulnerabilities like Heartbleed in 2014, which exposed widespread memory corruption risks, and Spectre in 2018, which demonstrated speculative execution's potential for control-flow manipulation, spurring demand for robust hardware-assisted defenses. By 2023, CFI had been integrated into production environments, including Google's Chrome browser via the V8 JavaScript engine, where it enforces forward- and backward-edge checks to protect against exploitation in just-in-time compiled code. As of 2023, adoption remained uneven, with approximately 28.7% of binaries in Android 13 incorporating CFI for both forward- and backward-edge protection, compared to less than 1% prevalence in Linux distributions like Ubuntu and Debian due to implementation complexities and overhead concerns. Early software-only CFI implementations faced significant performance challenges, with runtime overheads averaging around 16% (up to 45%) on SPEC2000 benchmarks due to dynamic checks and code instrumentation, limiting deployment in performance-sensitive applications. These issues drove the evolution toward hybrid hardware-software approaches in the 2020s, leveraging features like Intel CET to offload enforcement and reduce overhead to under 5% in many cases.

Security Threats

Control-Flow Hijacking Attacks

Control-flow hijacking attacks exploit memory corruption vulnerabilities to alter a program's intended execution path by manipulating control data, such as return addresses on the stack or function pointers in memory. In a typical scenario, an attacker supplies excessive input that overflows a buffer, overwriting adjacent control data and redirecting to malicious or unintended code locations upon the next , like a function return. This diversion allows the attacker to execute arbitrary instructions outside the program's legitimate . The impact of these attacks is severe, as they facilitate —directly executing attacker-supplied payloads—or the reuse of existing binary code snippets called gadgets to bypass protections and perform unauthorized operations, such as or . These exploits predominantly target software written in memory-unsafe languages like and , where bounds checking is absent, enabling unchecked writes to sensitive memory regions. issues, including those enabling control hijacking, account for approximately 50% of Microsoft-assigned CVEs as of 2025. Successful control-flow hijacking requires specific preconditions, including writable segments for both and , which allow of control structures, and the presence of indirect control transfers, such as virtual function calls or pointer-based jumps. While mitigations like Data Execution Prevention (DEP) prevent execution of injected and (ASLR) complicates address prediction, they fall short because they do not enforce validation of control transfer destinations, leaving room for attacks like that repurpose legitimate . Recent analyses, such as those using the SeeCFI tool, highlight ongoing vulnerabilities in real-world binaries despite these defenses, underscoring the need for targeted control validation.

Specific Exploit Techniques

Return-Oriented Programming (ROP) is a code-reuse attack technique where an attacker chains together short sequences of existing instructions, known as "gadgets," typically ending with a return instruction, to execute arbitrary malicious behavior without injecting new code. These gadgets are discovered in the program's binary or linked libraries, allowing the attacker to redirect control flow by overwriting the return address on the stack, effectively bypassing Data Execution Prevention (DEP) mechanisms that prevent execution of non-code memory regions by reusing legitimate, executable code segments. ROP was first formalized as a Turing-complete exploitation paradigm, demonstrating its ability to perform complex computations through gadget composition on architectures like x86. Jump-Oriented Programming (JOP) extends code-reuse attacks by focusing on indirect jumps rather than returns, mitigating limitations of ROP in environments where stack-based control is restricted or monitored. In JOP, attackers identify "jump gadgets"—instruction sequences concluding with an indirect jump—and link them via a centralized dispatch table constructed in attacker-controlled memory, enabling sequential execution of gadgets without relying on the return instruction or stack pivoting. This approach targets vulnerabilities exploitable through indirect control transfers, such as calls in object-oriented code, and has been shown to achieve on x86 systems by chaining gadgets from libraries like libc. Counterfeit Object-Oriented Programming (COOP) represents an advanced code-reuse technique tailored to C++ applications, exploiting virtual dispatch mechanisms to hijack without altering return addresses or direct jumps. In COOP, an attacker forges legitimate-looking objects in memory, corrupting virtual tables (vtables) to point to attacker-chosen methods, thereby inducing a chain of virtual function calls that execute desired operations while adhering to the program's type constraints and appearing benign to coarse-grained defenses. This method leverages object-oriented features like and polymorphism to bypass control-flow integrity checks that validate targets but not the contextual validity of calls, and it has been demonstrated to defeat multiple CFI implementations on real-world C++ binaries. A more recent variant, Coroutine Frame-Oriented Programming (CFOP), exploits vulnerabilities in C++20 coroutine implementations to bypass CFI protections in modern compilers. CFOP manipulates coroutine frames—data structures managing suspension and resumption—through heap corruption, allowing attackers to forge frames that redirect control flow to arbitrary gadgets while evading checks on indirect branches and object integrity. This technique succeeds across LLVM, GCC, and MSVC by abusing the lack of validation in frame allocation and resumption logic, enabling full code reuse even in hardened environments, as shown in exploits against 15 CFI schemes.

Fundamental Concepts

Direct and Indirect Control Transfers

In computer programs, control-flow transfers determine the sequence of instruction execution. Direct control transfers involve fixed, statically known destinations, such as unconditional jumps or calls to specific function addresses embedded in the . These transfers are inherently safe from manipulation because their targets are resolved at and cannot be altered dynamically without modifying the executable itself. In contrast, indirect control transfers have destinations determined at runtime through dynamic values, typically loaded from registers, locations, or pointers. Common examples include return instructions (ret), which fetch the target address from the stack; virtual function calls in object-oriented languages, which resolve targets via virtual tables (vtables); indirect jumps or calls using computed addresses (e.g., jmp reg or call [reg]); switch statements implemented via jump tables, where the target is selected based on a computed index; and invocations of signal handlers, which often involve indirect calls through function pointers set by the program. These transfers are particularly susceptible to attacks that overwrite pointers or registers, as the target addresses are not fixed and can be corrupted through errors like buffer overflows. Control-flow integrity (CFI) policies address these vulnerabilities by deriving whitelists of valid targets specifically for each indirect transfer site. These policies are constructed through static analysis of the program's (CFG), which models all possible execution paths and identifies legitimate destinations reachable from each indirect site under normal conditions. For instance, for a return instruction, the policy might limit targets to addresses of valid call sites in the CFG, while for a virtual call, it restricts targets to entries in the program's vtables. This approach ensures that only precomputed, safe targets are permitted, preventing deviations from the intended without requiring runtime computation of all possibilities.

Control-Flow Graphs and Policies

In control-flow integrity (CFI), the (CFG) serves as a foundational model representing the valid execution paths of a program. It is a in which nodes correspond to basic blocks—sequences of instructions with a single and a single exit point—and edges denote permissible control transfers between these blocks. The CFG is typically constructed through static analysis of the program's binary or , identifying potential targets of branches, calls, and returns while conservatively approximating indirect transfers whose destinations are not immediately known at . The CFI policy defines the subset of CFG edges that must be respected during execution, particularly for indirect control transfers such as those via function pointers or returns, which are vulnerable to manipulation. This policy restricts forward edges, like indirect calls, to target only function entry points, and backward edges, like returns, to valid caller locations, thereby limiting the program's behavior to a precomputed safe subset of possible flows. Policies are derived from the full CFG but focus on enforcing constraints at indirect branch sites to prevent deviations that could enable attacks. CFI policies operate at varying levels of to balance and . Coarse-grained policies, often at the level, group multiple blocks under shared identifiers (e.g., one label per function), allowing transfers within broader equivalence classes but potentially permitting some invalid paths. Fine-grained policies, conversely, operate at the instruction level, assigning unique identifiers to precise locations and enforcing stricter constraints on targets. Runtime checks validate adherence to the policy by verifying that each indirect transfer lands on an allowed destination. Formally, a CFI can be represented as a collection of allowed (source, target) pairs for each indirect control-transfer site in the program, where the source is the originating or instruction, and the target is a valid successor in the CFG. This set-theoretic view ensures that dynamic execution remains confined to the static , with proofs demonstrating that no unauthorized transfers are possible even under adversarial control of . Such representations enable theoretical of completeness and precision.

CFI Techniques

Coarse-Grained Approaches

Coarse-grained approaches to control-flow integrity (CFI) enforce broad policies that restrict indirect control transfers to large equivalence classes of potential targets, such as all functions compatible with a given pointer type, while minimizing overhead. These methods group valid targets loosely based on static analysis of program structure, allowing transfers only within these classes to approximate the intended (CFG) without enforcing precise per-target validation. Such policies prioritize practicality over strictness, making them feasible for real-world deployment where fine-grained checks would incur excessive costs. Key examples include type-based CFI, which validates targets by matching the runtime type of a against predefined equivalence classes derived from the program's , ensuring that indirect calls or jumps land only on functions with compatible signatures. Another variant involves blacklisting obviously invalid targets, such as non-function addresses, while permitting others within broad categories to reduce false positives. Early implementations, such as the 2005 Google prototype for Windows/x86 binaries, demonstrated these principles by inserting lightweight checks at indirect branches to enforce class-based restrictions computed from the program's CFG. Subsequent binary-level adaptations, like bin-CFI, extended this to commercial off-the-shelf (COTS) software by assigning a small set of labels (e.g., based on function types and module locations) without requiring access. A notable example is CCFIR (Compact Control-Flow Integrity and Randomization), introduced in 2013, which applies policies to binaries by assigning distinct IDs for function pointers and returns (e.g., a 3-ID scheme), redirecting indirect jumps to aligned stubs for validation, achieving low overheads around 4% on SPECint2000. These approaches offer significant advantages in and compatibility, with runtime overheads typically ranging from 5% to 10% on benchmark suites like SPEC CPU2000, enabling their application to legacy binaries without extensive recompilation. Their minimal —often just a few instructions per indirect transfer—preserves the original program's behavior while providing a baseline defense against gross control hijacking. However, they remain susceptible to intra-class attacks, where an adversary redirects flow to a malicious function within the same , such as a type-compatible gadget in chains. Additionally, their reliance on static analysis limits effectiveness against dynamic code loading or , as new targets may evade precomputed classes.

Fine-Grained Approaches

Fine-grained control-flow integrity (CFI) approaches enforce precise, context-sensitive policies that restrict indirect control transfers to exact, precomputed targets at each call site, using unique labels or identifiers assigned to functions and control-flow edges. This contrasts with coarser methods by minimizing valid targets per site through whole-program analysis, which constructs detailed control-flow graphs to derive whitelists of permissible destinations. Such policies enhance by preventing deviations even within the same function type, addressing limitations of broader classifications. Key techniques involve compile-time insertion of runtime checks, where branch targets are compared against site-specific whitelists before execution, often using bit-testing or cryptographic signatures for validation. Binary rewriting enables deployment on legacy code by inserting these checks and redirecting transfers to validation stubs, while label-based methods embed unique IDs at function entries for verification. These mechanisms require comprehensive static analysis to propagate labels across modules, ensuring compatibility with dynamic linking. Recent advancements include origin-sensitive CFI, which tracks pointer origins to further refine target sets, achieving overheads under 10% in some implementations as of 2019. Another approach leverages Pointer Authentication (PAC), a hardware feature that embeds cryptographic modifiers in pointers to enforce fine-grained CFI; for instance, return addresses are signed with context-specific keys, verifying exact targets at each site. PAC-based systems achieve precision by tying authentication to call-site contexts, resisting pointer forgery in indirect transfers. These methods incur higher runtime overheads, around 20% on performance-sensitive benchmarks like SPEC CPU2006 due to frequent checks and analysis demands, but provide robust resistance to advanced attacks like Counterfeit Object-Oriented Programming (COOP) by enforcing per-site constraints that block object reuse chains. The need for whole-program analysis limits scalability in large, modular systems, though optimizations like signature-based validation can mitigate costs in kernels.

Auxiliary Mechanisms

Shadow stacks provide a mechanism to protect backward edges in control-flow transfers by maintaining a separate, protected stack dedicated exclusively to return addresses. Upon a function call, the return address is pushed onto both the regular data stack and the shadow stack; on return, the address popped from the data stack is verified against the one from the shadow stack before proceeding. This ensures that (ROP) attacks, which rely on overwriting return addresses on the stack, are thwarted by preventing mismatched returns. The shadow stack is typically isolated in a protected region, such as a separate thread-local area or kernel-protected space, to prevent direct tampering. Vtable verification enhances control-flow integrity for object-oriented languages like C++ by safeguarding calls against corruption of virtual method tables (vtables). It involves computing and storing cryptographic hashes or identifiers for legitimate vtables at , then validating the vtable pointer's integrity before indirect calls through virtual functions. This check ensures that only authorized vtables are used, defending against attacks like counterfeit (COOP) that forge valid-looking objects to hijack virtual dispatch. Implementations often embed verification code at call sites, with minimal runtime checks using precomputed hashes to confirm vtable authenticity. For instance, techniques like VTint validate vtable integrity by hashing entries and comparing against expected values, incurring less than 2% performance overhead on benchmarks. Code-pointer integrity (CPI) extends CFI protections beyond control transfers to non-control pointers that , such as function pointers embedded in structures. CPI enforces that all pointers remain unforgeable by selectively instrumenting accesses to validate pointer at load and store operations, using techniques like pointer or isolated storage. This prevents data-flow attacks where corrupted pointers could lead to , providing a formal guarantee of for code-referencing without full address-space protection. The approach instruments only necessary accesses, achieving practical overheads of 7%–21% on standard benchmarks like SPEC CPU2006. These auxiliary mechanisms are frequently integrated with core CFI policies to provide comprehensive protection, as standalone edge checks alone may leave gaps in backward edges or . For example, LLVM/Clang has supported shadow call stacks since version 7 (2018), allowing compilation with the -fsanitize=shadow-call-stack flag to combine them seamlessly with forward-edge CFI, resulting in isolated handling with typical overheads of 2%–5% for the stack component alone. Such combinations ensure robust defense against control-flow hijacking while maintaining compatibility with existing codebases.

Implementations

Compiler Support: LLVM/Clang

LLVM/Clang has provided integrated support for control-flow integrity (CFI) since LLVM version 3.4, following the implementation described in the seminal work on enforcing forward-edge CFI in production compilers. The primary mechanism for enabling fine-grained CFI in Clang is the -fsanitize=cfi flag, which instruments code to verify indirect control transfers against a compile-time control-flow policy derived via link-time optimization (LTO). This approach leverages LTO to analyze the entire program or module, generating efficient runtime checks such as jump tables for indirect calls, ensuring high precision without simplifying assumptions about the code. Key features of Clang's CFI implementation include support for shadow call stacks via the -fsanitize=shadow-call-stack flag, which protects return addresses by maintaining a separate stack for them, available on x86_64 and architectures. Vtable verification is handled through sub-flags like -fsanitize=cfi-vcall and -fsanitize=cfi-nvcall, which check virtual and non-virtual calls against expected dynamic types, preventing type-confused control hijacks in C++ code. Since (API level 28) in 2018, Clang's CFI has been enabled by default in security-critical components such as media frameworks, NFC, and , using forward-edge protections to safeguard user-space and kernel code. Recent advancements include enhanced integration with Pointer Authentication Codes (PAC) starting from Clang versions supporting Armv8.3-A in 2023, where the -mbranch-protection flag enables hardware-accelerated signing of return addresses and pointers, complementing software CFI checks for backward-edge protection. Additionally, as of 2025, -compiled binaries can be analyzed for CFI presence using SeeCFI, a detection tool that identifies instrumentation patterns without source access, facilitating deployment verification. For optimal precision, Clang's CFI requires whole-program LTO via -flto, though ThinLTO (-flto=thin) offers a scalable alternative with reduced compilation time while maintaining most benefits. Performance overhead is typically low, with runtime costs around 4% on benchmarks like SPEC CPU2006 when using LTO, and further mitigated to under 10% in practical workloads through optimizations like ThinLTO.

Compiler Support: GCC

The GNU Compiler Collection (GCC) introduced software-based control-flow integrity (CFI) support through the Virtual Table Verification (VTV) mechanism in version 4.9, released in April 2014, focusing on fine-grained forward-edge protection for C++ virtual function calls by verifying vtable pointers at runtime using type-based checks. This implementation instruments code to ensure that indirect calls via virtual functions adhere to the program's control-flow graph, with checks performed against a global table of verified vtables, providing protection against type-confused pointer dereferences without requiring link-time optimization (LTO) for basic operation. VTV builds upon coarser-grained defenses like Fortify Source, which mitigates buffer overflows that could indirectly enable control-flow hijacks, though it does not enforce full CFI policies on its own. Performance evaluations on SPEC CPU2006 benchmarks showed an average runtime overhead of 8% for VTV, with code size increases up to 15%, establishing its viability for production use while prioritizing precision for C++ workloads. Key features of GCC's CFI include type-based validation in VTV, which assigns unique identifiers to function types and checks compatibility during virtual dispatches to prevent cross-type attacks, covering over 99% of virtual calls in evaluated binaries. For backward-edge protection, GCC integrates with stack-smashing defenses via the -fstack-protector option, which inserts canaries to detect corruption, serving as a software to shadow stacks in the absence of native support until hardware extensions were added later. Fine-grained CFI enforcement, particularly for forward edges, can leverage LTO (-flto) to compute more precise control-flow policies across compilation units, enhancing VTV's accuracy by propagating type information globally, though this increases compilation time by 20-50%. Hardware-assisted CFI, enabled via -fcf-protection, supports tracking (e.g., x86 ENDBR opcodes) and pointer authentication on compatible architectures, requiring LTO for full policy derivation and offering near-zero runtime overhead on supported hardware. Recent advancements in GCC's CFI support include expanded compatibility for architectures starting in version 15 (released in 2025), with implementation of the Zicfilp extension for forward-edge landing pads and Zicfiss for stateful shadow stacks, enabling efficient software-hardware hybrid CFI without dedicated registers. These improvements address 's lack of built-in CFI primitives, reducing overhead to under 2% on workloads through atomic stack operations like ssamoswap. However, GCC's CFI remains vulnerable to novel attacks like Coroutine Frame-Oriented Programming (CFOP), a code-reuse technique exploiting C++ frames to bypass protections in versions up to 14.2, as demonstrated in a 2025 analysis affecting major compilers including GCC. Overall adoption of GCC's CFI lags behind /, with only 12% of analyzed binaries in a 2025 study enabling software CFI compared to 28% for , attributed to GCC's emphasis on hardware reliance and less modular sanitizer integration. To enable CFI in GCC, developers must use -fvtable-verify=std for VTV or -fcf-protection=full for hardware modes, both benefiting from -flto to enforce program-wide policies and minimize false positives in indirect transfers. Runtime overhead for hardware CFI is typically 1-3% on SPEC benchmarks, comparable to Clang's implementations, but GCC's less optimized integration results in higher mobile deployment costs, such as 5-10% battery impact on devices due to coarser LTO handling in embedded toolchains.

Hardware Support: Intel CET

Intel's Control-flow Enforcement Technology (CET) is a hardware-based extension designed to protect against control-flow hijacking attacks, such as (ROP) and jump-oriented programming (JOP), by enforcing valid control transfers at the processor level. Introduced in 2019 with the Ice Lake microarchitecture (10th Generation processors), CET provides two primary mechanisms: shadow stacks for safeguarding return addresses and indirect branch tracking (IBT) for validating indirect control transfers. CET is enabled via the CR4.CET bit and requires verification of support through specific feature flags, such as CET_SS for shadow stacks and CET_IBT for indirect branch tracking. The shadow stack mechanism maintains a separate, protected stack solely for return addresses, managed by the Shadow Stack Pointer (SSP) stored in model-specific registers (MSRs) like IA32_PL3_SSP for user mode. During function calls, the processor automatically pushes the return address onto this shadow stack using instructions like CALL, while returns (RET or IRET) pop and compare it against the runtime stack; mismatches trigger a control-protection exception (#CP). IBT enforces that indirect branches (e.g., indirect JMP or CALL) land only on valid targets marked by endbranch instructions (ENDBR64 in 64-bit mode or ENDBR32 in 32-bit/compatibility mode), which reset a branch tracker in MSRs such as IA32_U_CET.TRACKER. Violations, including indirect branches to unmarked locations or invalid endbranch executions, also raise a #CP exception (interrupt vector 21) with an error code indicating the fault type, such as NEAR-RET for near returns. CET compatibility has been integrated into major operating systems starting in 2020, with version 20H1 (May 2020 Update) enabling user-mode shadow stack support for compatible hardware, and 5.18 (May 2022) adding IBT for the kernel, followed by user-space shadow stack support in kernel 6.4 (June 2023). When properly implemented with compiler-generated endbranch markers and OS-managed MSRs, CET incurs minimal runtime overhead, typically less than 1% on standard benchmarks, due to its hardware-accelerated checks and NOP-like endbranch instructions. As an x86-specific extension, CET is limited to Intel processors supporting the feature (from Ice Lake onward) and requires explicit OS and compiler enablement, such as via parameters or Windows compatibility modes; it does not function on legacy x86 hardware without CET or on non-x86 architectures.

Hardware Support: ARM Pointer Authentication

ARM Pointer Authentication (PAC) is a hardware security extension introduced in the v8.3-A architecture in 2016, designed to protect pointers from unauthorized modification by embedding a cryptographic Pointer Authentication Code (PAC) into unused high-order bits of 64-bit pointers. The PAC is generated using a keyed cryptographic primitive based on the QARMA block cipher, leveraging one of five 128-bit secret keys stored in special system registers that are inaccessible to user-mode software. This mechanism enables probabilistic verification of pointer integrity, making it significantly harder for attackers to forge or corrupt pointers during control-flow hijacking attempts, thus serving as a foundational enabler for control-flow integrity (CFI) enforcement. The core mechanisms of PAC focus on authenticating critical control-flow transfers, particularly returns and calls. For return address protection, the PAC-IA instructions use the A-key for instruction addresses to sign the link register before pushing it onto the stack and verify it upon return using authentication instructions like AUTIASP. Similarly, PAC-IB employs the B-key to authenticate call targets, ensuring that indirect branches to function pointers are validated against expected signatures. In ARMv8.5 and later architectures, PAC integrates with shadow stack mechanisms, such as those using dedicated pointer-authenticated stacks, to provide stronger backward-edge CFI by separating return addresses from the main call stack and enforcing authentication on stack operations. Recent advancements have expanded PAC's adoption in production systems. Since 2023, Google's Chrome V8 JavaScript engine has incorporated PAC for CFI, signing return addresses and code pointers to mitigate exploitation in web applications running on devices. In 2025, introduced HyperGuard for Windows on ARM64, which leverages PAC to enhance kernel-mode protections against control-flow attacks by diversifying key usage and integrating with hypervisor-based integrity checks. PAC also resists attacks through address diversification, where the PAC computation incorporates pointer location and modifier values, preventing attackers from reliably forging signatures even with partial memory access or hardware faults. PAC is widely compatible with modern ARM hardware, including Apple's M-series processors, which implement it under the arm64e ABI for system-wide pointer signing in and macOS. Qualcomm's Snapdragon processors, starting with models like the 8cx Gen 3, support PAC for enhanced security in Windows and Android environments. Compiler support is mature, with providing pointer authentication intrinsics and ABI handling since 2019, alongside GCC's integration of PAC instructions from the same period. Typical performance overhead remains low at around 3% for return-address protection in instrumented applications, attributed to hardware-accelerated cryptography.

OS and Runtime Protections

Control Flow Guard (CFG) is a software-based control-flow integrity mechanism integrated into the Windows operating system, initially introduced in Windows 8.1 Update 3 in November 2014 to mitigate memory corruption vulnerabilities by validating indirect control transfers in user-mode applications. It employs a bitmap-based validation approach, where the operating system maintains a per-process bitmap protected by the kernel; this bitmap marks valid targets for indirect calls, such as function entry points, and the processor checks against it at runtime to prevent unauthorized jumps. For kernel-mode protection, Kernel Control Flow Guard (KCFG) extends this to the Windows kernel, leveraging Hypervisor-protected Code Integrity (HVCI) under Virtualization-Based Security (VBS); it became available starting with Windows 10 version 1703 (Creators Update) in April 2017, enhancing safeguards against control-flow hijacking in kernel code. Microsoft's eXtended Flow Guard (XFG), previewed in 2019 as an evolution of CFG, incorporates hash-based function signatures to provide finer-grained validation of indirect calls by matching caller-callee prototypes, thereby addressing limitations in bitmap-only checks for external function calls. Although prototyped and documented in tools like MSVC, XFG has not been fully released or enabled by default in Windows as of 2025, remaining in experimental stages to balance security gains with performance overheads. In the , control-flow integrity support emerged around 2020 through compiler instrumentation, primarily via /Clang's CFI implementation, which enforces valid indirect branches and virtual calls at runtime to defend against code-reuse attacks. This integration allows kernel builds with CFI enabled using flags like -fsanitize=cfi, promoting adoption in distributions for improved exploit resistance without hardware dependencies. Browser runtimes have also adopted CFI enhancements; for instance, the V8 JavaScript engine in Chromium integrated Pointer Authentication Codes (PAC) for control-flow integrity in October 2023, signing return addresses and indirect branches on ARM64 architectures to prevent manipulation in JavaScript execution. This runtime protection complements OS-level checks by securing dynamic code paths in web applications. Android's runtime environment enforces CFI through LLVM/Clang, which became the default compiler in 2014, with CFI specifically enabled by default in Android Pie (2018) for key components like media frameworks, Bluetooth, and NFC to handle dynamic loading policies across shared libraries via cross-DSO CFI schemes that relax strict link-time target knowledge. This approach ensures integrity during library loading and execution, reducing vulnerabilities in modular apps without disabling the feature in production builds.

Limitations and Challenges

Bypass Methods

Control-flow integrity (CFI) protections, while effective against many control-flow hijacking attacks, have been circumvented through various software and hardware bypass techniques that exploit limitations or auxiliary vulnerabilities. These methods often leverage imprecisions in the enforced (CFG), non-control data manipulations, or hardware-specific weaknesses, allowing attackers to redirect execution without violating core CFI checks. Research has demonstrated that such bypasses remain a significant challenge, particularly for coarse-grained CFI schemes that permit broad equivalence classes of valid targets. Software-based bypasses frequently target non-CFI gadgets or structural features in modern languages and compilers. Data-only attacks, for instance, manipulate program data structures to alter behavior without altering control flow, thereby evading CFI's focus on code pointers and indirect branches. These attacks corrupt sensitive data like function pointers in heaps or global offset tables, enabling unauthorized operations while respecting the program's CFG. A seminal example involves exploiting memory corruption to modify data-oriented state, such as kernel page tables, which CFI alone cannot prevent due to its lack of data integrity enforcement. More recent advancements include Coroutine Frame-Oriented Programming (CFOP), a 2025 code-reuse technique that hijacks C++ frames to bypass CFI in major compilers like , GCC, and MSVC. CFOP exploits the fact that coroutine frames contain unchecked or weakly protected code pointers, allowing attackers to construct gadgets from coroutine suspension and resumption logic, even under fine-grained CFI policies. This method succeeds by chaining frame manipulations to redirect subtly, demonstrating vulnerabilities in how compilers handle asynchronous execution constructs. Hardware-assisted CFI implementations, such as Intel's Control-flow Enforcement Technology (CET) and ARM's Pointer Authentication Codes (PAC), introduce additional bypass vectors through physical or speculative attacks. For PAC, fault injection and side-channel techniques can leak authentication keys, enabling attackers to forge valid pointers. The attack, for example, uses to extract PACs from pointers, allowing reconstruction of authenticated control-flow targets and facilitating hijacking despite PAC's cryptographic signing. Similarly, CET's Indirect Branch Tracking (IBT) can be evaded via endbranch spoofing, where attackers forge ENDBRANCH instructions or use counterfeit objects to mimic valid targets. Techniques like Counterfeit Object-Oriented Programming (COOP) exploit type confusion to redirect IBT-protected calls to unauthorized gadgets, bypassing the requirement for legitimate ENDBRANCH markers at branch destinations. Mitigation gaps in CFI often stem from partial policies that overlook or enforce overly permissive CFGs, enabling classic es documented in early . Coarse-grained CFI, which groups targets by broad types or modules, suffers from CFG errors, allowing attacks like control-flow bending that warp indirect calls within equivalence classes to unintended locations. Between and , papers highlighted vulnerabilities such as loop-oriented programming (LOP), which chains loops as gadgets to both coarse CFI and shadow stacks by avoiding direct returns. Another example is the exploitation of stack attacks to manipulate return addresses before CFI checks, undermining even 64-bit implementations. These gaps persist in s lacking comprehensive CFI, where non-control remains unprotected, amplifying the impact of memory errors. The evolution of CFI bypasses reflects ongoing adversarial adaptations, with coarse-grained schemes proving particularly vulnerable in real-world scenarios. Studies indicate that a substantial portion of memory corruption vulnerabilities, including those assigned CVEs in , can bypass coarse CFI due to its permissive policies, though exact figures vary by deployment. Fine-grained CFI and hardware mechanisms like PAC reduce successful bypass rates significantly, often to under a quarter of coarse-grained cases, by tightening target validations and integrating cryptographic checks. However, hybrid attacks combining software gadgets with hardware leaks continue to challenge even advanced protections, underscoring the need for layered defenses.

Performance and Overhead

Control-flow integrity (CFI) mechanisms introduce performance overheads that vary based on implementation granularity, ranging from coarse-grained approaches with minimal impact to fine-grained ones with higher costs. Software-based CFI typically increases code size by 10-30%, as adds checks and metadata for validating indirect branches and control transfers. For instance, modular CFI (MCFI) reports an average 17% code size increase across benchmarks, while fine-grained variants like FineIBT show 2-19% growth depending on the program. Runtime overheads on SPEC CPU benchmarks span 5-50%, influenced by check frequency and optimization level; the original CFI implementation averaged 16% slowdown (0-45% range), whereas optimized CFI achieves about 1% on SPEC CPU 2006. Coarse-grained CFI tends toward the lower end (e.g., 0.78% for slot-based forward-edge enforcement), while fine-grained policies can reach 8-10% or more, such as 8.54% for binary-level CFI or 7.6% for origin-sensitive CFI. Several factors modulate these overheads. Link-time optimization (LTO) enhances CFI precision but extends compile times significantly, as it enables whole-program analysis for better indirect call resolution. Hardware-assisted CFI substantially reduces costs: Intel Control-flow Enforcement Technology (CET) with Indirect Branch Tracking (IBT) limits runtime impact to 1-7% in fine-grained setups, while Pointer Authentication Codes (PAC) yield under 0.5% average overhead for pointer integrity checks and as low as 2.5% in kernel contexts. On mobile devices, these hardware features minimize battery drain compared to software-only approaches, though frequent PAC signing can still add minor energy costs in pointer-heavy workloads. Recent analyses of deployed binaries highlight practical measurements. Tools like SeeCFI, introduced in 2025 to detect CFI adoption, underscore that real-world slowdowns average around 15% in instrumented applications, aligning with historical benchmarks but varying by deployment scale. Optimizations such as (PGO) mitigate this by informing devirtualization and inlining, reducing forward-edge CFI overheads in GCC and LLVM implementations through runtime profile data. Trade-offs in CFI design balance security and efficiency: coarse-grained variants suit legacy systems with low overhead (e.g., <5% runtime) but weaker protection, while fine-grained enforcement for critical applications offers robust integrity at higher costs (10-30% combined), prioritizing security in high-value targets like servers or embedded systems.

References

  1. https://users.soe.ucsc.edu/~abadi/Papers/cfi-tissec-revised.pdf
  2. https://arxiv.org/pdf/1706.07257
  3. https://dl.acm.org/doi/10.1145/2594291.2594295
  4. https://dl.acm.org/doi/10.1145/3702982
  5. https://dl.acm.org/doi/10.1145/3607199.3607239
  6. https://dl.acm.org/doi/10.1145/1102120.1102165
  7. https://dl.acm.org/doi/10.1145/1609956.1609960
  8. https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_zhang.pdf
  9. https://learn.microsoft.com/en-us/windows/win32/secbp/control-flow-guard
  10. https://grsecurity.net/effectiveness_of_intel_cet_against_code_reuse_attacks
  11. https://v8.dev/blog/control-flow-integrity
  12. https://es.cs.rptu.de/publications/datarsg/Hemm24.pdf
  13. https://crypto.stanford.edu/cs155old/cs155-spring11/lectures/03-ctrl-hijack.pdf
  14. https://users.ece.cmu.edu/~dbrumley/courses/18487-f13/powerpoint/03-controlflow-attack.pdf
  15. https://www.cs.cornell.edu/courses/cs5431/2017sp/Lec2-CFI.pdf
  16. https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/bade/documents/products-and-services/en-us/security/sfi-nov-2025-progress-report.pdf
  17. https://learn.microsoft.com/en-us/defender-endpoint/exploit-protection-reference
  18. https://hovav.net/ucsd/dist/rop.pdf
  19. https://www.comp.nus.edu.sg/~liangzk/papers/asiaccs11.pdf
  20. https://www.usenix.org/system/files/usenixsecurity25-bajo.pdf
  21. https://www.cs.columbia.edu/~suman/secure_sw_devel/p340-abadi.pdf
  22. https://www.ieee-security.org/TC/SP2014/papers/OutOfControl_c_OvercomingControl-FlowIntegrity.pdf
  23. https://arxiv.org/pdf/1602.04056
  24. https://personal.utdallas.edu/~hamlen/Papers/icfem05-cfi.pdf
  25. https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-davi.pdf
  26. https://arxiv.org/abs/1810.10649
  27. https://www.seclab.cs.sunysb.edu/lszekeres/Papers/Zhang-2013-CCFIR.pdf
  28. https://nebelwelt.net/files/16EUROSP.pdf
  29. https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/carlini
  30. https://dl.acm.org/doi/10.1007/978-3-319-20550-2_8
  31. https://www.usenix.org/system/files/sec19-khandaker.pdf
  32. https://www.usenix.org/system/files/sec19fall_liljestrand_prepub.pdf
  33. https://arxiv.org/pdf/2104.14993
  34. https://nebelwelt.net/files/15DIMVA.pdf
  35. https://security.di.unimi.it/download/COOP-Oakland15_1.pdf
  36. https://arxiv.org/abs/1811.03165
  37. https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-tice.pdf
  38. https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-kuznetsov.pdf
  39. https://clang.llvm.org/docs/ShadowCallStack.html
  40. https://research.google.com/pubs/archive/43809.pdf
  41. https://clang.llvm.org/docs/ControlFlowIntegrity.html
  42. https://clang.llvm.org/docs/PointerAuthentication.html
  43. https://lwn.net/Articles/977720/
  44. https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html
  45. https://www.redhat.com/en/blog/fighting-exploits-control-flow-integrity-cfi-clang
  46. https://www.intel.com/content/www/us/en/developer/articles/technical/technical-look-control-flow-enforcement-technology.html
  47. https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/client/platforms/alder-lake-desktop/12th-generation-intel-core-processors-datasheet-volume-1-of-2/010/intel-control-flow-enforcement-technology/
  48. https://kib.kiev.ua/x86docs/Intel/CET/334525-003.pdf
  49. https://docs.kernel.org/next/x86/shstk.html
  50. https://windows-internals.com/cet-on-windows/
  51. https://www.phoronix.com/news/Intel-CET-IBT-For-Linux-5.18
  52. https://www.phoronix.com/news/Linux-6.4-Shadow-Stack-Coming
  53. https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/pointer-auth-v7.pdf
  54. https://developer.arm.com/documentation/110389/latest/
  55. https://blog.ssg.aalto.fi/2019/06/protecting-against-run-time-attacks.html
  56. https://sit-cybersecurity.com/exploit-development-unveiling-windows-arm64-pointer-authentication/
  57. https://developer.apple.com/documentation/security/preparing-your-app-to-work-with-pointer-authentication
  58. https://web.eng.fiu.edu/gaquan/Papers/ESWEEK24Papers/EMSOFT/EMSOFT_92_Ostapyshyn
  59. https://pointer-authentication.github.io/
  60. https://www.blackhat.com/docs/us-15/materials/us-15-Zhang-Bypass-Control-Flow-Guard-Comprehensively-wp.pdf
  61. https://www.crowdstrike.com/en-us/blog/state-of-exploit-development-part-1/
  62. https://i.blackhat.com/BH-USA-25/Presentations/USA-25-McGarr-Out-Of-Control-KCFG-And-KCET.pdf
  63. https://blog.quarkslab.com/how-the-msvc-compiler-generates-xfg-function-prototype-hashes.html
  64. https://www.offsec.com/blog/extended-flow-guard/
  65. https://lwn.net/Articles/810077/
  66. https://android-developers.googleblog.com/2019/05/queue-hardening-enhancements.html
  67. https://source.android.com/docs/security/test/cfi
  68. https://www.usenix.org/system/files/woot24-becker.pdf
  69. http://www.cs.ucr.edu/~trentj/papers/secdev19.pdf
  70. https://pacmanattack.com/paper.pdf
  71. https://static1.squarespace.com/static/5c2f61585b409bfa28a47010/t/64fb2ce1e4c6f107868c1484/1694182627599/COOP.pdf
  72. https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-carlini.pdf
  73. https://ieeexplore.ieee.org/document/7345282/
  74. https://dl.acm.org/doi/10.1145/2810103.2813671
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.