Control flow integrity
Detecting control-flow deviation from a separate execution domain - and holding outputs back until the window between attack and detection is closed.
Watching from outside
Software-based control flow integrity puts a checker inside the system it is checking. That is a structural weakness: in-process checks share the protected execution environment and may themselves become targets of control-flow diversion or data corruption - their resilience depends on the enforcement architecture, protected state and attack model. The monitoring also costs runtime on the very system whose timing budget is already tight.
Trace-based CFI does not have that shape. The expected control flow is known from the binary. The actual control flow arrives over the trace port. Moving the monitor outside the application execution domain removes the need for an in-process check that an attacker might skip by diverting control flow. The monitor, trace configuration, expected-flow model, communication path and response mechanism remain security-relevant assets and must be protected accordingly.
The monitor is implemented in a separate hardware or execution domain from the protected application. The strength of that separation depends on the actual SoC, board, debug and management architecture; it must not be inferred from physical separation alone. The application executes no in-process CFI checks in the passive external-monitor configuration; the trace source, transport and system response still consume implementation resources and may have platform-specific power, bandwidth or latency effects.
Numbered threat markers from the figure: assumption or control, and what remains open.
| # | Threat | Assumption / control | Residual limit |
|---|---|---|---|
| 1 | disable or reconfigure the trace source | trace-configuration identity is checked; loss of the stream is itself a detectable event | a window until detection; protection of the trace control registers is an SoC property |
| 2 | saturate the trace path | bandwidth budgeting; overflow and loss are signaled on the validity channel | during a loss interval, detection degrades to a reported gap, not to silent coverage |
| 3 | spoof the model or an update | authenticated provisioning and update channel | key handling and update process security sit outside the monitor |
| 4 | compromise the monitor itself | separate hardware with a deliberately small attack surface | supply chain and management access of the monitor remain in the trust base |
| 5 | data-only attack, no control-flow deviation | outside the scope of control-flow monitoring | needs complementary controls; external CFI does not claim to cover it |
| 6 | malicious but allowed path | detection quality is bounded by the policy / model | model completeness is an assumption, stated with the deployment |
| 7 | response arrives too late | detect, decide and respond are separate stages with a stated latency budget | whether the budget is adequate depends on the hazard, not on the monitor |
What it detects
Deviation. A branch that should not have been taken, a return to an address that is not on the call stack, a jump into the middle of a function. Whether the cause was an attack, memory corruption or a genuine bug is a question for the analysis afterwards; the detection is the same.
The window between attack and detection
Every monitor - internal or external - has a detection latency: the span between the moment the control flow first deviates and the moment the anomaly is recognized. Knowing that an attack happened is useful. Knowing that the attack did not lead to the disclosure of sensitive data or the release of a manipulated control command is what actually protects the system - and that is decided entirely inside this window.
The patented arrangement therefore does not stop at detection. Its central element is a controllable latency output buffer, placed outside the observed processor’s writable domain, that holds the processor’s outbound data - responses, payloads, control commands - for a configurable latency span. That separation is an integration property: it must be enforced by the concrete SoC, board, debug and management architecture. Only when the monitor has raised no anomaly by the end of that span is the output released; the moment an anomaly is raised, the pending output is blocked. Detection becomes containment: a control-flow attack that is recognized within the window never becomes an effect outside the system.
This changes what a deviation report means in practice. Without output gating, “attack detected” is the beginning of an incident investigation into what may already have leaked. With output gating, for the outputs routed through the buffer and a latency span that covers the detection latency, the answer is already part of the mechanism: the withheld output never left.
The security assumptions, detection limits, trace-loss policy and model-update controls belong to any deployment discussion and are stated in full in the technical documentation for the configuration under review.
Patent status
This one is granted: EP 4 016 343 B1 and US 12,462,017 B2. The granted patents describe an arrangement that includes non-intrusive observation, an execution monitor outside the observed processor’s execution domain, and a controllable output-latency mechanism that gates outputs on the monitor’s verdict. The precise claim scope is defined by the granted claims and is best assessed from the official patent records. Details on the patents page - including the detail that this specification cites our two decoder patents as prior art, which is a reasonable summary of how the two lines relate.
Research context
How this hardware-level view combines with software-level, model-based attack identification is the subject of a joint preprint with the University of Lübeck and OTH Regensburg: Towards Model-based Run-time Cybersecurity: On Control-Flow Anomaly Detection, Attack Identification, and Hardware Monitoring (arXiv preprint, August 2026). The paper cites the granted arrangement above as the concrete instantiation of its hardware monitor, and its worked authentication-service example shows how independent hardware observation turns an ambiguous software-level diagnosis into a high-confidence identification of code injection or control-flow hijacking. More of our scientific work is listed under publications.