Architectural Mimicry: Innovative Instructions to Efficiently Address Control-Flow Leakage in Data-Oblivious Programs

Architectural Mimicry: Innovative Instructions to Efficiently Address Control-Flow Leakage in Data-Oblivious Programs

Speakers: Hans Winderix, PhD Researcher, DistriNet Group, KU Leuven; Marton Bognar; Job Noorman; Lesly-Ann Daniel; Frank Piessens

Conference: IEEE S&P

YouTube: https://www.youtube.com/watch?v=qr9ICw5KnSw

Overview

In an era where the security of sensitive data is paramount, microarchitectural side-channel attacks pose a significant threat, particularly those targeting control-flow leakage. These attacks exploit subtle differences in a program's execution characteristics—such as timing, cache usage, or branch predictor state—to infer secret information based on which path a conditional branch took. The talk "Architectural Mimicry: Innovative Instructions to Efficiently Address Control-Flow Leakage in Data-Oblivious Programs" by Hans Winderix and his co-authors introduces a groundbreaking hardware-software co-design approach to fundamentally address this problem.

The core of their proposal, Architectural Mimicry (AM), is an Instruction Set Architecture (ISA) extension that empowers hardware to understand and enforce the security intent of applications. By introducing a new hardware primitive called mimic execution and specialized instruction qualifiers, AM provides a principled, secure, and efficient mechanism for hardening applications against control-flow leakage. This innovation tackles long-standing limitations of purely software-based countermeasures, offering substantial performance benefits and stronger, more durable security guarantees for data-oblivious programs across a wide range of processor architectures, from low-end microcontrollers to high-end systems with complex microarchitectural optimizations.

Background

▶ Watch: Introduction to control-flow leakage side-channel attacks (0:00)

The necessity for Architectural Mimicry stems from the persistent challenge of protecting sensitive computations from side-channel attacks. These attacks capitalize on unintended information leakage through shared computing resources or observable execution characteristics. Within this broad category, control-flow leakage attacks are particularly insidious. They aim to deduce the outcome of a secret-dependent branch by observing differences in execution time, contention for shared resources like a scheduler queue, or changes to shared microarchitectural state, such as that of a branch predictor. If the two sides of a conditional branch yield distinct observable characteristics, an attacker can infer which path was taken, thereby revealing information about the secret condition driving the control flow.

Traditionally, software-based techniques have been employed to harden applications against control-flow leakage. Two prominent methods are control-flow balancing and control-flow linearization.

• Control-flow balancing attempts to make both sides of a conditional branch produce identical microarchitectural observations. This involves adding "dummy computations" to the shorter or less resource-intensive path, ensuring that regardless of the branch outcome, the observable side-channel footprint remains constant. While effective for processors with simple, "low-end microarchitectural profiles" lacking modern optimizations like branch predictors or instruction caches, it becomes insecure on more sophisticated systems where these optimizations can reintroduce observable differences.
• Control-flow linearization, on the other hand, completely eliminates secret-dependent branches. It transforms the code such that instructions from both potential branches are always executed in a fixed order. A "predicate" is then used to ensure that only the instructions corresponding to the original branch's true outcome actually modify the program's architectural state. This technique is generally more robust on "higher-end systems" equipped with modern hardware optimizations.

Despite their utility, current software-only countermeasures suffer from several critical limitations:

1. Cross-layer vulnerabilities: Hardening typically occurs at the source code level. However, lower layers of the computing stack, such as compilers or the underlying hardware, are often unaware of the security intent embedded in the source code. This disconnect can lead to cross-layer vulnerabilities, where optimizations or implementations at these lower levels inadvertently break the security properties intended at the source level.
2. High performance overhead: Software-based hardening techniques frequently rely on inserting extra instructions and utilizing additional registers for dummy computations. This overhead can be substantial, leading to significant performance degradation, especially in performance-critical applications. The talk highlights that state-of-the-art software linearization can incur an overhead of up to 19% in code size alone.
3. Error-prone manual hardening: A common practice involves manually hardening security-critical code sections. This process is not only labor-intensive and error-prone but also tightly "couples the security policy to the source code." This creates a brittle dependency, as the actual information leaks are dictated by the underlying hardware implementation, not solely the source code.
4. Suboptimal adversary model: To ensure security, developers are often forced to adopt a conservative adversary model, assuming that control flow always leaks. This might be suboptimal for certain processors, such as microcontrollers, which might require less stringent countermeasures due to their simpler microarchitectures. This "one-size-fits-all" approach can lead to unnecessary performance penalties.

