Control-Flow Attestation: Concepts, Solutions, and Open Challenges

Control-Flow Attestation: Concepts, Solutions, and Open Challenges
Zhanyu Shaa,∗ , Carlton Shepherdb , Amir Rafia and Konstantinos Markantonakisa

a Information Security Group, Royal Holloway, University of London, Egham, Surrey, United Kingdom
b School of Computing, Newcastle University, Newcastle-upon-Tyne, Tyne and Wear, United Kingdom
ARTICLE INFO ABSTRACT

Keywords: Control-flow attestation (CFA) unifies the worlds of control-flow integrity and platform attestation
Control-flow attestation by measuring and reporting a target’s run-time behaviour to a verifier. Trust assurances in the
Hardware-assisted security target are provided by testing whether its execution follows an authorised control-flow path. The
Trusted computing problem has been explored in various settings, such as assessing the trustworthiness of cyber-physical
systems, Internet of Things devices, cloud platforms, and many others. Despite a significant number of
arXiv:2408.06304v1 [cs.CR] 12 Aug 2024
proposals being made in recent years, the area remains fragmented, addressing different adversarial
behaviours, verification paradigms, and deployment challenges. In this paper, we present the first
survey of control-flow attestation, examining the core ideas and solutions in state-of-the-art schemes.
In total, we survey over 30 papers published between 2016–2024, consolidate and compare their key
features, and pose several challenges and recommendations for future research in the area.
1. Introduction from ,  creates a measurement that is an aggregation

of different steps in the resulting program execution. These
Today’s computing platforms are susceptible to attacks ‘steps’ may correspond to the different nodes that were
manipulate software behaviour at run time. Control-flow at- traversed within the target’s control flow graph (CFG), where
tacks, such as return-oriented programming (ROP), have be-  knows the set of legitimate paths before ’s deployment.
come commonplace that execute unintended program code In recent years, a large number of CFA schemes have
paths in order to perform unauthorised functions using ex-
been proposed in the literature, focussing on different mea-
isting code fragments. These fragments are combined in
surement approaches, roots of trust, adversarial models, and
sequence in a way that evades conventional defences, such hardware and software assumptions. For instance, different
as code signing and other static integrity-checking methods. hardware security technologies have been suggested for pro-
The challenge of run-time threats has underpinned the area tecting ’s measurement and reporting procedures [4, 5, 6,
of control-flow integrity (CFI), which aims to ensure that 7]; various static and dynamic methods have been proposed
programs adhere to authorised paths of execution [1]. This
for program instrumentation [4, 8, 9, 10, 11]; and numerous
can be achieved, for example, by verifying the legitimacy of control-flow transfer types have been monitored [7, 10, 12,
the destination address of every control-flow transfer (e.g. 13, 14]. Despite receiving significant attention from the
jump and call instructions). Other mechanisms have also research community, no survey exists that consolidates and
been developed, such as code pointer integrity (CPI) [2], reflects on the state of the art. In this paper, we address
which segregates pointers from other data in memory; and
this gap through a comprehensive review of existing CFA
data execution prevention (DEP), which prevents code from
proposals and make the following contributions:
being executed from regions of memory that are not explic-
itly marked as executable. • We present the first systemisation of knowledge paper
In this paper, we concern ourselves with the problem on control-flow attestation, covering over 30 CFA
of control-flow attestation (CFA). In general, CFA schemes proposals over approximately the last decade since
aim to bridge the problems of CFI and platform attestation CFA was first introduced in the literature.
by building assurances that a target device has not been
compromised at run-time. This contrasts to conventional re- • We consolidate the knowledge areas explored in state-
mote attestation that relies on measuring static components, of-the-art CFA schemes, and describe their applica-
such as bootloaders and other software binaries [3]. CFA tion in existing proposals.
overcomes the limitations of static attestation, which cannot
• Using a common set of criteria, we compare exist-
reliably detect run-time attacks after any measurements have
ing CFA schemes with respect to their trust assump-
been taken. A typical CFA scheme involves a proving device,
tions, target control-flow transfers, attack coverage,
, and a challenger or verifier, . Given an input challenge
and other salient features in order to elucidate their
⋆
Carlton Shepherd has received funding from the UK EPSRC features, advantages, and shortcomings.
‘Chameleon’ project (EP/Y030168/1).
∗ Corresponding author
1.1. Related Work
zhanyu.sha.2020@rhul.ac.uk (Z. Sha); carlton.shepherd@ncl.ac.uk
(C. Shepherd); amir.rafi@rhul.ac.uk (A. Rafi);
To the best of our knowledge, no extensive survey cur-
k.markantonakis@rhul.ac.uk (K. Markantonakis) rently exists summarizing CFA schemes; however, several
ORCID (s): 0000-0001-7511-2910 (Z. Sha); 0000-0002-7366-9034 (C. existing papers survey remote attestation (RA) more gener-
Shepherd) ally in different contexts, which we summarise in Table 1.
Z. Sha et al.: Preprint submitted to Elsevier Page 1 of 26

Table 1 begin introducing the core ideas behind CFA in §3, such
An overview of related survey papers. as definitions and the knowledge areas of state-of-the-art
Work Year Description
proposals. We then systematically discuss each area of this
Steiner & Lupu [15] 2016 RA methods for wireless sensor networks.
taxonomy, discussing prover-verifier paradigms in §4; trust
Arias et al. [16] 2018 A brief review of device attestation methods. anchors in §5; and methods for instrumenting and measuring
Sfyrakis & Groß [17] 2020 Hardware methods for attesting network infrastructures.
Johnson et al. [18] 2021 A review of RA schemes for embedded systems. proving programs in §6 and §7. We consolidate existing CFA
Ankergård et al. [19] 2021 State-of-the-art software-based RA for IoT devices. proposals according to these features in §8 and present a
Kuang et al. [20] 2022 A general review of RA schemes for IoT devices.
Ambrosin et al. [21] 2022 Collective RA schemes for large IoT networks. comparison table to aid future research in the area. Lastly,
This Paper 2024 A comprehensive analysis of control-flow attestation. we present several open research problems and recommen-
dations in §9 before concluding the paper in §10.
In 2016, Steiner & Lupu [15] presented one of the first

surveys covering traditional remote attestation approaches 2. Fundamentals of Control-Flow Integrity
applicable to wireless sensor networks. Arias et al. [16] The goal of control-flow integrity is to ensure that a
(2018) provided a short review of device attestation methods given program follows only the intended code paths. Put
for IoT devices, touching principally on software, hard- otherwise, it aims to ensure that program execution adheres
ware, and swarm-based attestation in the static measurement to a set of policies. A typical method of enforcing CFI is
model. In 2020, Sfyrakis & Groß [17] reviewed different through the use of a control-flow graph (CFG) derived from
hardware approaches for attesting devices in network infras- the program’s source code, binary, or an intermediate rep-
tructures, such as those used in infrastructure-as-a-service resentation. A CFG represents all potential, and authorised,
solutions. In 2021, Johnson et al. [18] proposed a taxon- execution paths that a program can follow during its runtime.
omy of RA schemes for embedded systems, categorising A CFG for a given program, 𝑃 , can be represented as a
proposals according to their root of trust, evidence type, directed graph, 𝐺 = (𝑉 , 𝐸), where:
evidence gathering, packaging and verification, and scala-
bility. Ankergård et al. [19] examined software-only remote • 𝑉 is a set of vertices, where each vertex, 𝑣𝑖 ∈ 𝑉 ,
attestation schemes without relying on hardware-based roots represents an independent sequence of instructions.
of trust for IoT devices. Kuang et al. [20] (2022) survey re-
• 𝐸 is a set of edges where each edge is defined as a
mote attestation schemes for IoT devices in general, detailing
tuple, (𝑣𝑖 , 𝑣𝑗 ) ∈ 𝐸, representing a possible control
attestation proposals targeting different attacks (e.g. static
flow transfer between two vertices. Transfers can be
and run-time software attacks, and physical attacks). Lastly,
the result of function calls, returns, or (un-)conditional
Ambrosin et al. [21] review solutions in the area of collective
jumps in 𝑃 .
remote attestation, where multiple devices are attested as a
whole rather than individually. Vertices of a CFG are referred to as basic blocks (BBLs),
In some of these surveys [16, 18, 21], control-flow attes- which are considered an atomic sequence of program in-
tation is described briefly but not comprehensively, consid- structions with a single entry and exit point. The entry point
ering only early control-flow attestation schemes (e.g. [4, 8]). is the first instruction of a BBL, while the exit refers to the
They do not present a dedicated treatment to the large final instruction. A control-flow transfer instruction, such as
number of CFA proposals that have emerged over the past a branch or jump, is typically considered the last instruction
decade. We directly address this gap in this paper. Survey of a BBL. Other instructions within a BBL do not alter
papers on control-flow integrity more generally have also the control flow. As such, the execution of a BBL is linear,
been published on verification methods [22] and hardware- with each instruction following the previous one until the
based CFI systems [23]. We emphasise that CFI is a related final instruction. A control-flow transfer will have a source
concept necessary for understanding CFA schemes, but it is corresponding to the exit point of a BBL, and a destination
not directly concerned with attesting target platforms. that points to the entry point of a BBL. Given a control
This paper offers a comprehensive treatment of pro- transfer instruction at runtime from a point (𝑝) in a block (𝑣𝑖 )
posals that attest devices using run-time control-flow be- to a target address (𝑡), the transfer is allowed iff ∃(𝑣𝑖 , 𝑣𝑗 ) ∈ 𝐸
haviours. Specifically, we consider proposals that contain in the CFG such that 𝑡 is the starting address of block 𝑣𝑗 .
mechanisms for securely measuring and reporting the state When the CFI security property [1] holds for a given
of a proving device. Proposals that focus on detecting only program, 𝑃 , we say that 𝑃 adheres to an authorised walk,
control-flow integrity violations are considered useful sup- 𝑤 = {𝑣0 , 𝑣1 , … 𝑣𝑛 }, for a connected sequence of vertices
plementary literature, but they are orthogonal to this work. with starting and final vertices, 𝑣0 and 𝑣𝑛 respectively.1 For a
given program, the implementation of control-flow integrity
1.2. Paper Structure for a desired program is achieved generally in two phases:
We begin with preliminary information in §2, cover-
ing the principles behind control-flow integrity, the basics 1 Existing literature often refers to the term ‘path’, even though this can
of control-flow graphs, and control-flow and non-control- be considered a misnomer in graph theory. A path is a trail in which all
vertices (and thus all edges) are distinct, whereas a walk is more general: it
data attacks addressed by CFA schemes. After this, we is a finite or infinite sequence of edges which joins a sequence of vertices.

1. CFG construction: The target program’s CFG is com- e.g. through improper input validation and sanitisa-
puted using static or dynamic analysis or a combi- tion, which is subsequently executed.
nation thereof. Static analysis uses the program code
using its binary, source code, or an intermediate form Stack-based buffer overflows are a canonical example,
(cf. LLVM’s intermediate representation [24]). This which involves overwriting function return addresses and
process is used to identify all possible control flow other variables on the stack to redirect execution to code
transfers before its execution. In contrast, dynamic to a malicious payload (e.g. shellcode). Heap-based attacks
analysis builds the CFG through giving inputs and are another approach, involving overflowing buffers on the
logging program execution. heap and affecting adjacent heap metadata and objects (e.g.
function pointers) that redirect control flow.
2. CFI enforcement: This is performed at runtime and More modern attacks involve the concept of code reuse,
involves a reference monitor that checks and enforces which rely on unauthorised sequences of existing authorised
the program’s adherence to the CFG derived in the code fragments in order to realise malicious functionality.
previous step. A common CFI enforcement method is
through program instrumentation [1]. Here, a check- (A.2) Code reuse attacks: Redirects a program’s control
point 𝐶(𝑝, 𝑡) is inserted at a control transfer instruction flow to execute existing executable code sequences,
at point 𝑝 in BBL, with a target, 𝑡. Here, 𝑝 and 𝑡 or gadgets, in order to perform malicious operations.
represent a logical CFG edge between one BBL 𝑣𝑖 and These attacks are highly flexible and can be used to
a target BBL, 𝑣𝑗 . Before executing any control transfer bypass common protections, e.g. DEP and W⊕X,2
instruction, the program passes control to the refer- by using executable code already present in memory.
ence monitor that verifies whether 𝐶(𝑝, 𝑡) is associated
with (𝑣𝑖 , 𝑣𝑗 ) ∈ 𝐸. That is, the monitor ensures that the A common example of a code-reuse attack is return-
transfer complies with the CFG. If the check fails, the oriented programming (ROP) [26], which relies on return
monitor may half the program’s execution, throw an instructions to chain together a sequence of gadgets. Each
exception, or take another enforcement action. gadget typically concludes with a return instruction; the next
gadget in the sequence starts based on the tampered return
In practice, control-flow transfers are instigated by in- address of the previous one. It is widely known ROP attacks
structions that alter the normal sequential execution flow, can achieve Turing-completeness [27]. Jump- (JOP [28]) and
directing it from the current instruction to a different, non- call-oriented programming (COP [29, 30]) attacks are two
consecutive address in the program. A control-flow transfer other code reuse attacks, which involve tampering forward
has two main attributes: a source address and a destination control-flow transfers, namely indirect jumps and indirect
address. Transfers are divided into forward and backward calls respectively, in order to chain sequences of gadgets.
ones, which redirect execution to a new location and re-
turn execution to the prior location respectively. On X86 2.1.2. Non-Control Data Attacks
platforms, the call and ret instructions are two examples Rather than directly modifying control data, e.g. function
of such instructions. Forward control-flow transfers may pointers, non-control data attacks rely on the manipulation
further be categorised into direct and indirect calls and of more general data to indirectly change a program’s con-
jumps. Branching and jump instructions may be executed trol flow [31, 32, 33]. Detecting non-control-data attacks is
according to some condition, e.g. jz (jumps if the zero flag, more challenging because they technically traverse legiti-
ZF, is set) and jnle (jump if not less or equal). mate edges of the program’s CFG, even though malicious
functionality ensues as a consequence. Let us consider a
2.1. Control-Flow Attacks motivating example. An adversary may execute arbitrary
Control-flow integrity and attestation schemes aim to commands on a Linux system if they can influence the
address the problem of control-flow attacks that manipulate arguments to a execve() call in the target program. The
control-flow transfers in order to perform unauthorised ac- target program’s CFG is respected, even though the resulting
tions. In this section, we describe the common attack classes, behaviour is unauthorised. Data attacks can be realised in the
and label them for later comparison in §8. following ways:
2.1.1. Control Data Attacks (A.3) Direct data manipulation (DDM) attacks: Refers
The primary class are attacks that directly modify control to attacks that maliciously modify the data used in
data used to that directly influences the processor’s pro- decisions that affect a program’s control flow.
gram counter (PC) during execution by modifying return
addresses and function pointers [25]. A fundamental attack Branch variable attacks are an example of (A.3) in which
vector, which we refer to as code injection, involves inserting an adversary influences data used in determining the out-
malicious code into executable memory and redirecting the come of conditional branches, i.e. in ‘if’ and ‘switch’ state-
PC to that code. ments. The resulting data causes another legitimate branch
2 Write XOR Execute (W⊕X) is a security feature that ensures memory
(A.1) Code injection attacks: The attacker directly inserts
malicious code into the target program’s memory, regions are either writable or executable, but not both simultaneously.

;; Conditional direct jump (jump if equal)

