Processor Trace Control Flow Integrity Validation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing control flow integrity validation techniques require source code modification and/or binary re-instrumentation, incur performance penalties, and provide limited accuracy in detecting control flow hijacking attacks, such as ROP and JOP, due to their coarse-grained or fine-grained validation methods.
Innovation Solution
The system utilizes processor trace data and a control flow graph to detect control flow integrity violations in real-time by capturing and analyzing execution traces, determining whether control flow transfers adhere to legitimate paths, and employing a control flow validator to identify potential attacks before malicious application launch.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If existing CFI validation techniques are used, then control flow hijacking attacks can be detected, but source code modification and binary re-instrumentation are required
Solution Approach 1:
The patent introduces processor trace (PT) circuitry as an intermediary component that captures execution traces at the hardware level. This mediator enables CFI validation without requiring modifications to the application binary or source code, as the PT circuitry independently monitors control flow transfers and compares them against the control flow graph.
Solution Approach 2:
The patent replaces the mechanical/software-based approach of binary re-instrumentation with a hardware-based processor trace mechanism. By substituting the software instrumentation process with hardware-level trace capture, the system eliminates the need for binary modification while maintaining attack detection capability.
2Reliability
If existing CFI validation techniques are used, then control flow transfers can be validated, but performance penalty is incurred
Solution Approach 1:
The processor trace circuitry acts as a dedicated hardware intermediary that captures execution traces without interfering with the normal application execution path. The trace capture occurs at the hardware level in parallel with application execution, allowing validation to proceed without adding software overhead that would slow down the application.
Solution Approach 2:
The system validates control flow transfers by periodically checking execution traces against the control flow graph at indirect branch points. This periodic validation approach, implemented through hardware trace capture, provides continuous security monitoring while minimizing disruption to application performance compared to continuous software-based validation.
3Reliability
If existing CFI validation techniques are used, then some attacks can be detected, but accuracy is limited due to coarse-grained or fine-grained validation
Solution Approach 1:
The patent segments the control flow validation process into fine-grained basic blocks, where each node in the control flow graph represents a basic block with a single entry and exit point. This segmentation allows precise tracking of control flow transfers at the instruction level, enabling accurate detection of hijacked control flow while maintaining manageable complexity through the structured graph representation.
Data Source
AI summary
One embodiment provides an apparatus. The apparatus includes collector circuitry to capture processor trace (PT) data from a PT driver. The PT data includes a first target instruction pointer (TIP) packet including a first runtime target address of an indirect branch instruction of an executing target application. The apparatus further includes decoder circuitry to extract the first TIP packet from the PT data and to decode the first TIP packet to yield the first runtime target address. The apparatus further includes control flow validator circuitry to determine whether a control flow transfer to the first runtime target address corresponds to a control flow violation based, at least in part, on a control flow graph (CFG). The CFG including a plurality of nodes, each node including a start address of a first basic block, an end address of the first basic block and a next possible address of a second basic block or a not found tag.