These limitations underscore the need for a more integrated and principled approach, one that involves the hardware in enforcing security policies and provides a more efficient and robust defense against control-flow leakage.

Key Findings

▶ Watch: Introducing Architectural Mimicry and its goals (4:00)

The work presented in "Architectural Mimicry" delivers a set of crucial contributions designed to overcome the shortcomings of existing side-channel countermeasures:

1. Hardware-Software Co-Designed Solution: The central finding is the development of a novel hardware-software co-design solution. Unlike prior software-only approaches, Architectural Mimicry brings the hardware into the security loop, offering a more secure and significantly more efficient alternative to the state-of-the-art. This co-design ensures that the hardware is aware of and actively participates in enforcing the program's security intent.

1. Mimic Execution Primitive: A foundational contribution is the introduction of mimic execution, a new hardware primitive. This primitive allows the processor to imitate the microarchitectural behavior of an instruction—such as causing cache accesses, branch predictor updates, or specific timing characteristics—without actually modifying any architectural state (e.g., registers or memory). This is a more fundamental approach than the "clever tricks" of dummy computations used in software countermeasures, providing precise control over microarchitectural observations.

1. Architectural Mimicry (AM) ISA Extension: Building upon mimic execution, the researchers propose Architectural Mimicry (AM) as an ISA extension. This extension provides a convenient and principled way for software to control mimic execution. It defines a new processor mode, specific status registers, and a set of instruction qualifiers that dictate how individual instructions should behave under different execution contexts, effectively decoupling the security policy from the raw source code.

1. Evaluated Implementation: The team provides a concrete implementation of AM on an open-source processor. This implementation was used to rigorously evaluate the security, performance, and hardware cost of their proposal. The evaluation demonstrates substantial performance benefits and reasonable hardware overhead, proving the practicality of AM for both low-end and high-end processors.

1. Formalized Programming Models: Finally, the talk details and formalizes programming models that illustrate how to correctly and securely implement control-flow balancing and control-flow linearization using the AM ISA extension. These models are backed by formal properties—well-behaved property, security property, and correctness property—ensuring that the use of AM instructions is sound and predictable under defined conditions.

Technical Deep Dive

▶ Watch: Key contributions: Mimic Execution and ISA Extension (5:00)

Architectural Mimicry (AM) is implemented as an ISA extension, providing fine-grained control over instruction execution to prevent control-flow leakage. The extension introduces a new processor mode, status registers, and instruction qualifiers.

At its core, AM features a new processor mode called mimicry mode. When the processor is operating in mimicry mode, standard instructions are "mimicked." This means they generate the same microarchitectural events (e.g., cache accesses, branch predictor interactions, pipeline stalls) as if they were executed normally, but crucially, they do not update any architectural state, such as general-purpose registers or memory. This allows for precise control over side-channel observations without altering the program's intended data flow.

To control this behavior from software, AM defines three status registers and five instruction qualifiers. Each assembly instruction can be associated with an instruction qualifier, written before the instruction mnemonic, which determines its exact behavior. The five qualifiers are:

1. Activating qualifier: Typically associated with conditional branches, this qualifier is used to conditionally activate or deactivate mimicry mode based on a secret-dependent condition.
2. Standard qualifier: Instructs the CPU to execute an instruction normally when in standard mode and to mimic it when in mimicry mode.
3. Ghost qualifier: Performs the inverse of the standard qualifier. The instruction is mimicked when the CPU is in standard mode and executed normally when in mimicry mode.
4. Mimic qualified: These instructions are always mimicked, regardless of the current processor mode.
5. Persistent qualified: These instructions are always executed normally, regardless of the current processor mode.

Let's illustrate how these qualifiers are leveraged for hardening techniques:

Control-Flow Balancing with AM

For control-flow balancing, the goal is to ensure that both paths of a secret-dependent branch yield identical side-channel observations. Consider an unbalanced conditional branch where one path (e.g., "taken") has fewer instructions than the other ("not taken"). To balance this, AM allows the insertion of mimic instructions. For example, if the "not taken" path contains an ad instruction and a jump, the "taken" path can be augmented with a mimic ad instruction and a standard jump. The mimic ad will produce the same microarchitectural footprint as the ad in the other path without affecting architectural state, while the standard jump ensures both jumps are executed normally, balancing the control flow.