cmp rax, rbx ; Compare RAX and RBX
je mylabel ; Jump to 'mylabel' if RAX = RBX
;; Unconditional direct jumps
jmp mylabel ; Jump to 'mylabel'
jmp 0x00401000 ; Jump to the address 0x00401000
;; Direct calls
call myfunc ; Call the function 'myfunc'
call 0x00401234 ; Call the function at 0x00401234
;; Indirect jumps
Figure 1: Some control- and data-flow target points from jmp rax ; Jump to an address in register RAX
Debes et al. [36]. An ‘impure DOP vulnerability’ corresponds to jmp [0x00401234] ; Jump to an address pointer 0x00401234
(A.3) if x or y is manipulated to enter the program’s ‘if’ block in jmp [rbx+rcx*4] ; Register-indirect jump with an offset
Line 1. Line 3 may be susceptible to code reuse attacks via code jmp [rsp] ; Jump to an address on the stack
injection (A.1) to divert execution (3 → 8) to (3 → 𝑋) or ROP ;; Indirect calls
(A.2) to achieve (3 → 2). Line 4 has a ‘pure DOP vulnerability’ call rax ; Call an address in RAX
(A.4) if the argument to broadcast() can be influenced. call [0x00401234] ; Call a function pointer at 0x00401234
call [rbx+4] ; Register-indirect call with an offset
call [rsp] ; Use the stack to call a function
;; Return instructions
to be taken, which nevertheless results in unintended be- ret
haviour.3 In a similar case, the adversary may attempt to
manipulate the data that is used in the termininating condi- Figure 2: X86-64 assembly examples of various control-flow
tion of loops, e.g. ‘while’ and ‘for’ statements. Such attacks transfer types.
may also involve manipulating the data of loop termination
conditions, which we refer to as a ‘loop variable attack’.
A generalisation of this concept has recently emerged.
performance overhead that this can occur, especially on
Data-oriented programming (DOP), first presented by Hu et
constrained devices. Indeed, not all control-flow transfers
al. [32], relies on chaining existing data gadgets in the data
are relevant to the security of a system, and it is intuitive
plane in order to perform malicious operations. The method
to monitor transfers that are common targets for particular
is capable of achieving Turing-completeness [32]. Since
exploits of interest. For example, one may wish to pay
these flows are part of the program’s intended behavior,
particular attention to indirect jumps and calls in order to
they do not trigger CFI violations that would be detected
address ROP and JOP attacks. In Figure 2, we give some
using conventional protections. Ispoglou et al. [33] later
examples of such transfers used by X86-64 platforms. We
introduced block-oriented programming (BOP) to assist with
now describe the control-flow transfer types have been used
the automation of data-oriented attacks by identifying and
in existing work:
using whole BBLs as data plane gadgets.
(C.1) All control-flow transfers: This is the most expan-
(A.4) Data-oriented attacks: Executes a sequence of ex-
sive definition of . We assume that  is a maximal
isting data gadgets on attacker-controlled inputs in
set, or has the greatest cardinality, for the target
order to perform malicious actions while respecting
architecture. In practice, all possible control-flow
the target program’s CFG.
instructions are examined—conditional jumps, di-
In Figure 1, we give some common points in which rect calls, indirect calls, etc.—imposing the greatest
control- and data-flow attacks may be used. In the literature, overhead during monitoring and measurement. It is
adversaries with the ability to perform data-oriented attacks also the most invasive, requiring the heaviest degree
are considered to be highly sophisticated [32, 34, 35]. We of instrumentation of the target program (see §6).
emphasise that, if no additional context-sensitivity is intro- Monitoring all control-flow transfers has been used
duced, or additional checks are performed on critical data in many existing proposals, with a heavy focus on
variables, then it is possible for non-control-data and DOP proposals requiring dedicated hardware detection cir-
attacks to bypass control-flow integrity mechanisms. cuits [9, 12, 34, 36, 37, 38, 39, 40, 41].
2.2. Control-Flow Transfer Types (C.2) Conditional direct branches/jumps: Includes all
In CFI and CFA, monitoring different control-flow trans- branching and jump instructions, represented as as-
fer types is used to detect particular unauthorised paths sembly or machine code, that alter the execution se-
within a target program. We note that it is often undesirable quence based on a specific condition. If the condition
to monitor every possible control-flow due to the significant is true, then the program counter is directly set to
a specified address, continuing execution from that
3 It is important to recognise this semantic gap: just because legitimate
address. In direct jumps, the target address or label
edges of a CFG are followed does not mean that unintended or unauthorised
is explicitly stated in the instruction. The address is
behaviour more abstractly can be performed.

fixed at compile time and does not change at runtime. 3. Introducing Control-Flow Attestation
A control-flow attestation scheme can be considered as
(C.3) Unconditional direct branches/jumps: Transfers C = (𝑇 , , , , 𝑉 ). The target program, 𝑇 , is executed
the control flow to a specified address or label without on the proving device, . The terms ‘attested program’ [4],
any condition using a jump instruction. jmp is the fun- ‘attestation program’ [46] and ‘selected program’ [47] are
damental mechanism for performing unconditional used synonymously in the literature.4 The proving device
direct jumps in X86-64 assembly. may execute other programs during attestation, and so we
adopt the term ‘target program’ from [34] for clarity.
(C.4) Direct calls: A direct call is used to invoke a subrou-  denotes the control-flow transfer types (e.g. direct
tine or function by specifying the name or address of jumps, indirect calls) being monitored, which were pre-
the subroutine in the instruction, e.g. call (X86-64). sented in §2.2. A general requirement is that CFA scheme
(C.5) Indirect branches/jumps: Indirect jumps allow the must be able to monitor unique information about a BBL
program to transfer control to an address that is com- associated with a single control-flow transfer type. During
puted at runtime, rather than a fixed address specified collection, this information may include the addresses of a
in the code. This can include jumping to an address BBL’s first and final instructions; the control flow transfer’s
stored within a register, e.g. jmp rax; on the stack; or source and destination addresses, which delineates different
at an address pointed to in memory. BBLs; a unique label identifying the BBL;5 and the type of
control-flow transfer and its complete instruction represen-
(C.6) Indirect calls: Similar to indirect jumps, indirect tation, e.g. as machine code.
calls invoke a function whose address is computed at  is the facility used to create measurements of the
run-time or stored in a register or memory location. control-flow followed by 𝑇 . We cover measurement tech-
niques, such as cryptographic hashes of CFG nodes, in §7.
(C.7) Return instructions: Return instructions are used  is the procedure for reporting the set of measurements
at the end of a function to return to the location of collected by  to the verifier, . This procedure usu-
the PC before the function was invoked. On X86, ally involves encrypting and signing collected control-flow
the instruction ret pops the top value from the stack, measurements, forming an attestation report. Lastly, 𝑉 is
which should be the return address pushed onto the the verification procedure used by  in order to determine
stack by a previous call instruction, before jumping whether the measurements correspond to those which are
to that address. expected, i.e. a known, authorised run taken by 𝑇 . A binary
decision model is assumed here: if the verification procedure
Some proposals apply different CFI policies depend-
fails, then it indicates the presence of adversarial behaviour
ing on the location of the code being examined with the
and that one of the attacks described in §2.1 was performed.
aim of reducing performance overhead. For example, by
Typically, 𝑇 , , and  are run on , while 𝑉 is run on .
dividing code into critical and non-critical functions through  is usually run on , but it may be used by both entities.
manual policy specification or using statistical and machine In Figure 3, we illustrate the knowledge areas that char-
learning-based models [5, 9, 11, 42]. For example, ARI [43]
acterise their core elements. We posit that schemes can be
divides code into critical and non-critical compartments
delineated according to their attestation paradigm; the trust
based on a policy set. All control-flow transfers are moni-
anchor; the instrumentation method for collecting measure-
tored except unconditional direct jumps within critical com-
ments; the measurement method; and, finally, the adversarial
partments, but transfers within non-critical areas are not model under consideration. The coming sections describe
considered. OAT [6] attests partial code regions that are the proposals and applications within each area.
specified (annotated) by programmers. Within the attested
code, conditional direct jump, indirect jump, indirect call,
and return instructions are covered. ACFA [44] monitors all 4. Prover-Verifier Paradigms
control-flow transfers within pre-determined code regions We recognise that the majority of CFA schemes operate
including any transfer from outside to inside the region. under an interactive paradigm, which is initiated and verified
Other approaches monitor all control-flow transfers within by a (remote) verifier using a challenge-response protocol.
areas that process sensitive data, rather than denoted code This follows a conventional model of remote attestation used
regions (see DIAT [45]). Tracking load/store operations on by trusted computing systems, such as the Trusted Platform
critical data in memory has also been used, thus bridging the
4 Terms like ‘program,’ ‘target,’ or ‘application’ are also used in-
areas of control flow and data flow, but this remains a nascent
terchangeably, which may be adequate where  only executes a single
area of research [34, 45].
program, e.g. microcontroller units.
5 IDs are used to overcome issues with Address Space Layout Randomi-
(C.8) Mixed: Different granularity CFI policies are applied sation (ASLR) in which instructions’ memory addresses change with each
depending on code locations or developers’ annota- program execution. Using only instruction addresses, for example, cannot
tion of code to be attested, i.e. different control-flow delineate between different BBLs in this scenario. To solve this challenge,
the 𝑇 is instrumented to insert BBL IDs to mark the beginning of BBLs,
transfers may be monitored accordingly. which do not exist in the original target program.

Control-Flow
Attestation
Prover-Verifier Instrumentation Measurement Adversarial

Paradigm Trust Anchor Method Technique Behaviour
Conventional Collective Software Hardware Binary Hash- Non-control Code Code

Attestation Attestation Rewriting Dynamic based Hardware Data Attacks Injection Reuse
Kernel User TEEs HSM ROM CPU
Continuous Verifiable Space Space Compiler Abstract DOP Static Run-time COP JOP ROP
Reporting Computation Execution Hybrid Path Log
Arm Intel Custom Trace
TrustZone SGX Extensions Modules PMU LLVM GCC
Hybrid
Attestation
Figure 3: Knowledge areas of state-of-the-art control-flow attestation schemes.
Module (TPM). However, other approaches have also been 3 Challenge c

Application Application
developed in recent years. Module A
6 Response r
Module A
Verifier Ver Prover Prv
4.1. Conventional Attestation Generate Control-Flow Execute:
Graph: G=CFG(A(*)) 1 4
Exec(A(input))
Conventional remote attestation is a two-party interac-
tive protocol between  and , which typically involves an Measure CFG Paths:
Measure executed
2 5 CFG Path:
offline and an online phase. The offline phase is also known H(G)
Auth=H(Exec(A(input)))
as the pre-processing [48] or bootstrap phase [41]. Here, Generate Authenticated
 generates the CFG of the target program and identifies Measurement DB Attestation Report:
and stores all legitimate control-flow paths in a database. r=SigK(Auth,c)
Verification of r 7
 may also modify, or instrument, the source code of the
target program on  to enable the measurement procedure
to capture runtime control-flow data. In this model, the Figure 4: The C-FLAT system model: an example of an
proving device belongs to the verifier, who makes these interactive CFA scheme [4].
modifications prior to ’s deployment in the field. On ’s
side, the target program and the measurement and reporting
procedures must be provisioned securely, including any key CFG in 2 for determining whether an authorised path was
distribution (e.g. attestation report signing keys). taken. In this scheme, all control-flow transfer types are mon-
The online phase involves the measuring and reporting itored, i.e. (C.1). Once the device is deployed in the field,
control-flow events. In a typical challenge-response proto- the online phase begins.  sends a challenge comprising
col,  sends an attestation request to , which then uses a program input to  in 3 . 𝑇 makes an execution run
the measurement module to measure control-flow data based based on this input in 4 . A measurement module, protected
on this challenge.  may run the target program that ac- by a trusted execution environment, computes the hash-
cepts the challenge data as its input parameters. When a based representation in 5 before signing and reporting the
specific termination condition is satisfied—for example, the measurement to  in 6 . Lastly,  determines whether an
final CFG node of 𝑇 has been executed, or a predefined authorised CFG path was followed in 7 by comparing it
measurement result length has been reached—then the mea- with the pre-generated measurements from 2 . The bulk of
surement module outputs the result, which is passed to existing CFA schemes follow a similar challenge-response
the reporting module. An attestation report is created that remote attestation model [4, 7, 11, 12, 13, 37, 46, 47].
is usually integrity-protected and encrypted using one of
public-key cryptography, i.e. applying a digital signature 4.2. Continuous Reporting
over the measurement result and metadata, or a symmetric- Rather than reporting measurements in the context of
key method with a shared key between  and .  sends a challenge-response protocol, LiteHAX by Dessouky et
the report to , who decrypts and verifies the report, and al. [34] reports measurements continuously  → . In this
performs the check that ensures that the correct control-flow work, there is an initial offline phase where  generates
path was followed. Finally,  may perform an action based the CFG of 𝑇 . However, during the online phase,  sends
on this check, such as blacklisting or powering down , or attestation reports to  in a one-way, continuous manner.
allowing it to access a particular resource. There is no formal challenge-response protocol at run-time.
C-FLAT by Abera et al. [4] is a canonical example We illustrate this in Figure 5. ACFA [44] similarly reports
of a CFA scheme that follows the conventional attestation measurements  → . The transmission of the attestation
model. The proposal begins with an offline phase in which report is triggered by one of three conditions: (1) the expira-
 generates a CFG of the target program in 1 .  then tion of a timer, which enables  to send reports periodically;
measures the cryptographic hash values of each path in the (2) the memory designated for storing measurement results

Figure 6: An overview of GuaranTEE [10]. In 1 , users interact

with ProvTEE (), which sends control-flow instances to an
analyser in VerifyTEE ( ′ ) in 2 – 3 . This data is used in
attestation reports for remote verifiers,  in 4 – 5 .
may be targeted by control-flow attackers; a signing service

Figure 5: LightHAX: a uni-directional CFA scheme (from [34]). for COVID-19 digital passports is given as a motivating
example.  ′ contains the logic for measuring and analysing
valid control-flow transfers, which are passed through a
becomes full; or (3) the completion of the attested code exe- trampoline implemented in . We illustrate this in Figure 6.
cution. Another difference with ACFA is that, after sending The target program’s instrumentation is performed through
the attestation report,  pauses the target program’s execu- extensions to the LLVM compiler framework, allowing ’s
tion until  returns a response to notify whether execution full CFG to be constructed pre-deployment. GuaranTEE
can be resumed. supports a form of remote and local attestation. At launch-
time, each SGX enclave mutually attests the other on the lo-
4.3. Hybrid Attestation cal machine, while enabling a remote  to retrieve attestation
We define hybrid attestation as a combination of lo- reports from  ′ .
cal monitoring and remote attestation. Geden and Ras-
mussen [47] follows the same offline stage as conventional 4.4. Verifiable Computation
remote attestation where  extracts a CFG, known as The traditional remote attestation paradigm for CFA
a runtime integrity model, before deploying the proving suffers from an inherent problem: it requires that  ex-
device. The model is stored internally in a discrete hardware poses executed paths and other program details to . This
security module (HSM) aboard . The HSM continuously is satisfactory in situations where  can be unreservedly
takes control-flow events as input from the CPU in real-time trusted, but it is not tenable where privacy concerns may
in order to thwart time-of-check-to-time-of-use (TOCTOU) arise. One example is the attestation of everyday devices, e.g.
problem in conventional remote attestation. A remote ver- smartphones, owned and used by the general public. Disclos-
ifier can acquire a report from the HSM, showing whether ing precise program details could expose privacy-sensitive
any security policy violations were detected over the course information about the user’s device. To address this problem,
of the target program’s execution. Debes et al. [36] proposed ZEKRA, which developed a new
CHASE by Dessouky et al. [35] proposes a set of hard- CFA paradigm based on verifiable computation. Here, a
ware extensions for implementing various run-time security third party—an attestation proxy—is introduced in order to
requirements for CFA. Different security modes are sup- perform the attestation verification between  and , which
ported, where either authorised control flows can be en- are considered mutually untrusted. ZEKRA converts the task
forced at run-time, or collected for later use in an attestation into an outsourceable arithmetic circuit through an applica-
response. In both cases, it is assumed that valid control flow tion of zero-knowledge Succinct Non-interactive Arguments
policies are provisioned on  by  prior to its deployment. In of Knowledge (zk-SNARK). Using this, the proposal enables
remote verification mode,  requests attestation of specific the proxy to convey only the executed path’s correctness to
ranges of memory locations at runtime. When local verifi-  without exposing privacy-sensitive program details.
cation is deployed, a measurement is triggered when a local
check detects a target attack. When detected, the violating 4.5. Collective Attestation
control-flow path is reported to . Conventional CFA assumes a single proving device and
GuaranTEE by Morbitzer et al. [10] investigates control- verifying entity. However, generalising control-flow attesta-
flow attestation within untrusted cloud environments. The tion to a system or network of devices topology can also be
work differs in that  and a local verifier,  ′ , run on the same useful. In other words,  is not necessarily a single device,
cloud-based virtual machine (VM) in Intel SGX enclaves. but rather a composition of individually attested devices or
The  is assumed to host a security-sensitive application that services whose trust statuses are assessed as a whole. This

Figure 8: System overview of DIAT (from [45]). Unlike

conventional schemes, measurements from each sub-system’s
CFGs are aggregated within attestation reports.
act as  and  in a given session. The authors address the

problem of adversarial verifiers who submit malicious attes-
tation challenges that purposely induce a particular control-
flow path resulting in unintended behaviour. To address this,
Figure 7: The ARCADIS system model (from [41]).
the authors combine secret sharing and mutual attestation in
order to create an agreed attestation measurement between
multiple devices.
is known as collective attestation [21]. RADIS [8] inves- DIAT [45] tackles the attestation of autonomous un-
tigates this problem in distributed IoT device networks. In manned aerial vehicles (UAVs) in which several critical
such environments, a control-flow attack on one device may components are connected for flight planning, navigation,
adversely affect the services performed by another device. sensor data acquisition, and actuator control. DIAT provides
For example, one device may produce data, e.g. sensor assurances about the trustworthiness of data flows between
measurements, that influences the actions of a consuming such components, which is given in Figure 8, as well as with
device. To address this, RADIS uses a service-level flow other UAVs. Let us assume two UAVs, 𝐷1 and 𝐷2 . At a high
graph (SFG) composed of individual CFGs corresponding to level, this is achieved by using the data produced by 𝐷1 as an
each proving device within a given IoT service. On request, input challenge for 𝐷2 . Each device monitors and measures
each prover collects measurements of the various control- its own control-flow events using an aggregated hash value,
flow transfers resulting from a challenge given by . The which can be reported to .
final device in the SFG returns an aggregated response to .
Similarly, ARCADIS by Halldórsson et al. [41] ad-
dresses the attestation of asynchronous distributed IoT ser- 5. Trust Anchors and Assumptions for
vices, where multiple devices and services are engaged in Control-Flow Attestation
publisher-subscriber relationships. In this work, a single 
A trust anchor is an authoritative sub-system from which
verifies the trustworthiness of multiple IoT devices using
a platform derives its trust; if the anchor is compromised,
hash-based measurements of each node in the devices’
then so are any dependent components that rely on its
CFGs. The system model is given in Figure 7. In 1 , 
functionalities. In theory, trust can be placed in any layer of
submits a challenge input to an initial ARCADIS-enabled
the platform architecture, from hardened user-mode applica-
device, which computes a measurement (𝐺𝐴𝐸1 ) in 2 , and
tions to kernel-mode or hardware-based systems. Nowadays,
sends it to an associated subscriber device, 𝑆 in 3 . 𝑆
isolated hardware-based mechanisms are commonly used
computes its own measurement, 𝐺𝐴𝐸2 , from its CFG in
trust anchors due to their high attack complexity and im-
4 . Notably, 𝐺𝐴𝐸2 contains 𝐺𝐴𝐸1 in its output.  makes
munity to powerful (kernel-mode) software adversaries [3,
a separate attestation to 𝑆 at a future point in time in 5
50, 51, 52]. Traditional trust anchors of this type include the
in which 𝐺𝐴𝐸2 is returned to  in 6 who checks whether
Trusted Platform Module (TPM) [53], embedded Secure El-
it corresponds to a known ‘safe’ measurement. The scheme
ements (SEs) [54], hardware security modules (HSMs) [55],
can be generalised to multiple target devices; the authors
and physically unclonable functions (PUFs) [56]. Modern
evaluate ARCADIS using a network of up to 40 IoT devices.
trusted execution environments (TEEs) [57] use system-
Li et al. [49] proposed CFRV that tackles attestation in
on-chip extensions to mitigate the costs of incorporating
networks of peer-to-peer IoT devices, where devices may

discrete hardware modules. A number of academic sys- deployment. (A notable exception is the proposal by Li et
tems have been proposed with similar design goals (e.g. al. [49], discussed previously in §4.5, which investigates
TyTAN [52] and TrustLite [51]). collective CFA for peer-to-peer devices).
The trust anchor is commonly used to protect ’s mea-
surement procedure and any key material used in generating 5.1. Trusted Execution Environments
attestation reports. For some proposals, this requires that the A trusted execution environment (TEE) [57] serves as a
trust anchor passes traditional static attestation and that it has common trust anchor in existing CFA proposals. A TEE is a
dedicated memory to store material that can only the anchor hardened environment in which code and data can be hosted
itself can access [13, 34, 37, 41]. For proposals that rely and executed with hardware-enforced isolation. It aims to
on TEEs, it is assumed that potentially applicable high-cost protect the integrity and confidentiality of code and data
attacks cannot be performed by an adversary, such as hard- at run-time and at rest from kernel-level adversaries in the
ware fault injections and side-channel attacks [50]. TEE- normal, rich execution environment (REE), such as Android
based proposals sometimes place trust in certain operating and Linux. Communication between the REE and TEE is
system components, such as kernel modules that initiate the achieved through an API that performs the switches between
communication with the TEE [6, 38]. In proposals where the the REE and TEE worlds, and authenticates and authorises
kernel serves as ’s trust anchor, it is somtimes assumed that the REE application that invokes functions within the TEE.
a method for protecting cryptography keys is available, such Different TEE implementations have been used, but we
as a TPM or a proprietary facility (see Intel MPK in [58]). observe that Intel SGX [9, 10, 40] and ARM TrustZone [7,
Very few CFA proposals are purely based in software, 14, 45, 46, 49] are widely used choices. Intel SGX follows
and most systems have some degree of hardware depen- the enclave model of trusted execution, where applications
dency. We observe that CFA schemes can be split into three are partitioned into sensitive and non-sensitive regions. Sen-
categories based principally on where security-critical CFA sitive portions are initially loaded by the (untrusted) operat-
components are implemented on : ing system into an enclave, where dedicated CPU extensions
provide hardware-enforced access control to enclave-hosted
• Software-based systems implement all process com- regions when the enclave is executing. The reader is referred
ponents at the software level, typically as libraries in to work by Costan & Devadas [59] for a comprehensive
user space and modules in kernel space. introduction to Intel SGX.
• Hardware-based proposals rely on a dedicated hard- Intel SGX differs to the trusted world model used by
ware for performing the measurement and reproting ARM TrustZone, which relies on dedicated operating sys-
operations. This may be a discrete on-chip security tems for handling sensitive and non-sensitive applications.
module, an off-chip micro-controller, or a set of be- We note that TrustZone-A [7, 14, 46, 49] and TrustZone-
spoke CPU extensions. M [45] have been used, which are compatible with the
ARM Cortex-A and -M CPU series respectively. In general,
• Hardware-assisted systems use software whose secu- hosting the measurement and reporting procedures in a user-
rity is underpinned by a hardware root of trust. TEE- mode TEE application is a common approach; that is, the
based proposals are characterised as such, as well measurement and reporting procedures execute at S-EL0 in
as proposals that rely on read-only memory (ROM), the ARM exception model. Additional extensions to the TEE
secure boot [45], and a TPM [13] in tandem with a are also required in a minority of proposals. Notably, Liu et
normal operating system. We also categorise proposal. [7] use an SRAM-based physically unclonable function
als that rely on DEP and W⊕X that make data portions (PUF) for deriving device-unique keys used in generating
of the target program non-executable [11, 40]. attestation reports. Irrespective of whether Intel SGX or
ARM TrustZone is used, the same underlying hardware is
The following assumptions are also commonly made. used to execute normal and secure world applications.
Attacks against  are out of scope and it possesses Figure 9 shows the general architecture of TEE-based
unbounded resources. State-of-the-art CFA schemes do not CFA schemes using C-FLAT [4] as an example. The target
consider attacks against . For example, from malicious program is executed in REE, while the measurement and
insiders, due to supply chain attacks, or any other vector reporting procedures run within the TEE. In this model,
with the intention of undermining the verification (𝑉 ) and a kernel-based trampoline implements the functionality to
measurement procedures (). Moreover, it is assumed that jump between the normal and TEE worlds. When an instru-
 has sufficient computational and storage resources to mented target control-flow transfer is executed, several steps
execute 𝑉 and, if applicable,  when required without are followed:
hindrance.
 acts honestly. It is similarly widespread that  makes 1. The control-flow event is passed to the trampoline,
no malicious modifications to 𝑇 .  deploys the intended which gains control of the execution.
program on  along with any instrumentation (if applicable)
in an honest fashion. It is not considered in the interest of 2. The trampoline forwards the control-flow event to the
 to instrument code that triggers malicious procedures, TEE over a secure monitor that validates the data and
issue malicious challenges, or otherwise disrupt  after its performs the world switch to the TEE.

REE TEE
Reporting 5 Measurement
Target Program Module Module
1 9 6 4
Trampoline TEE Run-time
2 8 7 3
Secure Monitor
TEE-enabled Hardware
Figure 10: SCaRR’s user- and kernel-space components [13].

Figure 9: A simplified TEE-based CFA architecture, showing
trusted (green) and untrusted (red) components.
5.2. Normal World Schemes

3–4. Execution is transferred to the TEE run-time, which A small number of proposals deploy the process com-
forwards the control-flow event to the TEE application ponents,  and , in the same execution environment as
(TA) used to host the measurement module. the target program, whether in kernel- or user-space. This
may be considered the ‘normal’ or ‘non-secure’ world, such
5. The reporting module is invoked immediately after as Android, Linux or a real-time operating system (RTOS).
the previous step or after collecting several measure- These schemes do not require a trampoline component to
ments. The module produces a cryptographic attesta- forward control-flow instances to the measurement mod-
tion report to be returned to , typically signed under ule at runtime. ScaRR [13] relies on kernel-space mod-
a hardware- or TEE-bound attestation signing key. ules for measuring relevant control-flow events and creat-
ing attestation reports. User-space programs hook relevant
6–8. The reporting module returns the signed attestation re- control-flow transfers, which are passed to the kernel mod-
port to the TEE run-time environment, which forwards ules through a user-space library (Figure 10). The design
it to the trampoline over the secure monitor. decision was motivated by performance. It is stated that us-
9. Finally, the report is returned to the target program, ing a TEE (Intel SGX) imposed considerable overhead “due
who then forwards it  over, e.g., a network con- to SGX clearing the Translation-Lookaside Buffer (TLB)...at
nection. (The reporting module may directly send the each enclave exit. This caused frequent page walks after
report to  after step 5, depending on whether the TEE each enclave call.” (p.8, [13]). Tiny-CFA [62], a hardware-
can establish network connections itself). based CFA scheme designed for low-end microcontroller
units (MCUs), makes a similar argument.
In other work, BLAST [14] partially performs measure- Normal world schemes tend to rely on other security
ment operations in the REE. The proposal uses a register mechanisms to safeguard data against user-space adver-
to mark the executed control-flow path in each function, saries. ReCFA [58] relies on Intel MPK [63], a proprietary
updating the register when target control-flow transfers are hardware-backed security mechanism for controlling page
executed. The contents of the register are transferred to table permissions from userspace, to protect the measure-
memory shared between the REE and TEE when the func- ment module. DIAT [45] assumes that the prover has ac-
tion returns, and then sent to the measurement module in cess to means of secure storage, secure boot, isolated ex-
the TEE when the target program finishes execution or the ecution, and inter-process communication. ARCADIS [41]
register content reaches a pre-determined length. bases its collective CFA scheme on the use of read-only
We also draw attention to the control-flow property- memory (ROM) as a trust anchor for write-protected key
based attestation (CFPA) scheme sketched by Koutroumpou- storage, encryption and measurement operations. Likewise,
chos et al. [60]. The proposal seeks to measure higher level Tiny-CFA [62] assumes that attackers are unable to mod-
behavioural and execution properties of proving programs, ify any writable memory or access any memory protected
i.e. as a sequence of abstract states, rather than individual by hardware-enforced access control. LAPE [48] relies on
control-flow events. This broadly reflects earlier efforts on standard memory protection unit (MPU) features to protect
property-based attestation (PBA) [61]. A system is described the measuring and reporting procedures from unprivileged
in which abstract control-flow events that satisfy particular adversaries.
properties can be used for PBA. The precise control-flow
transfers are not specifically defined. A TEE is used as a 5.3. Central Processing Unit Features
tamper-resistant trust anchor; however, the described system Another common trust anchor is the use of custom or
is not implemented concretely. proprietary or CPU features. These are predominately used
to realise a measurement module that gathers control-flow

Code Legend:
addi sp,sp,-16
pipelined processor
sw ra,12(sp)
jalr zero,ra,0 Pre-existing
lw ra,12(sp)
addi sp,sp,16
components
1 LO-FAT
executed instructions components
4 loops_status & branch_status ctrl

3 non_loops ctrl On-chip memory
Branch Filter 3
controller
branch type, (Src, Dest)
engine
Hash 11
Hash
Branches memory
engine Hash A
5
Indirect calls: (Src, Dest)
7 new_path ctrl
Loop Monitor
8 loop_end ctrl
6
Loop P_IDs 9 Loop P_IDs & counters
generator
Metadata
Metadata 10
Loop counter memory Metadata
storage
L
Figure 11: An overview of Atrium’s system architecture [37].
information while the target program is being executed, i.e.

Figure 12: System architecture of LO-FAT [12].
at a machine code level. Such CFA schemes can be divided
into two sub-categories. The first comprises schemes that
employ custom extensions to CPU designs, e.g. open-source
soft-core CPUs, to capture relevant control-flow events. The and loop and function IDs—corresponding to nodes of a
second contains proposals that rely on proprietary features of CFG—into a sequence of cryptographic hashes produced in
existing CPUs, such as tracing modules that track the history real-time during the program’s execution. These hashes are
of instructions executed by the processor. continuously stored in memory and used in the attestation
report returned to . It is noted that Atrium has reduced on-
5.3.1. Custom Extensions chip memory requirements while also addressing TOCTOU
Dedicated hardware circuits have been used that collect attacks when compared with LO-FAT.
control-flow events directly from processor pipelines and LiteHAX [34] is more complicated in nature, hook-
memory controllers. Naturally, this imposes significant in- ing three parts of the CPU’s pipeline: the decode, exe-
vasive modifications to the target platform, but it enables cute, and load/store phases (Figure 13). The proposal mon-
the highest degree of fidelity by monitoring instructions at itors all control-flow instructions and memory addresses of
the closest possible level. A common technique involves load/store instructions in order to address control- and data-
reading data from specific points of the processor pipeline, flow attacks respectively. A similar hash-based measure-
e.g. instruction fetch, decode and execute stages. Such pro- ment approach is used as Atrium [37] and LO-FAT [12].
posals are realised as extensions of open-source softcore However, LiteHAX the hash engine takes encoded control-
CPU designs on FPGA implementations, rather than using flow instructions and load/store instructions, their memory
proprietary CPUs (e.g. Intel or AMD). addresses, and the current program counter value when
In this area, LO-FAT [12] hooks the CPU’s instruction calculating the hash values for the attestation report.
pipeline in order to measure control-flow events. As shown CHASE [35] provides a configurable hardware design
in Figure 12, a branch filter and loop monitor is used to capable of detecting different adversaries. A selection of up
provide inputs to a hash engine and a metadata generator. to 10 sub-modules can be used to detect various control- and
The hash engine outputs a cumulative hash of the path that data-flow attacks, such as DOP and DDM attacks. To achieve
was traversed for a given input. The metadata generator this, the modules hook into the fetch and decode phases of
outputs data about any loops that were taken, including the the processor pipeline, which outputs features to a hashing
loop identifiers, the number of iterations, and the targets of module that continuously generates hash measurements for
indirect branches that were used. attestation reports. Depending on the configuration, both
Atrium [37] (Figure 11) uses hardware extensions to local and remote attestation can be provided. Addressing
capture instructions and memory addresses at the execution the strongest adversarial models, e.g. DOP attacks, requires
stage of the CPU’s pipeline. The extensions capture the the use of all 10 sub-modules, whereas the simplest threats
control-flow changes taken by the target program on  requires the use of only four sub-modules.
while executing a challenge from . An instruction filter is
used to consider only, and all, branch and jump instructions 5.3.2. Trace Modules
in addition to the current program counter values, and a In recent years, CPU manufacturers have deployed ca-
separate loop encoder is used to track the execution of loops. pabilities that actively record control-flow information of
A hashing engine is used to convert the executed instruction programs under execution. This is known as program tracing

(PMU) as a trusted measurement component. A PMU is a