Control-Flow Linearization with AM

Control-flow linearization with AM involves transforming a conditional branch into a structure where both potential execution paths are traversed, with mimicry mode controlling which instructions actually modify state.

An insecure conditional branch if (secret == 0) { ... } else { ... } is rewritten into two activating branches with opposite conditions.

For instance:

1. An activating branch checks secret == 0. If true, mimicry mode is activated for the subsequent block of instructions (corresponding to the else path of the original branch). If false, standard execution continues.
2. A second activating branch checks secret != 0. If true, mimicry mode is activated for its subsequent block (corresponding to the if path of the original branch).

Consider an example: if secret != 0, the first activating branch (checking secret == 0) will not activate mimicry mode. The instructions in its block will be executed normally. When the CPU reaches the then label, mimicry mode is deactivated. The second activating branch (checking secret != 0) will then activate mimicry mode, causing the instructions in its block to be mimicked. This ensures that the microarchitectural observations are consistent, but only the instructions relevant to secret != 0 actually modify the program's state.

Correctness and Security Challenges

Implementing linearization correctly and securely with AM requires careful consideration:

• Correctness Property: An activating region is correct only if the instructions within it, when executed in mimicry mode, do not affect the live state of the program. This becomes particularly challenging for memory operations like store instructions. A store cannot be simply mimicked without a mimicry-aware memory subsystem, as a memory write inherently changes architectural state. To preserve correctness, AM employs a clever trick: if a store instruction appears in an activating region, it must be associated with the persistent qualifier. To prevent this persistent store from incorrectly modifying the live state when mimicry mode should be active, a ghost load is added immediately before it. When the CPU is in standard execution mode, the ghost load is mimicked (ignored), and the new value is stored by the persistent store. However, when in mimicry mode, the ghost load is executed, loading the current memory value into a temporary register (e.g., T), and then the persistent store writes that same value back to memory. This ensures the memory location's value remains unchanged, preserving the live state while still producing the microarchitectural footprint of a store.

• Security Property: An activating region is secure only if its side-channel observations are independent of the processor mode. A subtle vulnerability can arise if address computations are not handled carefully. For example, if an ad instruction computes a memory address that is then used by a load and store, and this ad is only executed normally when mimicry mode is not active, the resulting memory accesses might differ (e.g., accessing address 0 vs. address 4). This difference in memory access patterns (e.g., hitting different cache lines) can leak control flow. To linearize such a branch securely, the address computation itself must be performed persistently using the persistent qualifier, ensuring that the address is always computed and the memory access pattern is identical, regardless of whether other instructions in the block are mimicked or executed.

Formalization

To provide strong guarantees, Architectural Mimicry's use is formalized around three key properties:

• The well-behaved property ensures that nested and recursive activations of mimicry mode function as intended without unexpected behavior.
• The security property formally defines the conditions under which the AM programming models for control-flow balancing and linearization are secure against microarchitectural side channels.
• The correctness property specifies when instructions, particularly in mimicry mode, do not affect the program's architectural result. The paper provides more detailed insights into this formalization.

Demo / Proof of Concept

▶ Watch: Technical details: Mimicry Mode and Instruction Qualifiers (7:00)

The practicality and effectiveness of Architectural Mimicry were demonstrated through its implementation on an open-source processor specifically designed for experimenting with hardware security extensions. The researchers developed two distinct implementations of AM to cater to different processor pipeline designs:

1. An in-order implementation: This version is suitable for simpler processors or for hardening balanced branches where instruction reordering is not a concern. It ensures that the control flow of balanced branches does not leak.
2. An out-of-order implementation: Designed for more complex, high-performance processors, this implementation allows only linearized branches to be securely executed. It addresses the challenges posed by dynamic scheduling and speculative execution common in modern CPUs.

For evaluation, the chosen processor core was configured with common features that are known sources of side-channel leakage, such as a branch predictor and a data cache. This setup allowed the researchers to realistically assess AM's ability to prevent information leakage through these channels.

The evaluation utilized a set of benchmark programs derived from related work in the field of side-channel countermeasures. Key metrics measured included:

• Code Size Overhead: For balanced code, AM demonstrated a modest improvement, performing only 1% point better than the state-of-the-art software-only solutions. However, for linearized code, AM showed hardly any overhead, a significant advantage compared to the 19% code size overhead typically observed with existing software-based methods. This indicates that AM can achieve strong security guarantees without bloating the executable.