hardware component found on most contemporary CPUs
that monitors various hardware events. Such units have been
used widely for optimising software performance, identi-
fying bottlenecks, and understanding the interaction with
hardware. PMUs can count various types of events, such as
the number of instructions executed, cache hits and misses,
branch predictions etc., and have been used for numerous
security applications [70, 71, 72, 73].
LightFAt relies on a CPU’s PMU on  to monitor the
number of instructions per cycles and L1 cache accesses
used during the execution of the target program for a given
challenge from . The number of events is sent to  who
then uses a machine learning model to classify the program
execution as being malicious or legitimate. The model is
Figure 13: System architecture of LiteHAX [34]. assumed to be trained on the target program pre-deployment
with known, labelled malicious/legitimate traces. Results of
95% accuracy and 0.9757 F1-score are presented using a
whereby the CPU outputs encoded control-flow information AMD Ryzen 7 2700X 64-bit processor.
into readable memory. Authorised applications can read this
data, also known as a trace, to learn the control-flow path 5.4. Discrete Hardware Modules
followed by a given program. The trace feature is supported The previous section described several proposals that di-
by many contemporary CPU processors; for example, Intel rectly utilise CPU features or hook into the CPU’s instruction
CPUs support a tracing module from their 5th generation pipeline using custom hardware extensions. In contrast, sev-
models, called Intel Processor Trace (PT) [64], which is eral proposals have employed dedicated hardware security
designed for debugging pruposes. ARM CoreSight [65] is a modules that are separated from the platform’s processor,
comprehensive suite of debug and trace components that are but are still part of the system-on-chip (SoC). These modules
embedded in ARM-based processors, providing developers are dedicated to implementing the measurement () and
with method to optimise and debug their applications on reporting () procedures in CFA schemes.
ARM architectures. The RISC-V specifications also describe Geden & Rasmussen [47] proposed an on-SoC hardware
a trace module; however, its availability varies according security module (HSM) that collects control-flow informa-
to vendor in the spirit of RISC-V’s modular instruction set tion from the system bus (Figure 14). The HSM continuously
architecture [66, 67]. takes control-flow events as input from the CPU, includ-
Among the proposals we identified, two proposals dis- ing the requested instruction address, opcode, and operand
cuss the application of trace modules for control-flow attes- values over the system-on-chip’s control line and address
tation [36, 68]. Papamartzivanos et al. [68] describes a two- and data buses. The collected events are compared with
tier tracing technique combining a kernel-mode extended security policies defined in the HSM’s runtime integrity
Berkeley Packet Filter (eBPF) [69] and Intel PT. By default, model for detecting code injection and re-use attacks. The
eBPF monitors both user space (e.g. target program’s con- use of continuous run-time data addresses TOCTOU at-
figuration and commands executed by the target program) tacks: a challenge-response protocol that measures events
and kernel space (e.g. kernel shared libraries and system at only fixed points in time does not detect attackers that
calls). The data captured by eBPF on  is sent to the  for act transiently between those points. The proposal allows
verification. If any violations of specified requirements are  to acquire a report from the HSM showing whether any
detected, Intel PT is used to collect additional control-flow security policy violations were detected; it also supports
information from the target program. This additional layer of local verification whereby the module outputs a binary result
data collection is used to provide assurances about the nature to indicate if a target control-flow hijacking attacks are
of the detected violation. detected. In scenarios where attacks are detected, the module
ZEKRA [36] implicitly relies on a trusted trace module outputs a binary result and provides auxiliary information,
with a certified asymmetric key pair in order to provide such as the last executed instruction.
path authenticity. The proposal does not specify an im- ACFA [44] proposes a discrete hardware monitor that
plementation per se, but specifies that the module must detects and saves all control-flow transfers during the execu-
chronologically and faithfully provide a trace of the executed tion of a target program. A log of these control-flow transfer
path when executing a program region to be attested. records, referred to as 𝐿𝑜𝑔 , is written to a dedicated region
of read-only memory of a micro-controller unit in a sequen-
5.3.3. Performance Monitoring Units tial manner. The read-only nature prevents a compromised
In 2024, Gonzalez-Gomez et al. [5] proposed Light- program from overwriting the event sequence. The module
FAt, which relies on a CPU’s performance monitoring unit also triggers an interrupt for when the reporting procedure

Figure 15: An overview of the LLVM compiler framework [77].
6.1. Compiler-assisted Instrumentation

Compiler-assisted instrumentation assumes access to the
Figure 14: Block diagram of the HSM used by Geden and
Rasmussen (from [47]). program source code, allowing additional code-level se-
mantics to be leveraged during the instrumentation process
and enabling precise control-flow tracking and optimisation.
Existing proposals tend to rely on the LLVM framework [75]
must begin. This launches a trusted measurement routine
which enables, in theory, the integration of CFA into var-
that computes a MAC over the target program’s binary and
ious input languages and target platform architectures (Fig-
𝐿𝑜𝑔 , and sends the result to  for verification.
ure 15). In this vein, the ScaRR system proposed by Toffalini
Tiny-CFA [62] uses a minimalist approach to control-
et al. [13] instruments target programs using a bespoke
flow attestation, focussing on reducing the trusted comput-
compiler built using the LLVM and CRAB frameworks [76].
ing base and the number of invasive modifications needed to
The compiler is used to create a ‘Measurements Generator’
realise a trust anchor. The work employs a simple external
for performing several operations. This includes identifying
hardware module that monitors run-time control-flow states
all valid measurements of the program during the offline
in order to produce a proof-of-execution (PoX). Tiny-CFA
phase, given as a key-value pairing in Eq. 1:
proposes an approach that combines automated code instru-
mentation with APEX [74], which uses a bespoke hardware
(𝑐𝑝𝐴 , 𝑐𝑝𝐵 , 𝐻(𝐿𝑜𝐴)) ⇒ [(𝐵𝐵𝐿𝑠1 , 𝐵𝐵𝐿𝑑1 ),
module to provide a PoX from a micro-controller unit core.
(𝐵𝐵𝐿𝑠2 , 𝐵𝐵𝐿𝑑2 ), … (𝐵𝐵𝐿𝑠𝑛 , 𝐵𝐵𝐿𝑑𝑛 )] (1)
6. Instrumentation Methods Where 𝑐𝑝𝐴 and 𝑐𝑝𝐵 are checkpoint identifiers representing
The collection of control-flow data can be achieved an arbitrary sequence of BBLs. 𝐻(𝐿𝑜𝐴) is the hashed mea-
through the process of instrumentation, which involves mod- surement value of a list of actions (LoA), which is the list of
ifying the target program to add instructions that capture, CFG edges for traversing 𝑐𝑝𝐴 → 𝑐𝑝𝐵 ; and (𝐵𝐵𝐿𝑠𝑖 , 𝐵𝐵𝐿𝑑𝑖 )
and measure, control-flow events of interest. Dispatch in- is the source and destination BBL at index 𝑖. The compiler
structions are used near target control-flow transfers or at is also used for detecting and instrument control-flow in-
the entry of BBLs to this end. When a target control-flow stances, which are passed to three kernel-space modules re-
transfer is executed at run-time, the dispatch instructions sponsible for generating measurements. To support this, the
call pass the transfer(s) to the measurement module for it to Measurement Generator analyses the LLVM intermediate
be measured. Execution is resumed after the measurement representation (IR) of the target program’s processed source
process has completed. code. The CRAB framework is used to generate the CFG
Instrumentation has been achieved in three ways: 1 at itself, which is used to resolve indirect forward jumps. We
the compiler level [6, 10, 11, 13, 14, 43, 48, 49], 2 by note that mapping LLVM to raw assembly BBLs involves the
rewriting compiled binaries [4, 7, 38, 39, 41, 45, 46, 58, 62], use of dummy code, which is later removed using a custom
or 3 using dynamic instrumentation [8, 9, 40, 42]. Auto- binary rewriting tool. The authors add approximately 3.5K
mated methods are involved in all cases. In theory, manual lines of code (LOC) to CRAB and LLVM 5.0.
instrumentation is a fourth possibility—that is, identifying GuaranTEE [10] also uses the LLVM compiler frame-
and labelling control-flow transfers by hand—but this is work (see §4.3). The authors perform the instrumentation in
infeasible for non-trivial programs. We recognise that not two LLVM phases: during IR optimisation and the backend
all CFA proposals require a dedicated instrumentation step. stages. In the IR pass, calls are added to the trampoline
This applies where hardware extensions are used to detect, at the start and end of identified BBLs, i.e. at the start
capture and measure control-flow events within the CPU’s and end of BBLs and direct function calls. The backend
instruction pipeline (e.g. Atrium [37] and LO-FAT [12]). In pass implements trampoline calls before and after indirect
the coming sections, we describe methods for instrumenting function calls, indirect jumps, and before return instructions.
target programs used by CFA schemes. Notably, the authors released their LLVM extensions as
open-source software.

BLAST by Yadav & Ganapathy [14] is an efficient CFA code. Intel’s MPK system is used to protect the integrity
scheme that relies on a combination of techniques for min- of instrumented data structures—the loop stack and path
imising TEE world switches and the Ball-Larus algorithm stack—used by control-flow events. The authors compare
for optimal instrumentation placement in target program this to SCaRR [13] where control-flow edges are measured
CFGs [78]. The authors instrument BLAST as a compiler in kernel space, which has a “potential enormous context
pass within the LLVM framework in a way that commits switching cost for the control-flow events on an order of
CFG path information to a log file on . A TEE is used to magnitude in gigabytes” (p. 6, [58]). The authors combine a
sign a hash representation of the log file, which is returned kernel mode-based functions to preserve code integrity and
to  on request. MPK-protect data structures in order to uphold the integrity
LAPE [48] uses the LLVM-compatible ACES [79] com- of the measurement procedure.
piler to create and instrument ‘compartments’ on ARMv7 DIAT [45], which attests software modules on drone
devices. Programs execute within components where indi- platforms, realises the instrumentation by making custom
rect calls and function entry and exit points are recorded and extensions to the PX4 open-source flight controller software.
measured using a hash-based approach. We note that, despite Firstly, each software module is assigned a unique identifier
LLVM’s flexibility, there are some downsides. LLVM is typ- for identifying the various flight controller sub-components
ically not used unchanged: proposals tend to require exten- at run-time. The authors rely on the insertion of dispatch in-
sive modifications or extensions of the magnitude of 1,000s structions at relevant control-flow events. These instructions
LOC [10, 13, 14]. In practice, this may pose compatibility redirect execution to a monitor that measures the ID of the
issues when adapting the schemes to existing toolchains and software module in question and the source and destination
development environments. addresses of the control-flow event. The method by which
In other work, Hu et al. [11] use a combination of the dispatch instructions are inserted is not clear; however,
compiler-assisted instrumentation and binary rewriting— it is stated that the “modifications are applied to the code in
discussed in §6.2—to hook control-flow instances. The assembly form” (p. 9, [45]).
GCC compiler with the -finstrument-functions flag is used Liu et al. [7] instrument the target program on  at a
to instrument function entry and exit points. Afterwards, binary level before it is deployed. A custom binary analysis
branches within functions are hooked using binary rewriting tool is developed that targets indirect jumps and computes
using the Capstone disassembly framework [80]. and stores all legal targets in a database held by . The
work instruments the following instructions pertaining to
6.2. Binary Analysis and Rewriting control-flow events (ARM assembly): bx lr, pop pc rx,
Binary rewriting involves making direct modifications to blx rx, bl rx and bx rx. The instrumentation is used to
the compiled target program, where control-flow instances jump to a trampoline module, discussed in §5.1, which sends
are represented and changed in the form of machine code. control-flow data to a measurement module implemented
This approach can be applied to existing programs, making within ARM TrustZone, which includes the values of return
it suitable for incorporating CFA into software where the addresses and function pointers to be reported to .
original source code is not accessible. The approach has
particular applications to retrospectively protecting legacy 6.3. Dynamic Instrumentation
and proprietary software. Dynamic instrumentation refers to the method of insert-
C-FLAT [4] developed a custom binary rewriting ap- ing monitoring and verifying code into a program while it
proach for ARM binaries. The authors identify the locations is running. This compares to instrumenting target programs
of control-flow instructions, such as indirect branches, which using static analysis and manipulating the executable before
are overwritten with dispatch instructions. The dispatch execution (e.g. using binary rewriting). Dynamic methods
instructions are used to trigger an assembly routine, which rely on the insertion of probes or tracking mechanisms into a
serves as a trampoline for transitioning into ARM TrustZone running program. These probes can monitor the control flow
(see §5.1). The Capstone disassembly engine [80] is used of the application in real-time, identifying any deviations
to identify control-flow transfers in program binaries to be from expected paths.
rewritten with dispatch instructions. Common dynamic instrumentation tools used more gen-
Recording every function call can impose significant erally in the area of control-flow integrity use Intel Pin [82],
performance overhead (see p. 3, [58]). To address this, DynamoRIO [83], and LLVM-based methods [84]. In the
ReCFA [58] derives a CFG from the target program us- area of control-flow attestation specifically, GACFA [9] re-
ing TypeArmor for performing call-site filtering, whereby lies on Intel Pin-3.15 to instrument the target program during
CFG nodes are skipped where none of its predecessors has runtime. Here, control flow events, which are collected using
more than one successor. ReCFA uses Dyninst [81] for the Intel Pin, are sent to the scheme’s measurement module
static binary instrumentation of user-space programs on . running in an Intel SGX enclave. The measurements are cal-
Dyninst provides a set of libraries and utilities designed culated using a hash-based approach; the final measurement
for the static (and dynamic) inspection and manipulation is signed under a secret key within the enclave and provided
of executables. Dyninst enables users to insert, modify, or within an attestation report. A similar approach is used in
remove code in a program’s CFG without access to its source the BDFCFA [40] proposal, which uses Intel Pin for binary

instrumentation, and presents an approach with bidirectional learn all of the legitimate control-flow paths within an offline
attestation for blockchain applications. phase. This may be stored in a database in the form of <key,
RADIS [8] uses the Python trace module to dynami- value> pairs. (Using hash values to aggregate and represent
cally instrument target functions at the interpreter level. A the nodes traversed by  is a common approach [4, 8, 13, 37,
bespoke implementation of the module in a TEE is recom- 39, 41, 45, 46, 48, 49]). In the online phase,  issues an at-
mended to protect the measurement procedure from kernel- testation challenge, and  responds with a measurement that
mode adversaries; however, the proposal was neither imple-  matches against the records in its database. This method
mented nor evaluated. suffers from the path explosion problem, where the number
of control-flow paths grows dramatically with the number
7. Measuring and Monitoring Control Flow of branches in the target program. The storage requirements
placed on  can be enormous. It is also possible that ’s
The measurement process is one of the key facets of CFG may contain non-deterministic behaviours that are not
a CFA scheme. It is at the core of  demonstrating to  straightforward to calculate a priori as a legitimate path,
that an authorised path/walk was followed through the target such as branches that depend on input/output (I/O) data.
program’s CFG. For a given CFA scheme, the measurement In comparison, monitoring and measuring events at a
method typically remains constant, regardless of the control- control-flow transfer level can mitigate the challenges above.
flow paths or the target program in question. However, these Rather than tracking all potential control-flow paths, only
methods tend to vary significant between CFA schemes, legitimate control-flow transfers are stored. For example, us-
which we elaborate upon in this section. ing a whitelist or otherwise flagging any anomalous transfers
The measurement process measures the whole or part(s) that are encountered. On the down side, this method can
of the target program’s CFG: impose significant run-time overhead on  if many control-
• Whole program measurement: The whole control- flow transfers are monitored and measured during execution.
flow path used by the target is measured, comprising An interesting observation can thus be made: the choice
the nodes traversed by  using a challenge supplied of measurement approach reflects a time-space complexity
by . The task of  is to determine whether the mea- trade-off between the storage requirements of  and the run-
surement returned by  corresponds to a known, ‘safe’ time overhead on .
value reflecting the execution of the target program
7.1. Hash-based Measurements
from start to finish.
A naïve method is to instrument the target program on
• Partial measurement: Particular aspects of the control-  in order to capture every control-flow transfer. When 
flow path are measured, such as loops, certain branch- traverses the CFG of a target program,  stores a list of these
ing instructions, functions etc. The overall measure- transfers and sends it to  as part of an attestation response.
ment may comprise several such measurements as a However, such an approach can lead to prohibitively large
proxy that the target program had executed correctly attestation reports that may be unsuitable for constrained
and without the presence of an adversary. Given a devices. Many schemes, therefore, make use of hash-based
measurement result from , then  checks whether measurements to represent control-flow paths in a space-
these (partial) program measurements conform to efficient manner.
known valid results.
7.1.1. Hash Computation
A CFA scheme may measure the whole program and Let us consider the above example once more. One
partial elements, or multiple aspects of partial elements, solution to reduce the memory requirements on  is to
simultaneously. BLAST [14] serves as a good example, make a single hash calculation over the collected control-
which uses optimal instrumentation of loops and functions flow transfers and return this (hashed) result to  after the
in order to achieve whole program control-flow attestation CFG’s terminating node had been reached. This is method
efficiently. is, again, not widely due to the need to store every control-
We can also consider measuring techniques as acting flow transfer before the hash function has been applied.
at different levels of abstraction. Path-based techniques To address this problem, hash-based CFA proposals have
measure an entire or partial control-flow path within the opted for a cumulative approach to hash computation. The
target program’s CFG, i.e. path-level granularity. In con- measurement module performs a hash computation at every
trast, control-flow transfer-based methods monitor individ- control-flow transfer using data from the previous transfer.
ual low-level transitions at each branch, function call, or an- This can be described by the recurrence relation in Eq. 2:
other relevant control-flow event. There is little information {
stored explicitly about the path. ℎ(𝑑, 𝐶𝑖 ) 𝑖=0
𝐻𝑖 = (2)
At first glance, it may seem that path-based measure- ℎ(𝐻𝑖−1 , 𝐶𝑖 ) 𝑖 > 1
ments are superior because they consider the entire path
explicitly. However, there can be a significant measurement Where 𝑖 denotes the node number, 𝐻𝑖 refers to the hash
range of potentially legitimate paths for non-trivial pro- value generated at node 𝑖, and ℎ(⋅) is a suitable hash function.
grams. Recall that, prior to ’s deployment,  usually must 𝐶𝑖 is the control-flow event at 𝑖, which may be represented by

a (src, dst) pair [12], an (entry, exit) pair [13], or a BBL ID as new elements, i.e. control-flow transfers, are added. In-
[4]. 𝑑 represents the default value used when the first control- cremental MSH schemes are used to efficiently update new
flow event when 𝑖 = 0, e.g. 0 in C-FLAT [4] or ℎ(0) in control-flow transfers, avoiding the storage or recalculation
GACFA [9]. The main advantage of cumulative hash-based of the entire set upon adding a new element [87]. Compared
approach is that it does not require  to store all control- to conventional cryptographic hash functions, MSH func-
flow transfers. Once a round of calculation is completed, tions are space-efficient for CFA applications, reducing the
the corresponding control-flow transfers can be discarded. In number of possible hash values to be stored in a database
Figure 16, we present a canonical example of a cumulative belonging to  or .
hash-based approach used by C-FLAT [4], demonstrating The space-efficient property of MSH functions can also
the hash values at different nodes of a target program’s CFG. pose some downsides. Namely, they do not consider the
order of control-flow transfers in the set. It is possible that
multiple legitimate control-flow paths have the same hash
value, thus  loses contextual information control-flow path.
Even if a hash value in the measurement result matches one
in the database,  can determine only the number, not the
order, of executed control-flow transfers. This could be fatal
if an adversary finds a sequence of malicious control-flow
transfers that produces the same MSH value as the legitimate
sequence. We pose this issue as a research challenge.
7.1.2. Discussion
The main advantage of hash-based measurement is that
it can generate short, constant-length measurement results,
irrespective of the target program’s size or the number of
Figure 16: An example of cumulative hash calculation approach control-flow events. The length of the measurement result
from C-FLAT [4]
is a major factor to influence the attestation report size, and
thus the space and network complexity when the report is
Common hash functions used in existing CFA proposals computed on  and sent to .
can be categorised as standard cryptographic hash functions, However, hash-based measurements present some major
and multi-set hash functions. disadvantages. The first is the aforementioned path explo-
Standard cryptographic hash functions: BLAKE2 [85] sion problem: if a target program contains several loops
is a common choice for CFA schemes targeted at embedded with non-trivial terminating conditions, then it is possible
systems with limited computational resources [6, 13, 35, 43]. that relatively short programs can impose significant storage
BLAKE2 is known to be significantly outperform (∼50%) requirements on . Furthermore, if an attack does take
competing functions, such as Keccak and SHA-2, in raw place, then  cannot determine how or where any violations
execution time (cycles per byte) [86]. We note that SHA- occurred in the control-flow path followed by the target
256 [8, 9], SHA-512 [41] and SHA-3 [12, 34] have also program from the hash measurement alone [7]. The presence
been employed in existing work, albeit to a lesser extent. of adversarial behaviour can be detected, but its precise
Worryingly, cryptographically broken algorithms have also nature cannot, which may pose difficulties in identifying
been investigated by some schemes (MD5 [41, 48]). and patching any security vulnerabilities. This is due to
Incremental Multi-set hash (MSH) functions: Some CFA the inherent pre-image resistance and avalanching effects
schemes have explored specialised hash functions with of cryptographic hash functions: using just one additional
space-efficient properties. Incremental MSH functions [87] control-flow transfer in the hash computation yields a sig-
take as a collection, or multiset, of arbitrary elements and nificant difference in the resulting hash value.
their occurrences. An MSH function allows one to incremen- A segmented hashing approach has been used to reduce,
tally generate different permutations of the multiset while but not eliminate, the effects of path explosion. Here, the
enabling the testing of equivalence relations. For example, target program is divided into multiple segments, and a
consider the multiset M = {⟨𝐴, 3⟩, ⟨𝐵, 2⟩, ⟨𝐶, 8⟩, ⟨𝐷, 1⟩}, separate hash computation is performed for each segment.
where ⟨𝐴, 3⟩ denotes the element 𝐴 and 3 represents its Atrium [37] considers each loop in the target program as a
number of occurrences (or multiplicity). Consider an MSH separate, independent segment. Let us consider a toy target
value constructed from this multiset where 𝐷 is added to program containing five sequential loops, each of which
an existing ordered set, {𝐴, 𝐵, 𝐶}, i.e. 𝐻1 = {𝐴, 𝐵, 𝐶} ∪ may iterate up to 10 times. A separate hash computation is
𝐷 = {𝐴, 𝐵, 𝐶, 𝐷}. Consider another MSH value, 𝐻2 = performed for each loop.  will generate six hash values to
{𝐷, 𝐵, 𝐴, 𝐶}. An MSH scheme enables one to verify the represent the entire control-flow path, one for each loop, plus
equivalence of 𝐻1 and 𝐻2 . one hash value to represent a control-flow path excluding all
MSH schemes are used by DIAT [45] and CHASE [35]. loops. Consequently,  must only store 51 legitimate hash
They allow the hash value of the set to be efficiently updated values (10 for each of the five loops) and one legitimate for

the control-flow path excluding loops, signfiicantly reducing Another example is RAGE [42], which relies on a ma-
the storage requirements versus a conventional hash-based chine learning-based approach using unsupervised graph
approach (resulting in  storing 100,000 control-flow paths). neural networks to avoid computing a complete CFG of the
Segmented hash computation has also been used to tackle target program. In the training phase,  uses one legitimate
conditional branches and recursive functions [13]. control-flow path represented as a sequence of BBL ad-
dresses as a partial CFG (PCFG) with which feature extrac-
7.2. Other Path Log Representations tion is performed. The features are used to train a Variational
Rather than summarising the control-flow path using Graph Autoencoder (VGAE) model [89] that encodes CFGs
hash values, other proposals have used more sophisticated into a lower-dimensional space (graph embedding). The
methods for logging and representation. ISC-FLAT by Neto legitimate control-flow path is converted to an embedding
& De Oliveira [38] aims to address the problems caused by which serves as a reference. Ten other legitimate and illicit
system interrupts during the measuring process. Consider a control-flow paths are used to set an appropriate threshold
simplified example in which  traverses the nodes 𝑁𝐴 → using the directed Hausdorff distance [90] to quantify the
𝑁𝐵 → 𝑁𝐶 to produce a hash value 𝐻(𝑁𝐴 , 𝑁𝐵 , 𝑁𝐶 ) as difference between two embeddings. During the attestation
part of a legitimate control-flow path run on . In realistic process,  sends a measurement result, a sequence of BBL
scenarios, a software or hardware interrupt may sponta- addresses, executed by the target program to .  inputs this
neously cause another sequence of nodes to be visited mid- data to the VGAE model to produce a new embedding. 
measurement, i.e. 𝑁𝐴 → 𝑁𝐵 → (𝑁𝐸 → 𝑁𝐹 → 𝑁𝐺 ) → compares the embedding with the referenced embedding;
𝑁𝐶 , where (⋅) contains the nodes visited by an interrupt if their distance exceeds a predefined threshold, then it
handler. Hashing these nodes would produce an unintended indicates the detection of attacks. The authors tested their
hash value, undermining the reliability of the measurement proposal using synthetic ROP and DOP attacks, yielding
process.6 results of 0.9803 (ROP) and 0.9101 (DOP) F1-score while
ISC-FLAT addresses this problem by using a TEE-based maintaining a low False Positive Rate of 0.0319.
application to monitor the control-flow transfers of an in-
strumented target program and trapping all interrupt requests 7.3. Whitelist-based Monitoring
within the TEE. The TEE is used to protect the measuring In whitelist-based CFA schemes,  generates an enu-
process from kernel-mode adversaries. When an interrupt is meration of all authorised control-flow transfers in an offline
trapped, the TEE application notes the points at which the phase. In the online phase,  sends a sequence of target
interrupt service routine was activated, which is reflected control-flow transfers taken by the target program to ,
in the report sent to . The system stores path logs of the represented by (src, dst) pairs.  matches each (src, dst) pair
form {𝐴𝑖0 , 𝐴𝑒0 , 𝐴𝑖1 , 𝐴𝑒1 , … , 𝐴𝑖𝑛 , 𝐴𝑒𝑛 }, where 𝐴𝑖𝑥 represents the against the whitelist; any mismatch indicates the occurrence
memory address of the first instruction of node 𝑁𝑥 in the of a control-flow attack. The approach has been used by a
program’s control flow graph, and 𝐴𝑒𝑥 is the destination of a minority of proposals [7, 58].
branching instruction in 𝑁𝑥 . In other words, a sequence of An advantage of whitelist-based measurement is that
addresses and destinations is used to represent the control  has greater visibility over the nature of the control-flow
flow, rather than aggregating them as a single hash value. violation, which can help with patching and remediation
Control-flow abuse is then detected through the inspection efforts. Another advantage is that it demands less storage
of the path log that is sent from  to . space on  than hash-based approaches.  still requires a
BLAST [14] uses Ball-Larus numbering to assign a nu- whitelist to store all legitimate control-flow transfers of the
meric value to each edge of the target program’s CFG. Every target programs, but the path explosion problem is avoided;
possible path is marked by a unique integrity identifier,called the storage requirement is proportional to the number of
pathID, which is the sum of the values of the edges included legitimate control-flow transfers.
in the path. When a function call has finished execution, its A concern with whitelist approaches is the need to mon-
pathID, target address of the function call, and return in- itor, and potentially store, control-flow transfers in real-time.
struction are recorded and stored in shared memory between This can impose significant time and space requirements on
the REE and TEE. When a predetermined length has been . Indeed, if the attestation report is sent to  only after the
reached, the log is sent to measurement module within the target program terminates, the measurement module must
to perform a cumulative hash computation. BLAST can send store the sequence in memory until that point. Indeed, a
two different measurement results. By default,  sends a long sequence of control-flow transfers produces a large
single hash value as a measurement result to . If  cannot attestation report size.
match the value in its database, it requests that  provides One way to mitigate the problem caused long control-
a sequence of tuples <func, pathID>.  then computes the flow transfer sequences is using partial attestation reports.
Whole Program Path (WPP) representation [88] from the Here,  generates a mini-attestation report when specific
sequence and sends it to . requirements are meet—e.g. the configured length of the
6 A naïve solution is to suspend interrupts altogether during the mea-
sequence is reached [34], and particular piece of code fin-
surement process, but this can give rise to wider system issues. ishes [6]—in order to prevent memory exhaustion. Using
partial attestation reports allows  to receive information

1... Normal World Secure World

2 if (read_command(&cmd)) { Normal World Secure World
conditional
3 get_input(&peripheral_input); 11101010...
branches
4 if (status_OK(peripheral_input)) { . . .11. .0010
5 op_func = get_op_func(cmd->op); indirect

Trampoline Measurement
6 (*op_func)(cmd->p_size, ...); jump/calls
1| 2. . .
Stream
Control Flow Library Engine
Instrumentation signed
7 }
8 } ret = ℎ( ⊕ ) ℎ
CVI Check blob
9 ... (part of an operation) src.c src.c
Prover-side Critical Variable
... ... CFI Check
Discovery &
Verifier-side
Instrumentation
ret2 ret3 ret4 ret5 ... Hash' Verification
TEE OS Engine
L3 L4 L5 L6 addr1 Compiler Application
1 1 icall
Attestation
L2 0
0 Blob
Each transfer meets CFG?
L9 L8
Hash' = Hash? Compile-time Runtime Verification
Measurement-guided Path Reconstruction & Verification
Figure 18: Deployment overview of OAT [6].

Figure 17: The OAT verification procedure [6].
verifies the proving application, ’ and  respectively. We

about control-flow paths once certain portions of the target refer the reader back to Figure 6 for an overview of the
program has finished execution without waiting for it to proposal. ’ hosts a ‘control analyser’ that collects control-
terminate. Indeed, partial attestation reports can meet some flow transfers passed from  over a trampoline. ’ has a
scenarios with real-time requirements (see ARI [43]). Com- copy of the known, legitimate CFG that  ought to follow
pression has also been used to minimise the measurement when executing the target platform. As control-flow transfers
results in attestation reports; for example, ReCFA [58] used are passed  → ’, then ’ compares them against the
Zstandard [91], an off-the-shelf compression algorithm, to expected transfers from the CFG, recording any differences
reduce the size of control-flow transfer sequences. in an attestation log. Such differences are logged as a hash
chain, which tracks ID values corresponding to the endpoints
7.4. Abstract Execution of CFG edges, and encrypted using AES in GCM mode. This
Abstract execution [92] is a method for monitoring au- data forms part of the attestation report that can be sent to a
thorised program states by simulating or mimicking the exe- remote verifier, .
cution the proving program. This is principally performed
on the side of  who, after receiving a set of program 7.5. Hybrid Measurement
states from , checks whether it corresponds to a valid set We define hybrid measurement as combining more than
of program states. In the context of CFA, this is similar one of the aforementioned measurement methods. Currently,
to whitelist-based measurements. However, rather than rep- three existing CFA proposals fall into the category, which
resenting control-flow transfers as (𝑠𝑟𝑐, 𝑑𝑠𝑡),  simulates use a combination of hash-based measurement and ab-
the execution of 𝑇 by aggregating control-flow transfers stract execution. LO-FAT [12] uses abstract execution for
using its CFG. The set of states from  is compared with loop paths and hash-based measurement for the rest of the
legitimate, reconstructed paths in order to detect the pres- control-flow path; avoiding hash-based measurements for
ence of control-flow hijacking attacks. The representation of loops avoids the path explosion problem. OAT [6] is the first
control-flow transfers more generally depends on different CFA scheme to explicitly address control-flow and data-only
CFA proposals. One way is to represent indirect control-flow attacks on embedded systems. OAT addresses this through
transfers by its 𝑑𝑠𝑡 value and conditional branches using a a combination of hash-based measurements and compact
binary encoding, where 0 = not taken and 1 = taken [34]. execution traces using software-only techniques in a TEE
Another representation involves assigning dedicated IDs to (ARM TrustZone).
target control-flow transfers [10]. OAT’s system overview is given in Figure 18. The source
Consider the example of the OAT CFA scheme by Sun et program, 𝑇 , undergoes control-flow and critical variable
al. [6]. Here,  starts abstract execution from the root BBL, instrumentation using an LLVM-based compiler. At run-
or the entry point of 𝑇 ’s CFG, and follows forward-edge time, a TEE-based measurement engine consumes applica-
traces.  maintains a simulated call stack to track return tion events through a trampoline library in the normal world.
addresses in memory, computing hash values as  does. The engine checks the integrity of ‘critical variables’, which
Violations are detected when a mismatch is found between are identified by developers, using value-based approach to
the current BBL and its trace, i.e. the block ends with an reduce performance overhead. More specifically, it checks
indirect call when the next element is a branch; the computed whether the value at an instrumented load instruction is the
hashes do not equal known ‘safe’ values; or the addresses same as the value recorded at its previous instrumented store
are not valid.  terminates the abstract execution when it instruction. The engine also measures CFI using a combi-
encounters a BBL whose final instruction is not a control- nation of traces for forward-edge control flow transfers (i.e.
flow transfer. We illustrate the OAT verification procedure branches and indirect calls/jumps), and hash-based measure-
in Figure 17. ments for backward-edge transfers (returns) using BLAKE2.
GuaranTEE [10] focuses on intra-platform attestation Traces and hashes are combined to form an ‘attestation blob’
between two TEE-enabled applications, one which locally that is sent to . After receiving the blob,  abstractly

Figure 19: Workflow of ARI by Wang et al. [43].
while hash-based measurements assess backward control-

flow transfers. The basic steps are as follows:
1. Within 𝑇 , when a control-flow transfer is executed,
the measurement module checks the type of transfer
and performs the corresponding operations:
(a) For conditional branches, it outputs {0, 1} to
indicate whether or not the branch is taken.
(b) For indirect jumps and function calls, the mea-
surement module outputs the BBL dst.
(c) For a return instruction, it records the return
address, 𝑟𝑒𝑡𝑎𝑑𝑑𝑟 , and computes a hash value as
shown in Equation 3.
𝐻𝑛𝑒𝑤 = 𝐻(𝐻𝑝𝑟𝑒𝑣 ⊕ 𝑟𝑒𝑡𝑎𝑑𝑑𝑟 ) (3)
Figure 20: ARI’s verification procedure executed by  [43].
2.  sends a sequence of control-flow transfers and the
final hash value as an attestation report upon request
from .
executes 𝑇 using its CFG by starting from its entry BBL
to reconstruct the measurement hatch, which we described 3.  simulates the call stack to track return addresses
previously in §7.4. through abstract execution. When the execution en-
ARI by Wang et al. [43] focusses on challenges in attest- counters a BBL that ends with procedure call, and if
ing autonomous cyber-physical systems. ARI relies on the the control-flow transfer is authorised, the function’s
decomposition of mission-critical software into sandboxed return address is pushed onto the stack. Later, when
‘compartments’, which are monitored using a combination abstract execution reaches a BBL which ends with a
of control- and data-flow techniques. Compartments are return instruction,  inspects the return address from
isolated using a memory protection unit or with software- the top of the stack to determine the direction of
based instrumentation. A trust anchor based on TEEs (ARM execution, before popping the return address from the
TrustZone or RISC-V Keystone) or a dedicated hardware stack. The hash is calculated in the same way as the
module is suggested. ARI monitors control flows between measurement module does during runtime.
compartments, e.g. hashes of return addresses on the stack;
data flows of critical variables; transfers between compart- 4. If no violations are detected during abstract execution,
ments; and event timestamps. What is defined as a ‘critical’  compares the computed hash value with the one
component or data is set using a policy-based approach. reported by . A match indicates no control-flow
These policies are translated into appropriate instrumen- attacks were detected, while a mismatch suggests the
tations using an LLVM-based compiler. During 𝑇 ’s exe- occurrence of an attack.
cution, a recording engine captures control and data flow We note that the results of abstract execution are used
events in the form of an event log, inspired by aircraft flight alongside known static values. In ARI, data-flow integrity is
recorders. The workflow of ARI is given in Figure 19. In assessed simultaneously using a value-based approach (i.e.
Figure 20, the verification procedure is given, whereby the inspecting the value of critical variables between store and
application is re-executed and different control- and data- load operations). Supplementary information, such as timing
flow measurements are calculated and compared with taht profiles, may also be used [43] (see Figure 20).
sent by . Using abstract execution for forward control-flow trans-
The abstract execution methods of OAT [6] and ARI fers and hash-based measurement for backwards control-
[43] use similar techniques. Both proposals use simulated flow transfers inherits advantages of both approaches. Firstly,
execution on  for verifying forward control-flow transfers, it provide space-efficiency by shortening the length of mea-
surement results. Sun et al. [6] argued that target programs

typically execute a large number of return instructions, • - paradigm: We give the prover-verifier (-)
i.e. backward control-flow transfers. Hashing is naturally paradigm used by the proposal; for example, whether
space-efficient over listing them sequentially, significantly it uses a conventional remote attestation, hybrid, or
reducing the size of the measurement result. Indeed, OAT another approach described in §4.
reported an average size reduction of 97% [6].
A second advantage is that it ameliorates a major draw- • Target control-flow transfers: The types of control-
back of hash-based measurements: the requirement for  to flow transfers that are monitored by the proposal using
store all possible control-flow paths and their corresponding those discussed in §2.2.
hash values. Return addresses, which serve as input of hash • Target control-flow attacks: The types of control-
computation, are obtained by abstract execution based on flow attacks addressed by the scheme, which were
memory addresses of function call. As such,  does not have discussed in §2.1. We further annotate this column as
to know learn possible backward control-flow paths during follows: a ‘MP’ label is used where the proposal as-
the offline phase, but instead only the final value. sumes a memory protection mechanism to be in place,
However, hybrid methods still inherit a significant disad- such as data execution prevention or non-writable
vantage of hash-based approaches. Specifically, if the hash code regions. ‡ indicates that the proposal monitors
value from the measurement result does not match the one only specific sections of the target program, not the
obtained from abstract execution, then  does not know program in its entirety. ± is used when the proposal
what backward control-flow path was violated. This limits uses a machine learning or statistical model to detect
’s ability to precisely identify potential vulnerabilities that control-flow attacks; that is, whether an attack is de-
exploit return addresses (e.g. as used by ROP attacks). tected is probabilistic, not a certainty.
8. Evaluation 8.2. Discussion and Analysis

Some trends can be observed in the development of
A significant number of control-flow attestation propos- CFA proposals. Firstly, it is noteworthy that the use of
als have been published in the past decade. To aid in future CPU extensions and hardware modules as trust anchors and
research, we consolidate and compare these publications, instrumentation methods were used frequently in the earlier
their features and shortcomings against a common set of literature (2017–2019) [7, 12, 34, 35, 37, 47]. Such proposals
criteria. In total, we have identified 31 distinct proposals that require deep modifications to open-source CPU or SoC de-
fall under the definition of control-flow attestation published signs, which are not commercially available. In more recent
between the years 2016 and 2024. In this section, we de- work, there is a shift towards those that rely on off-the-shelf
scribe the criteria used to compare such works based broadly technologies, such as proprietary trace modules, memory
on the sections presented hitherto. protection units, performance monitoring units, and kernel-
mode implementations (2020–2024) [5, 36, 39, 48, 58, 68].
8.1. Comparison Criteria The use of proprietary, hardware-assisted methods, such as
Table 2 summarises the CFA proposals found in the Intel SGX and ARM TrustZone, has remained dominant
state of the art in chronological order. We extracted the key over the years, representing the greatest proportion of CFA
features from each proposal based on the areas presented proposals (16/31, ≈52%) [4, 6, 7, 9, 10, 11, 11, 14, 38, 40,
previously in Figure 3. More specifically, we consider the 42, 43, 45, 46, 49, 60].
following criteria: There is a clear tension with the use of proprietary
technologies and custom architectures. The former tends to
• Trust anchor: The root-of-trust upon which the pro-
be widely available and easily accessible to researchers and
posal relies in order to uphold its security, e.g. a
potential end-users, e.g. software developers. However, this
TEE, custom CPU extensions, an external hardware
comes at the cost of limited flexibility in monitoring control-
module, or another method described in §5.
flow transfers close to hardware. Custom architectures ad-
• Measurement approach: The way in which control dress this by monitoring events close to the CPU’s instruc-
flow is measured during the execution of the target tion pipeline, providing the greatest degree of granularity,
program, as described in §7. but at the cost of lacking compatibility with consumer off-
the-shelf platforms.
• Instrumentation method: The method by which the Many CFA schemes claimed the ability to detect code
target program is modified to capture control-flow injection attacks, i.e. (A.1). However, a significant minority
events from §6. of proposals (7/30, ≈23%) do not provide this due to fea-
tures bestowed by the scheme itself. Rather, they make as-
• Full implementation?: We observed that several pro-
sumptions regarding on the availability of mechanisms that
posals make recommendations for ideal trust anchors
enforce some aspect of the target program’s immutability;
and instrumentation methods, but which are neither
for example, using executable-space, data execution preven-
implemented nor evaluated in the proposal. We make
tion, and other memory protection mechanisms [12, 47].
this distinction explicit in our comparison.
LO-FAT, for instance, assumes that “the adversary cannot

Table 2
A summary of CFA proposals using the comparison criteria from §8.1.
Proposal Year Trust Anchor Measurement Instrumentation FI? - Target Control- Control-Flow
Approach Method Paradigm Flow Transfers Attacks
C-FLAT [4] 2016 TEE (ARM Trust- Hash-based Binary Rewriting ✓ Conventional (C.1) (A.1)(A.2)
Zone) (A.3)¶
LO-FAT [12] 2017 CPU Extensions Hybrid ▴ ✓ Conventional (C.1) (A.1)(MP)
(A.2)(A.3)¶
ATRIUM [37] 2017 CPU Extensions Hash-based ▴ ✓ Conventional (C.1) (A.1)(A.2)†
(A.3)¶
LiteHAX [34] 2018 CPU Extensions Abstract Ex- ▴ ✓ Continuous (C.1) (A.1)(A.2)†
ecution Reporting (A.3)(A.4)
CHASE [35] 2019 CPU Extensions Hash-based ▴ ✓ Conventional (C.8)† (A.1)(A.2)
(MSH) (A.3)¶
DIAT [45] 2019 TEE* Hash-based Binary Rewriting † ✗ Collective (C.8) (A.1)‡(A.2)‡
(MSH) (A.3)‡¶
(A.4)‡¶
G&R [47] 2019 Hardware Module ▴ ▴ ✓ Conventional (C.2)(C.3)(C.4) (A.1)(MP)
(C.7) (A.2)(A.3)(A.4)
Liu et al. [7] 2019 TEE (ARM Trust- Whitelist Binary Rewriting ✓ Conventional (C.2)(C.3)(C.5) (A.1)(A.2)
Zone) + PUF (C.6)(C.7) (A.3)¶
MGC-FA [11] 2019 TEE (ARM Trust- Hash-based Compiler (GCC ✓ Conventional (C.8) (A.1)±(A.2)±†
Zone) and Capstone) (A.3)±¶
RADIS [8] 2019 TEE* Hash-based Dynamic† ✗ Collective (C.1) (A.1)(A.2)†
ScaRR [13] 2019 Kernel Hash-based Compiler (LLVM) ✓ Conventional (C.2)(C.3)(C.5) (A.1)(A.2)
(C.6)(C.7)
CFPA [60] 2019 TEE* ★ ★ ✗ Conventional ★ (A.1)(A.2)
(A.3)¶
DO-RA [46] 2020 TEE (ARM Trust- Hash-based Binary Rewriting ✓ Conventional (C.2)(C.5)(C.6) (A.1)(MP)
Zone) (C.7) (A.2)† (A.3)
LAPE [48] 2020 MPU Hash-based Compiler (LLVM) ✓ Conventional (C.3)(C.6) (A.1)(A.2)
OAT [6] 2020 TEE (ARM Trust- Hybrid Compiler (LLVM) ✓ Hybrid (C.2)(C.5)(C.6) (A.1)‡(MP)
Zone) (C.7) (A.2)‡† (A.3)‡
(A.4)
ARCADIS [41] 2021 ROM Hash-based Binary Rewriting † ✗ Collective (C.1) (A.1)(A.2)
GACFA [9] 2021 TEE (Intel SGX) Hash-based Dynamic (Intel ✓ Conventional (C.8) (A.1)±(A.2)±
Pin) (A.3)±¶
ReCFA [58] 2021 Kernel Whitelist Binary Rewriting ✓ Conventional (C.2)(C.5)(C.6) (A.1)(MP)
(C.7)(C.3)¶ (A.2)†
Tiny-CFA [62] 2021 Hardware Module ▴ Binary Rewriting ✓ Conventional (C.1) (A.1)(A.2)¶
(A.3)
Papamartzivanos 2021 Trace Module (In- ▴ ▴ ✓ Conventional (C.2)†(C.4)(C.7)† (A.1)(A.2)
et al. [68] tel PT)
BDFCFA [40] 2022 TEE (Intel SGX) Hash-based Dynamic (Intel ✓ Conventional (C.1) (A.1)(MP)
Pin) (A.2)¶ (A.3)¶
Ben Yehuda et 2022 Kernel Hash-based Binary Rewriting ✓ Conventional (C.1) (A.1)(A.2)
al. [39] (A.3)¶
CFRV [49] 2022 TEE (ARM Trust- Hash-based Compiler (LLVM) ✓ Collective (C.1) (A.1)(A.2)¶
Zone)
GuaranTEE [10] 2022 TEE (Intel SGX) Abstract Ex- Compiler (LLVM) ✓ Hybrid (C.4)(C.5)(C.6) (A.1)(A.2)¶
ecution (C.7)
ACFA [44] 2023 Hardware Module Abstract Ex- ▴ ✓ Continuous (C.1) (A.1)(A.2)
(On-chip) ecution Reporting
ARI [43] 2023 TEE (ARM Trust- Abstract Ex- Compiler (LLVM) ✓ Conventional (C.8) (A.1)(A.2)(A.3)
Zone) ecution
BLAST [14] 2023 TEE (ARM Trust- Path Log Compiler (LLVM) ✓ Conventional (C.2)(C.3)(C.5) (A.1)(MP)
Zone) (C.6)(C.7) (A.2)¶†
ISC-FLAT [38] 2023 TEE (ARM Trust- Path Log Binary Rewriting ✓ Conventional (C.1) (A.1)¶ (A.2)¶
Zone)
ZEKRA [36] 2023 Trace Module* Hash-based ▴* ✗ VC (C.1) (A.1)(A.2)
RAGE [42] 2024 TEE* Path Log Dynamic ✗ Conventional (C.1) (A.2)±¶
(A.4)±¶
LightFAt [5] 2024 PMU Path Log Dynamic ✓ Conventional (C.1) (A.1)±(A.2)±
*: Recommended for a complete implementation but not evaluated. ▴: Hardware detection circuit. †: Suspected based on publicly available
information. ¶: Partially addresses. ★: This work sketches a property-based CFA scheme and high-level requirements; it is neither implemented
nor evaluated. ‡: Uses a probabilistic approach. ±: Applies to only portions of the target program.

modify program code at run-time (marked as rx)” (p. 3, [12]) performing the challenge at launch-time, for example, would
as an implicit requirement for a memory protection mecha- be insufficient in detecting transient attackers.
nism. Geden & Rasmussen [47] requires non-writable code A final point of note is the relative lack of focus on direct
regions and non-executable data regions. In a TEE-based data manipulation (DDM) and data-oriented programming
scheme, OAT [6] assumes that the attackers cannot tamper (DOP) attacks: (A.3) and (A.4) respectively. 16/31 (≈52%)
with the instrumented code or the trampoline library in the and only 5/31 (≈16%) proposals address (A.3) and (A.4),
normal world, citing some memory protection methods for again respectively. We have mentioned that DOP attacks
embedded devices as potential solutions [93, 94].7 represent a highly sophisticated attacker (see §2.1 and [34]).
We observe that ROP attacks are the primary threat in The principal focus of CFA schemes is on direct control flow
schemes that address code reuse attacks, (A.2). Such pro- attacks, (A.1) and (A.2), rather than data flow attacks, even
posals add detection mechanisms to control-flow transfers though the latter can influence the former indirectly. Indeed,
that return from functions. Some work, e.g. C-FLAT [4] some schemes explicitly declare data-flow attacks to be out-
and GuaranTEE [10], address a particular variant in which a of-scope, even though their potential effects on control-flow
function is invoked from multiple calling locations. Suppose are recognised [4, 60]. Preventing data-oriented attacks is
there are two legitimate control-flow paths, 𝐴 → 𝐵 → 𝐶 a burgeoning area of research [96], and it is our belief that
and 𝐷 → 𝐵 → 𝐸, where 𝐵 is a vulnerable function. An designing attestation schemes that detect control- and data-
attacker may perform an attack to alter the control-flow path flow attacks is an important direction going forwards.
to 𝐷 → 𝐵 → 𝐶, which still visits legitimate CFG nodes
and may not be detected as an illicit path. This has been
addressed through the use of shadow stacks [7, 13, 47, 58]. 9. Open Problems and Recommendations
When a call-based control-flow transfer is executed, if its This section discusses research gaps and makes sugges-
target address is valid, then its call-after point will be pushed tions and recommendations for future work in the field.
on this shadow stack. For a return-based transfer, if its target
address is valid based on CFG, then  checks if it is identical 9.1. Platform Dependencies
to the top element of the shadow stack. If it is not, a control- We observed that many CFA schemes rely on proprietary
flow hijacking attack would be detected. If it matches, the platform features, such as Intel PT for measuring control-
top element is popped from the stack. Call-return matching flow traces, and Arm TrustZone for protecting code integrity.
is another solution in which  marks legitimate pairs of call This can negatively affect the potential longevity of propos-
and return control-flow transfers within the scheme’s offline als if certain features are made obsolete by platform vendors.
phase, which are measured at run-time [4]. We note, for example, that Intel SGX was recently discon-
All CFA proposals claimed that code reuse attacks can be tinued for consumer devices (Intel Core CPUs), limiting the
detected to some extent; however, only 11/31 (≈35%) specif- applicability of relevant CFA schemes that depend on it. It is
ically mentioned call-return matching or shadow stacks as possible that analogous technologies may be present on other
well-known countermeasures [4, 6, 7, 13, 34, 35, 36, 38, platforms, e.g. Arm TrustZone over Intel SGX, and that the
43, 47, 58]. In some instances, details about the call-return main idea of the scheme can still be applied. Nevertheless,
matching implementation have not been discussed fully [34]. not every TEE offers the same security properties. We urge
The propensity to focus on ROP attacks is notable. In recent caution when translating schemes to other platforms and the
years, other code reuse attacks have been developed, such impact this has on reducing the CFA scheme’s security.
as COP and JOP attacks, while only ROP attacks have
been demonstrated. In future work, we urge that researchers ⋄ Recommendation: We recommend that authors re-
demonstrate a wider range of code reuse attacks, such as lying on platform-specific security features for their
COP, JOP, return-to-libc, and ROP attacks. CFA schemes offer alternatives for those features on
In a related challenge, many proposals attest the program other platforms. Alternatively, authors ought to con-
at launch-time, which can give rise to TOCTOU attacks if sider generic constructions that are agnostic to partic-
an adversary conducts an attack before or after an attes- ular platform features.
tation challenge. Continuous reporting proposals explicitly
aim to address this challenge [34, 44] (see §4.2), where  9.2. Limited Deployment Scenarios
actively actively sends measurements to . However, this During the course of this work, it became evident that
paradigm is used by a very small number of proposals (2/31, CFA proposals tend to evaluated in laboratory conditions or
≈6%). Conventional attestation schemes may still detect this using fixed datasets, e.g. SPEC CPU benchmarks, that do
by  storing measurements until they are requested by  not replicate many real-world scenarios. In particular, we
(see ARCADIS [41]). Yet, this relies on  determining recognised that CFA schemes do not consider long-running
an appropriate timeframe to issue the challenge. Simply applications, like those that control sensors and actuators.
Such programs may execute a large number of control-flow
7 We note that, in some cases, it is possible to bypass memory protection
transfers during run-time. For schemes that measure control-
mechanisms, e.g. DEP, using ROP-style attacks. To this end, we refer the flow transfers,  might receive large attestation reports; in a
reader to work by Göktas et al. [95].
path-based scheme,  may find it challenging, if not infea-
sible, to obtain all legitimate control-flow paths due to the

enormous state space. We observed that very few proposals and adversarial models. We note that evaluations tend to
(e.g. OAT [6]) support customisable code attestation, which be conducted in an ad hoc manner, employing different
could alleviate this problem. test programs, metrics, and baselines. Consequently, it is
A large number of proposals rely on the submission difficult to evaluate CFA schemes in order to compare their
of program inputs in order to trigger a measurement of relative effectiveness. Some proposals have evalauted com-
traversed CFG notes. This paradigm may cause issues in ap- mon programs. In particular, the open syringe pump is the
plications where the program inputs do not traverse affected most common, which is an embedded program for remotely
nodes, e.g. affected by a code injection attack. For example, controlling liquid injections in medical applications. This
consider a device that accepts a significant number of inputs, has been used by seven CFA proposals [4, 6, 12, 34, 38,
such as a robotic arm or another cyber-physical system () 43, 62] that are designed for embedded devices. Using more
that communicates with a remote control service (). What general benchmarks is another choice in evaluation. SNU
parameters should  submit to ? Is it possible that the sup- Real-Time Benchmark is the most common one evaluated
plied parameters could unintentionally miss malicious code by three proposals [9, 11, 40]. Some proposals [14, 36, 42]
within a larger complex program? These questions, among published recently opt for Embench-IOT benchmark suite
others, have received limited attention in the literature. [97]. However, they are not designed for CFA schemes.
It is also conceivable that  relies on sensitive data that Besides performance evaluations, the lack of uniform
 cannot reasonably access, such as personally identifiable test vectors for evaluating security is also a notable omission
information or security-sensitive sensor data. Unfortunately, in the literature. CRFV [49] uses the RIPE [98] benchmark
we found that authors rarely discuss application- or domain- to evaluate the capability of code injection attacks and ROP
specific implications, even though it may impact the deploy- attack detection. Some proposals (e.g., C-FLAT [4]) involve
ability of a CFA scheme in practice. manual attacks that redirect the target program’s control flow
in the evaluation. Chilese et al. [42] evaluate their proposals
⋄ Recommendation: We advise that authors describe through a synthetic attack trace generation approach. They
the deployment assumptions and some challenges that develop generators that modify legitimate control-flow paths
may arise therein under realistic scenarios. In con- to compromised ones under ROP and DOP attacks to simu-
junction with the recommendation in §9.4, it may be late the two attacks.
useful to develop evaluation approaches and datasets
that reflect real-world problems in common domains ★ Research Question: To what extent can a benchmark-
of interest, e.g. cyber-physical systems. ing suite be developed for CFA schemes that evaluates
different control-flow attacks in a uniform manner?
9.3. Closed-source Implementations
We also became aware that most CFA proposals are pre- 9.5. Addressing Physical Attacks
sented without any publicly available artefacts. This is par- Many papers deem physical attacks on the devices as
ticularly crucial when a scheme demands extensive low-level outside the scope of their threat models [8, 47]. This is
changes, such as custom CPU extensions as FPGA/HDL acceptable where we can safely assume that adversaries
modules, binary-level modifications, custom kernel mod- are strictly remote or software-based ones. However, many
ules, and new assembly routines. A severe cost can be CFA schemes are designed for embedded systems, which
imposed to students and researchers who may wish to rapidly may be deployed in largely unsupervised environments,
prototype or compare multiple schemes. We also observe such as industrial control systems and critical national in-
that key implementation aspects are sometimes left unde- frastructure. The value of such devices to adversaries may
fined, such as the method of instrumentation, and some bring increase the viability of physical attacks, such as fault
schemes are not fully implemented (6/31, ≈20%). injection and side-channel attacks. Indeed, the authors of
Ultimately, this may lead to unfaithful implementations OAT state: “We trust code running inside the Secure World
and evaluations, impeding the reproducibility of some pro- (e.g., the measurement engine) and assume that attackers
posals. Additionally, a few proposals with closed-source cannot break the TrustZone protection. We also trust our
implementations do not describe the types of target control- compiler and the trampoline code. We assume that attackers
flow transfers or how  performs CFI checks, which in- cannot inject code in the Normal World or tamper with the
creases the difficulty for us to identify which specific types instrumented code or the trampoline library” [6]. It is widely
of control-flow attacks they can detect. known that TEEs are susceptible to hardware attacks [50].
We pose this as a significant gap in the literature, and urge
⋄ Recommendation: We strongly recommend that au- the development of CFA schemes that consider such threats.
thors open-source CFA schemes in the pursuit of
open science and reproducibility. Schemes that rely on ★ Research Question: To what extent can existing CFA
hardware extensions and low-level software modifica- schemes be made explicitly resilient to physical hard-
tions are of particular importance. ware attacks, such as fault injections?
9.4. On the Need for Common Benchmarks 9.6. Extended Attestation Paradigms
A wide variety of CFA schemes have been proposed in The vast majority of CFA schemes follow a traditional
the scientific literature with a myriad of system architectures remote attestation with a single has a rich, longstanding

history dating back to the inception of the Trusted Plat- [10] M. Morbitzer, B. Kopf, and P. Zieris, “GuaranTEE: Introducing
form Modules (TPM) in the early-2000s. We recognise control-flow attestation for trusted execution environments,” in 16th
that some different approaches to attestation, which were International Conference on Cloud Computing, IEEE, 2023.
[11] J. Hu, D. Huo, M. Wang, Y. Wang, Y. Zhang, and Y. Li, “A
developed for TPM-based platforms, have not yet been ap- probability prediction based mutable control-flow attestation scheme
plied to the domain of control-flow attestation. In particular, on embedded platforms,” in 18th IEEE Int’l Conference on Trust,
property-based [61], direct anonymous [99], and mutual Security and Privacy in Computing and Communications, IEEE,
attestation [100] have not been fully adapted to CFA. We 2019.
believe that these areas are fruitful avenues for researchers [12] G. Dessouky, S. Zeitouni, T. Nyman, A. Paverd, L. Davi, P. Koeberl,
N. Asokan, and A.-R. Sadeghi, “LO-FAT: Low-overhead control
in the field. flow attestation in hardware,” in 54th Annual Design Automation
Conference, 2017.
★ Research Question: To what extent can other at- [13] F. Toffalini, E. Losiouk, A. Biondo, J. Zhou, and M. Conti, “ScaRR:
testation paradigms, such as PBA, DAA and mutual Scalable runtime remote attestation for complex systems,” in 22nd
attestation, be integrated into control-flow attestation? Int’l Symposium on Research in Attacks, Intrusions and Defenses,
2019.
[14] N. Yadav and V. Ganapathy, “Whole-program control-flow path
10. Conclusion attestation,” in ACM SIGSAC Conference on Computer and Com-
munications Security, 2023.
In this paper, we presented a comprehensive analysis of [15] R. V. Steiner and E. Lupu, “Attestation in wireless sensor networks:
control-flow attestation as it is currently realised in the state A survey,” ACM Computing Surveys, vol. 49, no. 3, pp. 1–31, 2016.
of the art, exploring the concepts, solutions, techniques and [16] O. Arias, F. Rahman, M. Tehranipoor, and Y. Jin, “Device attes-
tation: Past, present, and future,” in Design, Automation & Test in
assumptions of 31 proposals in the field. We categorised Europe Conference & Exhibition (DATE), pp. 473–478, IEEE, 2018.
existing CFA proposals based on their key features using [17] I. Sfyrakis and T. Gross, “A survey on hardware approaches
a common set of criteria, including their instrumentation for remote attestation in network infrastructures,” arXiv preprint
method, target control-flow transfers, attacks addressed, at- arXiv:2005.12453, 2020.
testation paradigm, and more. Based on this, we presented a [18] W. A. Johnson, S. Ghafoor, and S. Prowell, “A taxonomy and review
of remote attestation schemes in embedded systems,” IEEE Access,
series of open challenges and recommendations for steering vol. 9, pp. 142390–142410, 2021.
future research in the field. Through our work, we hope it can [19] S. F. J. J. Ankergård, E. Dushku, and N. Dragoni, “State-of-the-art
enhance the reader’s understanding of the capabilities and software-based remote attestation: Opportunities and open issues for
considerations involved in designing and analysing control- Internet of Things,” Sensors, vol. 21, no. 5, p. 1598, 2021.
flow attestation schemes, and the challenges that lie ahead. [20] B. Kuang, A. Fu, W. Susilo, S. Yu, and Y. Gao, “A survey of
remote attestation in internet of things: Attacks, countermeasures,
and prospects,” Computers & Security, vol. 112, p. 102498, 2022.
[21] M. Ambrosin, M. Conti, R. Lazzeretti, M. M. Rabbani, and
References S. Ranise, “Collective remote attestation at the internet of things
[1] M. Abadi, M. Budiu, U. Erlingsson, and J. Ligatti, “Control-flow in- scale: State-of-the-art and future challenges,” IEEE Communica-
tegrity principles, implementations, and applications,” ACM Trans- tions Surveys & Tutorials, vol. 22, no. 4, pp. 2447–2461, 2020.
actions on Information and System Security, vol. 13, 2009. [22] N. Burow, S. A. Carr, J. Nash, P. Larsen, M. Franz, S. Brunthaler,
[2] V. Kuznetzov, L. Szekeres, M. Payer, G. Candea, R. Sekar, and and M. Payer, “Control-flow integrity: Precision, security, and per-
D. Song, “Code-pointer integrity,” in The Continuing Arms Race: formance,” ACM Computing Surveys, vol. 50, no. 1, 2017.
Code-Reuse Attacks and Defenses, pp. 81–116, ACM, 2018. [23] R. De Clercq and I. Verbauwhede, “A survey of hardware-based
[3] T. Abera, N. Asokan, L. Davi, F. Koushanfar, A. Paverd, A.-R. control flow integrity (CFI),” arXiv preprint arXiv:1706.07257,
Sadeghi, and G. Tsudik, “Things, trouble, trust: on building trust in 2017.
iot systems,” in 53rd Annual Design Automation Conference, 2016. [24] P. Muntean, M. Neumayer, Z. Lin, G. Tan, J. Grossklags, and
[4] T. Abera, N. Asokan, L. Davi, J.-E. Ekberg, T. Nyman, A. Paverd, C. Eckert, “Analyzing control flow integrity with LLVM-CFI,” in
A.-R. Sadeghi, and G. Tsudik, “C-FLAT: Control-flow attestation 35th Annual Computer Security Applications Conference, 2019.
for embedded systems software,” in ACM SIGSAC Conference on [25] S. Chen, J. Xu, E. C. Sezer, P. Gauriar, and R. K. Iyer, “Non-control-
Computer and Communications Security, 2016. data attacks are realistic threats,” in USENIX Security Symposium,
[5] J. Gonzalez-Gomez, H. Nassar, L. Bauer, and J. Henkel, “Light- vol. 5, p. 146, 2005.
FAt: Mitigating control-flow explosion via lightweight PMU-based [26] H. Shacham, “The geometry of innocent flesh on the bone: Return-
control-flow attestation,” in IEEE International Symposium on into-libc without function calls (on the x86),” in 14th ACM Confer-
Hardware Oriented Security and Trust, pp. 222–226, IEEE, 2024. ence on Computer and Communications Cecurity, 2007.
[6] Z. Sun, B. Feng, L. Lu, and S. Jha, “OAT: Attesting operation [27] A. Homescu, M. Stewart, P. Larsen, S. Brunthaler, and M. Franz,
integrity of embedded devices,” in IEEE Symposium on Security and “Microgadgets: Size does matter in Turing-complete return-oriented
Privacy, pp. 1433–1449, IEEE, 2020. programming,” Workshop on Offensive Technologies, 2012.
[7] J. Liu, Q. Yu, W. Liu, S. Zhao, D. Feng, and W. Luo, “Log-based [28] T. Bletsch, X. Jiang, V. W. Freeh, and Z. Liang, “Jump-oriented pro-
control flow attestation for embedded devices,” in 11th Interna- gramming: a new class of code-reuse attack,” in 6th ACM Symposium
tional Symposium on Cyberspace Safety and Security, pp. 117–132, on Information, Computer and Communications Security, 2011.
Springer, 2019. [29] N. Carlini and D. Wagner, “ROP is still dangerous: Breaking modern
[8] M. Conti, E. Dushku, and L. V. Mancini, “RADIS: Remote attesta- defenses,” in 23rd USENIX Security Symposium, pp. 385–399, 2014.
tion of distributed IoT services,” in 6th International Conference on [30] A. Sadeghi, S. Niksefat, and M. Rostamipour, “Pure-call oriented
Software Defined Systems, pp. 25–32, IEEE, 2019. programming (pcop): chaining the gadgets using call instructions,”
[9] J. Zhan, Y. Li, Y. Liu, H. Li, S. Zhang, and L. Lin, “NSGA-II- Journal of Computer Virology and Hacking Techniques, 2018.
based granularity-adaptive control-flow attestation,” Security and [31] S. Chen, J. Xu, E. C. Sezer, P. Gauriar, and R. K. Iyer, “Non-control-
Communication Networks, vol. 2021, pp. 1–16, 2021. data attacks are realistic threats,” in USENIX Security Symposium,

vol. 5, p. 146, 2005. [50] C. Shepherd, K. Markantonakis, N. Van Heijningen, D. Aboulkas-

[32] H. Hu, S. Shinde, S. Adrian, Z. L. Chua, P. Saxena, and Z. Liang, simi, C. Gaine, T. Heckmann, and D. Naccache, “Physical fault injec-
“Data-oriented programming: On the expressiveness of non-control tion and side-channel attacks on mobile devices: A comprehensive
data attacks,” in IEEE Symposium on Security and Privacy, IEEE, analysis,” Computers & Security, vol. 111, p. 102471, 2021.
2016. [51] P. Koeberl, S. Schulz, A.-R. Sadeghi, and V. Varadharajan,
[33] K. K. Ispoglou, B. AlBassam, T. Jaeger, and M. Payer, “Block ori- “TrustLite: A security architecture for tiny embedded devices,” in
ented programming: Automating data-only attacks,” in Proceedings 9th European Conference on Computer Systems, 2014.
of the ACM SIGSAC Conference on Computer and Communications [52] F. Brasser, B. El Mahjoub, A.-R. Sadeghi, C. Wachsmann, and
Security, pp. 1868–1882, 2018. P. Koeberl, “TyTAN: Tiny trust anchor for tiny devices,” in 52nd
[34] G. Dessouky, T. Abera, A. Ibrahim, and A.-R. Sadeghi, “LiteHAX: Annual Design Automation Conference, 2015.
lightweight hardware-assisted attestation of program execution,” in [53] W. Arthur, D. Challener, and K. Goldman, A practical guide to
IEEE/ACM International Conference on Computer-Aided Design, TPM 2.0: Using the new trusted platform module in the new age
pp. 1–8, IEEE, 2018. of security. Springer Nature, 2015.
[35] G. Dessouky, S. Zeitouni, A. Ibrahim, L. Davi, and A.-R. Sadeghi, [54] M. Reveilhac and M. Pasquet, “Promising secure element alterna-
“CHASE: A configurable hardware-assisted security extension for tives for NFC technology,” in 1st International Workshop on Near
real-time systems,” in IEEE/ACM International Conference on Field Communication, pp. 75–80, IEEE, 2009.
Computer-Aided Design, pp. 1–8, IEEE, 2019. [55] S. Mavrovouniotis and M. Ganley, “Hardware security modules,”
[36] H. B. Debes, E. Dushku, T. Giannetsos, and A. Marandi, “ZEKRA: in Secure Smart Embedded Devices, Platforms and Applications,
Zero-knowledge control-flow attestation,” in Proceedings of the pp. 383–405, Springer, 2013.
ACM Asia Conference on Computer and Communications Security, [56] S. Schulz, A.-R. Sadeghi, and C. Wachsmann, “Lightweight remote
pp. 357–371, 2023. attestation using physical functions,” in Proceedings of the 4th ACM
[37] S. Zeitouni, G. Dessouky, O. Arias, D. Sullivan, A. Ibrahim, Conference on Wireless Network Security, pp. 109–114, 2011.
Y. Jin, and A.-R. Sadeghi, “Atrium: Runtime attestation resilient [57] C. Shepherd and K. Markantonakis, Trusted Execution Environ-
under memory attacks,” in IEEE/ACM International Conference on ments. Springer, 2024.
Computer-Aided Design, pp. 384–391, IEEE, 2017. [58] Y. Zhang, X. Liu, C. Sun, D. Zeng, G. Tan, X. Kan, and S. Ma,
[38] A. J. Neto and I. D. O. Nunes, “ISC-FLAT: On the conflict between “ReCFA: Resilient control-flow attestation,” in Annual Computer
control flow attestation and real-time operations,” in IEEE 29th Security Applications Conference, pp. 311–322, 2021.
Real-Time and Embedded Technology and Applications Symposium, [59] V. Costan and S. Devadas, “Intel SGX explained,” Cryptology ePrint
pp. 133–146, IEEE, 2023. Archive, 2016.
[39] R. Ben Yehuda, M. Kiperberg, and N. J. Zaidenberg, “Nanovised [60] N. Koutroumpouchos, C. Ntantogian, S.-A. Menesidou, K. Liang,
control flow attestation,” Applied Sciences, vol. 12, no. 5, p. 2669, P. Gouvas, C. Xenakis, and T. Giannetsos, “Secure edge computing
2022. with lightweight control-flow property-based attestation,” in IEEE
[40] H. Li, T. Shen, F. Bai, and B. Gong, “Blockchain-assisted distributed Conference on Network Softwarization, pp. 84–92, IEEE, 2019.
fog computing control flow attestation,” Security and Communica- [61] A.-R. Sadeghi and C. Stüble, “Property-based attestation for com-
tion Networks, vol. 2022, 2022. puting platforms: Caring about properties, not mechanisms,” in
[41] R. M. Halldórsson, E. Dushku, and N. Dragoni, “ARCADIS: asyn- Proceedings of the Workshop on New Security Paradigms, pp. 67–
chronous remote control-flow attestation of distributed IoT services,” 77, 2004.
IEEE Access, vol. 9, pp. 144880–144894, 2021. [62] I. D. O. Nunes, S. Jakkamsetti, and G. Tsudik, “Tiny-CFA: Minimal-
[42] M. Chilese, R. Mitev, M. Orenbach, R. Thorburn, A. Atamli, and A.- istic control-flow attestation using verified proofs of execution,” in
R. Sadeghi, “One for all and all for one: GNN-based control-flow at- Design, Automation and Test in Europe Conference and Exhibition,
testation for embedded devices,” arXiv preprint arXiv:2403.07465, pp. 641–646, IEEE, 2020.
2024. [63] Intel Corporation, Intel(R) 64 and IA-32 Architectures Software
[43] J. Wang, Y. Wang, A. Li, Y. Xiao, R. Zhang, W. Lou, Y. T. Hou, Developer’s Manual, 2016. https://software.intel.com/en-us/
and N. Zhang, “ARI: Attestation of real-time mission execution articles/intel-sdm.
integrity,” in 32nd USENIX Security Symposium, 2023. [64] Intel Corporation, “Which Intel® processor models support Intel®
[44] A. Caulfield, N. Rattanavipanon, and I. D. O. Nunes, “ACFA: Secure processor trace (Intel® pt)?.” https://www.intel.com/content/www/
runtime auditing & guaranteed device healing via active control us/en/support/articles/000056730/processors.html, 2021.
flow attestation,” in 32nd USENIX Security Symposium (USENIX [65] Z. Ning and F. Zhang, “Understanding the security of ARM debug-
Security 23), pp. 5827–5844, 2023. ging features,” in IEEE Symposium on Security and Privacy, IEEE,
[45] T. Abera, R. Bahmani, F. Brasser, A. Ibrahim, A.-R. Sadeghi, and 2019.
M. Schunter, “DIAT: Data integrity attestation for resilient collabo- [66] RISC-V Community, “RISC-V Processor trace specification.” https:
ration of autonomous systems,” in Network and Distributed System //github.com/riscv-non-isa/riscv-trace-spec, 2024. Version 2.0.3.
Security Symposium, 2019. [67] RISC-V Community, “RISC-V N-Trace.” https://github.com/
[46] B. Kuang, A. Fu, L. Zhou, W. Susilo, and Y. Zhang, “DO-RA: data- riscv-non-isa/tg-nexus-trace/blob/master/docs/RISC-V-N-Trace.
oriented runtime attestation for IoT devices,” Computers & Security, adoc, 2024. Draft 0.6.
vol. 97, 2020. [68] D. Papamartzivanos, S. A. Menesidou, P. Gouvas, and T. Giannetsos,
[47] M. Geden and K. Rasmussen, “Hardware-assisted remote runtime “Towards efficient control-flow attestation with software-assisted
attestation for critical embedded systems,” in 17th Int’l Conference multi-level execution tracing,” in IEEE Int’l Mediterranean Confer-
on Privacy, Security and Trust, IEEE, 2019. ence on Communications and Networking, 2021.
[48] D. Huo, Y. Wang, C. Liu, M. Li, Y. Wang, and Z. Xu, “LAPE: [69] Various, “BPF Compiler Collection (BCC),” 2024. https://github.
A lightweight attestation of program execution scheme for bare- com/iovisor/bcc.
metal systems,” in IEEE 22nd Int’l Conference on High Performance [70] C. Shepherd, B. Semal, and K. Markantonakis, “Investigating black-
Computing and Communications, IEEE, 2020. box function recognition using hardware performance counters,”
[49] Y. Li, Q. Zhou, B. Li, and Y. Zhuang, “CFRV: A decentralized IEEE Transactions on Computers, 2022.
control-flow attestation schema using mutual secret sharing,” Sen- [71] Y. Xia, Y. Liu, H. Chen, and B. Zang, “CFIMon: Detecting violation
sors, vol. 22, no. 16, p. 6044, 2022. of control flow integrity using performance counters,” in IEEE/IFIP
Int’l Conference on Dependable Systems and Networks, IEEE, 2012.

[72] C. Maurice, N. Le Scouarnec, C. Neumann, O. Heen, and A. Francil- [94] C. H. Kim, T. Kim, H. Choi, Z. Gu, B. Lee, X. Zhang, and D. Xu,
lon, “Reverse engineering Intel last-level cache complex addressing “Securing real-time microcontroller systems through customized
using performance counters,” in 18th Int’l Symposium on Research memory view switching.,” in Network and Distributed System Se-
in Attacks, Intrusions, and Defenses, Springer, 2015. curity Symposium, 2018.
[73] B. Zhou, A. Gupta, R. Jahanshahi, M. Egele, and A. Joshi, “Hard- [95] E. Göktas, E. Athanasopoulos, H. Bos, and G. Portokalidis, “Out of
ware performance counters can detect malware: Myth or fact?,” in control: Overcoming control-flow integrity,” in IEEE Symposium on
ACM Asia Conference on Computer and Communications Security, Security and Privacy, pp. 575–589, IEEE, 2014.
2018. [96] L. Cheng, S. Ahmed, H. Liljestrand, T. Nyman, H. Cai, T. Jaeger,
[74] I. D. O. Nunes, K. Eldefrawy, N. Rattanavipanon, and G. Tsudik, N. Asokan, and D. Yao, “Exploitation techniques for data-oriented
“APEX: A verified architecture for proofs of execution on remote attacks with existing and potential defense approaches,” ACM Trans-
devices under full software compromise,” in 29th USENIX Security actions on Privacy and Security, vol. 24, no. 4, pp. 1–36, 2021.
Symposium, pp. 771–788, 2020. [97] Embench™: A Modern Embedded Benchmark Suite. https://www.
[75] C. Lattner and V. Adve, “Llvm: A compilation framework for life- embench.org/.
long program analysis and transformation,” in International Sympo- [98] J. Wilander, N. Nikiforakis, Y. Younan, M. Kamkar, and W. Joosen,
sium on Code Generation and Optimization, pp. 75–86, IEEE, 2004. “Ripe: Runtime intrusion prevention evaluator,” in 27th Annual
[76] G. Gange, J. A. Navas, P. Schachte, H. Søndergaard, and P. J. Computer Security Applications Conference, 2011.
Stuckey, “An abstract domain of uninterpreted functions,” in 17th [99] E. Brickell, J. Camenisch, and L. Chen, “Direct anonymous attesta-
Int’l Conference on Verification, Model Checking, and Abstract tion,” in 11th ACM Conference on Computer and Communications
Interpretation, Springer, 2016. Security, 2004.
[77] J. Zhao, S. Nagarakatte, M. M. Martin, and S. Zdancewic, “Formal- [100] C. Shepherd, R. N. Akram, and K. Markantonakis, “Remote cre-
izing the LLVM intermediate representation for verified program dential management with mutual attestation for trusted execution
transformations,” in 39th Annual ACM Symposium on Principles of environments,” in Information Security Theory and Practice: 12th
Programming Languages, 2012. IFIP WG 11.2 International Conference, Springer, 2019.
[78] T. Ball and J. R. Larus, “Efficient path profiling,” in 29th Annual
IEEE/ACM Int’l Symposium on Microarchitecture, IEEE, 1996.
[79] A. A. Clements, N. S. Almakhdhub, S. Bagchi, and M. Payer,
“ACES: Automatic compartments for embedded systems,” in 27th
USENIX Security Symposium, pp. 65–82, 2018.
[80] A. Q. Nguyen et al., “Capstone: The Ultimate Disassembler,” 2024.
https://www.capstone-engine.org.
[81] University of Wisconsin-Madison, “Dyninst,” 2024. http://www.
dyninst.org/.
[82] C.-K. Luk, R. Cohn, R. Muth, H. Patil, A. Klauser, G. Lowney,
S. Wallace, V. J. Reddi, and K. Hazelwood, “Pin: building cus-
tomized program analysis tools with dynamic instrumentation,”
ACM SIGPLAN Notices, vol. 40, no. 6, pp. 190–200, 2005.
[83] D. Bruening and S. Amarasinghe, Efficient, transparent, and com-
prehensive runtime code manipulation. PhD thesis, Massachusetts
Institute of Technology, 2004.
[84] A. Engelke and M. Schulz, “Instrew: Leveraging LLVM for high
performance dynamic binary instrumentation,” in 16th ACM Int’l
Conference on Virtual Execution Environments, 2020.
[85] J.-P. Aumasson, S. Neves, Z. Wilcox-O’Hearn, and C. Winnerlein,
“BLAKE2: Simpler, smaller, fast as MD5,” in 11th Int’l Conference
on Applied Cryptography and Network Security, Springer, 2013.
[86] J.-P. Aumasson, S. Neves, Z. Wilcox-O’Hearn, and C. Winner-
lein, “BLAKE2: simpler, smaller, fast as MD5,” in 11th Interna-
tional Conference on Applied Cryptography and Network Security:,
pp. 119–135, Springer, 2013.
[87] D. Clarke, S. Devadas, M. Van Dijk, B. Gassend, and G. E. Suh, “In-
cremental multiset hash functions and their application to memory
integrity checking,” in 9th International Conference on the Theory
and Application of Cryptology and Information Security, pp. 188–
207, Springer, 2003.
[88] J. R. Larus, “Whole program paths,” ACM SIGPLAN Notices,
vol. 34, no. 5, pp. 259–269, 1999.
[89] T. N. Kipf and M. Welling, “Variational graph auto-encoders,” arXiv
preprint arXiv:1611.07308, 2016.
[90] F. Hausdorff, Grundzüge der mengenlehre, vol. 7. von Veit, 1914.
[91] Y. Collet et al., “RFC 8878: Zstandard compression and the ‘appli-
cation/zstd’ media type,” 2021.
[92] J. R. Larus, “Abstract execution: A technique for efficiently tracing
programs,” Software: Practice and Experience, 1990.
[93] A. A. Clements, N. S. Almakhdhub, K. S. Saab, P. Srivastava,
J. Koo, S. Bagchi, and M. Payer, “Protecting bare-metal embedded
systems with privilege overlays,” in IEEE Symposium on Security
and Privacy, pp. 289–303, IEEE, 2017.

Control-Flow Attestation: Concepts, Solutions, and Open Challenges

Uploaded by

Copyright:

Available Formats

Control-Flow Attestation: Concepts, Solutions, and Open Challenges

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Control-Flow Attestation: Concepts, Solutions, and Open Challenges

Uploaded by

Copyright:

Available Formats

Control-Flow Attestation: Concepts, Solutions, and Open Challenges

Zhanyu Shaa,∗ , Carlton Shepherdb , Amir Rafia and Konstantinos Markantonakisa

ARTICLE INFO ABSTRACT

1. Introduction from ,  creates a measurement that is an aggregation

Z. Sha et al.: Preprint submitted to Elsevier Page 1 of 26

In 2016, Steiner & Lupu [15] presented one of the first

Z. Sha et al.: Preprint submitted to Elsevier Page 2 of 26

Z. Sha et al.: Preprint submitted to Elsevier Page 3 of 26

;; Conditional direct jump (jump if equal)

Z. Sha et al.: Preprint submitted to Elsevier Page 4 of 26

Z. Sha et al.: Preprint submitted to Elsevier Page 5 of 26

Prover-Verifier Instrumentation Measurement Adversarial

Conventional Collective Software Hardware Binary Hash- Non-control Code Code

Figure 3: Knowledge areas of state-of-the-art control-flow attestation schemes.

Module (TPM). However, other approaches have also been 3 Challenge c

Z. Sha et al.: Preprint submitted to Elsevier Page 6 of 26

Figure 6: An overview of GuaranTEE [10]. In 1 , users interact

may be targeted by control-flow attackers; a signing service

Z. Sha et al.: Preprint submitted to Elsevier Page 7 of 26

Figure 8: System overview of DIAT (from [45]). Unlike

act as  and  in a given session. The authors address the

Z. Sha et al.: Preprint submitted to Elsevier Page 8 of 26

Z. Sha et al.: Preprint submitted to Elsevier Page 9 of 26

Trampoline TEE Run-time

Figure 10: SCaRR’s user- and kernel-space components [13].

5.2. Normal World Schemes

Z. Sha et al.: Preprint submitted to Elsevier Page 10 of 26

4 loops_status & branch_status ctrl

information while the target program is being executed, i.e.

Z. Sha et al.: Preprint submitted to Elsevier Page 11 of 26

(PMU) as a trusted measurement component. A PMU is a

Z. Sha et al.: Preprint submitted to Elsevier Page 12 of 26

Figure 15: An overview of the LLVM compiler framework [77].

6.1. Compiler-assisted Instrumentation

Z. Sha et al.: Preprint submitted to Elsevier Page 13 of 26

Z. Sha et al.: Preprint submitted to Elsevier Page 14 of 26

Z. Sha et al.: Preprint submitted to Elsevier Page 15 of 26

Z. Sha et al.: Preprint submitted to Elsevier Page 16 of 26

Z. Sha et al.: Preprint submitted to Elsevier Page 17 of 26

1... Normal World Secure World

5 op_func = get_op_func(cmd->op); indirect

Figure 18: Deployment overview of OAT [6].

verifies the proving application, ’ and  respectively. We

Z. Sha et al.: Preprint submitted to Elsevier Page 18 of 26

Figure 19: Workflow of ARI by Wang et al. [43].

while hash-based measurements assess backward control-

Z. Sha et al.: Preprint submitted to Elsevier Page 19 of 26

8. Evaluation 8.2. Discussion and Analysis

Z. Sha et al.: Preprint submitted to Elsevier Page 20 of 26

Z. Sha et al.: Preprint submitted to Elsevier Page 21 of 26

Z. Sha et al.: Preprint submitted to Elsevier Page 22 of 26

Z. Sha et al.: Preprint submitted to Elsevier Page 23 of 26

Z. Sha et al.: Preprint submitted to Elsevier Page 24 of 26

vol. 5, p. 146, 2005. [50] C. Shepherd, K. Markantonakis, N. Van Heijningen, D. Aboulkas-

Z. Sha et al.: Preprint submitted to Elsevier Page 25 of 26

Z. Sha et al.: Preprint submitted to Elsevier Page 26 of 26

You might also like