• Execution Time Overhead: The impact of AM on execution time was particularly significant for linearized forms. On average, AM reduced the hardening overhead by a remarkable 50% on the in-order pipeline and an even more impressive 60% on the out-of-order pipeline when compared to state-of-the-art software techniques. This drastic reduction in performance penalty makes robust side-channel protection far more practical for real-world applications.

• Hardware Overhead: The hardware cost of integrating AM was measured by synthesizing the design onto an FPGA. The results indicated that the additional hardware overhead was "reasonable." Crucially, the critical path of the processor did not increase, implying that AM can be integrated without negatively impacting the processor's clock frequency or overall performance capabilities. This demonstrates the practicality of the proposal for deployment on both low-end and high-end processors.

In summary, the demonstration and evaluation confirmed that Architectural Mimicry is not only theoretically sound but also practically viable, offering substantial performance gains and minimal hardware cost while providing robust security against control-flow leakage.

Defensive Implications

▶ Watch: Practical example: Balancing a secret-dependent branch using AM (8:00)

The introduction of Architectural Mimicry (AM) carries profound implications for defenders and system architects striving to build secure systems, particularly those handling sensitive data.

Firstly, AM provides a principled and provably secure countermeasure against control-flow leakage attacks. By bringing the hardware into the loop, it addresses the fundamental issue of cross-layer vulnerabilities that plague software-only solutions. Developers can now specify security intent at a higher level, confident that the underlying hardware will enforce it without being subverted by compiler optimizations or microarchitectural specifics. This leads to more robust and durable security guarantees.

Secondly, the significant reduction in performance overhead (50-60% for linearized code) makes side-channel hardening far more practical for real-world, performance-critical applications. Historically, the performance penalty of strong side-channel protections has been a major barrier to their widespread adoption. AM's efficiency improvements can enable a broader range of applications, from embedded systems to cloud computing, to operate securely without prohibitive performance costs. This is particularly important for data-oblivious programs where constant-time execution is a requirement.

Thirdly, AM decouples the security policy from the source code. Instead of relying on error-prone manual code transformations, developers can leverage the AM ISA extension and its specialized instruction qualifiers to inform the hardware directly about security-critical regions. This approach is less prone to human error and makes the security properties more resilient to changes in compilers or underlying hardware implementations.

Finally, AM offers flexibility by supporting both control-flow balancing and control-flow linearization in a secure manner. This allows system designers to choose the most appropriate hardening strategy based on the specific processor architecture (e.g., low-end microcontrollers versus high-end CPUs with complex microarchitectural features) and the desired security-performance trade-offs, rather than being forced into a conservative, suboptimal approach.

For defenders, the emergence of AM signifies a potential shift towards more secure and efficient hardware-assisted side-channel protection. While it requires new hardware support, its benefits in terms of security, performance, and development ease make a compelling case for its adoption in future processor designs, ultimately raising the bar for attackers attempting to exploit microarchitectural side channels.

Key Takeaways

• Current software-only countermeasures for control-flow leakage attacks are prone to cross-layer vulnerabilities, incur high performance overhead, and are difficult to implement correctly.
• Architectural Mimicry (AM) is a novel hardware-software co-design solution that introduces mimic execution as a hardware primitive and an ISA extension with specialized instruction qualifiers (activating, standard, ghost, mimic, persistent).
• AM enables principled, secure, and efficient control-flow balancing and control-flow linearization by allowing the CPU to imitate microarchitectural events without changing architectural state.
• The implementation of AM on an open-source processor demonstrated significant performance benefits, reducing hardening overhead by 50% on in-order and 60% on out-of-order pipelines compared to state-of-the-art software, with negligible hardware cost.
• AM provides stronger security guarantees by informing the hardware about application security intent, addressing complex issues like handling store instructions with ghost loads and ensuring persistent address computations.
• This approach encourages portability and allows for a more optimal choice of hardening techniques (balancing vs. linearization) across diverse processor architectures, making robust side-channel protection more practical for data-oblivious programs.

About the Speaker(s)

The primary presenter of this work was Hans Winderix, a PhD researcher associated with the DistriNet group at KU Leuven. He was joined by his co-authors Marton Bognar, Job Noorman, Lesly-Ann Daniel, and Frank Piessens. Their collective research focuses on advancing hardware security extensions and developing robust defenses against microarchitectural side-channel attacks.