# Do Not Trust Power Management: Challenges and Hints for Securing Future
Trusted Execution Environments

Owen Le Gonidec13, Maria Méndez Real1, Guillaume Bouffard2, Jean-Christophe
Prévotet3

0009-0004-4774-6886 0000-0002-9336-9936 0000-0002-2046-369X
0000-0001-6951-4702 1Nantes Université, CNRS, IETR-UMR 6164, F-44000 Nantes
Email: {maria.mendez<EMAIL_ADDRESS>2National Cybersecurity
Agency of France (ANSSI), Paris, France
Email<EMAIL_ADDRESS>3UnivRennes, INSA Rennes, CNRS, IETR-
UMR 6164, F-35000 Rennes
Email<EMAIL_ADDRESS>
###### Abstract

Over the past few years, several research groups have introduced innovative
hardware designs for Trusted Execution Environments, aiming to secure
applications against potentially compromised privileged software, including
the kernel [1, 2, 3]. Since 2017 [4], Tang et al. introduced a new class of
software-enabled hardware attacks, which leverages energy management
mechanisms. These attacks aim at bypassing TEE security guarantees and
exposing sensitive information like cryptographic keys. They have increased in
prevalence over the past few years [5, 6, 7]. Despite that, current RISC-V TEE
architectures have yet to incorporate them into their threat models.
Proprietary implementations, such as Arm TrustZone and Intel SGX, embed
countermeasures. However, these countermeasures are not viable in the long
term and hinder the capabilities of energy management mechanisms.

This article presents the first comprehensive knowledge survey of these
attacks, along with an evaluation of literature countermeasures. Our analysis
highlights a substantial security gap between assumed threat models and the
actual ones, presenting considerable threats in modern systems-on-chip that
can undermine even the security guarantees provided by TEEs. We advocate for
the enhancement of the next generation of RISC-V TEEs to address these attacks
within their threat models, and we believe this study will spur further
community efforts in this direction.

###### Index Terms:

Hardware Security, Power Management, Fault Injection Attacks, Side-Channel
Attack, Countermeasure

##  I Introduction

To protect sensitive assets, modern mobile computing systems rely on TEEs.
TEEs offer a secure runtime execution environment where sensitive applications
are executed, co-located with a Rich Environment (RE), which may include
Operating System (OS) such as Android or iOS. TEEs isolate the execution of
sensitive applications from the rest of the system, _i.e._ , from the rich,
and potentially untrusted RE, relying on hardware mechanisms. Such
environments are widely used to secure critical applications, both in System
on Chips and high-end servers. TEEs aims to protect the system against
software attacks where the attacker may have full control over the RE,
including the rich OS. Attacks requiring physical access to the system are not
part of the TEEs’ threat model [8, 9, 10].

However, since the mid-2010s, dozens of articles have demonstrated several
methods by which a remote attacker can compromise the main security properties
of a TEE, utilizing hardware attacks initiated from software, without
requiring physical access to the target [11]. This emerging type of attack
relies on manipulating software-accessible interfaces to affect hardware
components, rendering them a realistic and dangerous threat. Among these,
energy-based attacks are particularly significant. They exploit embedded
energy management mechanisms maliciously to compromise the security of the
victim system. For instance, they may be employed to extract sensitive assets
such as cryptographic keys or to bypass authentication procedures. They enable
the injection of timing faults in a fault attack [4, 6], extraction of secret
information through a Side-Channel Attack (SCA) [12, 5, 13], and creation of a
covert communication channel utilized by a Trojan and a spy [14, 7]. Such
attacks have been conducted against widely deployed TEEs, such as ARM
TrustZone [14, 5, 4] and Intel Software Guard Extension (SGX) [6, 15, 13].
Despite falling into the category of software-induced attacks, these are still
not accounted for in TEE threat models.

Among commercial TEE implementations, Intel SGX is the only one that has
implemented a mitigation for energy-based fault attacks. However, it consists
of restricting the use of power management mechanisms, thereby greatly
limiting the primary objective of energy fine-grain optimization [6]. Arm [16]
recommends that vendors of TrustZone-enabled TEEs (_e.g._ , Qualcomm or
Samsung) implement a similar mitigation-although to our knowledge, no official
vendor document mentions an actual implementation. Again, this mitigation is
not sustainable eventually, as it results in power waste and does not address
the root cause of energy-based attacks. This initial mitigation proposed is
specific to fault attacks and does not address other types of energy-based
attacks, notably SCAs [5] and covert attacks, which will be reviewed in this
article. Consequently, we assert that existing TEEs are vulnerable to this
major threat.

Regarding RISC-V-based systems, these energy-based attacks have still not been
considered in recent TEE threat models. Even though several works have
introduced innovative hardware TEE implementations leveraging the capabilities
of the open ISA RISC-V, they do not offer any protection against energy-based
attacks [17, 2, 18, 3].

In this article, we provide the first overview of this new category of
hardware energy-based attacks and analyse their capabilities, limitations, and
evolution over the past few years. To the best of our knowledge, this is the
first work reviewing this emergent category of attacks. Additionally, we give
an overview of the initial attempts at countermeasures and demonstrate that
there is still much to be done in this field. Finally, through an analysis of
countermeasure implementation as part of TEEs, we demonstrate that mitigating
this new category of attacks constitutes a promising research field for the
future.

The remainder of this article is organized as follows: Section II provides
background information on physical attacks, power management mechanisms, and
TEE. Subsequently, Section III delves into internal energy-based attacks,
detailing their types, methods, results, and limitations. In Section IV, we
scrutinize the first published and implemented countermeasures against this
type of attack as well as their limitations. We provide an overview of the
challenges involved in implementing them in practice. Then, we propose
potential approaches for addressing these vulnerabilities. Finally, Section V
concludes this article and offers insights into future research directions.

##  II Background

###  II-A Hardware Attacks

Hardware attacks exploit the electronic behaviour of components executing
sensitive or critical applications. In the case of SCA, rather than breaking
complex mathematical algorithms such as cryptographic schemes protecting
secret data, an attacker analyses side-channel signals generated during the
execution of the victim application. Examples include the target device’s
electromagnetic emanation, power consumption, or computation time. These
signals reveal the target architecture and microarchitecture state, allowing
an attacker to deduce the instructions and/or data computed, thereby
compromising target confidentiality. Similarly, in Differential Fault Analysis
(DFA), an attacker can introduce faults into computation or memory by inducing
glitches within the electronic device through external sources, potentially
resulting in controlled instruction skipping, such as during an authentication
process. In both cases, SCA or DFA, the objective is typically to retrieve
secret information.

Traditionally, hardware attacks have required physical access to the hardware
device, such as through external sensors or sources of glitches. Consequently,
hardware attacks were not always considered in most device threat models.
However, a new type of software-induced hardware attack has emerged, allowing
an attacker application to perform hardware attacks from within the device. By
exploiting microarchitectural components shared by the victim and attacker
applications, such as memory caches, communication interconnections, or more
recently, power management components, this powerful new type of attack
greatly extends the threat surface.

###  II-B Power Management Mechanisms

Optimal power management has been a crucial part of digital systems design,
both in constrained SoCs and high-end servers, enabling energy savings and
improved thermal management. Among power management technologies, fine-grained
control mechanisms such as Dynamic Voltage and Frequency Scaling (DVFS) have
been employed for decades. DVFS involves adjusting the supply voltage and
operating frequency, which collectively have a cubic impact on power
consumption, depending on the system load, to meet performance targets. In
this article, we refer to a combination of operating frequency and supply
voltage as an Operating Point (OPP) (referred to as _P-States_ in Intel
terminology). In a typical DVFS implementation, either the OS or the hardware
central processing unit (CPU) requests a frequency adjustment based on a
workload estimation. The operating voltage is subsequently adjusted based on a
set of vendor-defined OPPs. These sets are defined by manufacturers to ensure
device safety and can extend beyond the actual operating limits of the device
[19]. Indeed, these limits vary due to factors such as ageing, temperature,
and manufacturing uncertainties [4], making it impractical for operators to
measure the limits of each device. In addition to OPPs scaling mechanisms, the
ability to query power consumption, temperature, and operating frequency is a
crucial aspect of power management. First, energy-aware programs benefit from
software interfaces that allow them to monitor these metrics. It is also
directly used by hardware components, for example to implement turbo
frequencies and power capping [20].

Figure 1: A typical DVFS implementation, illustrating components used for
sensing operating frequency and supply voltage.

Figure 1 provides an overview of the main components utilized in a typical
DVFS implementation, both for OPP scaling and sensing. It represents one
implementation among many possibilities. Indeed, hardware implementations of
such power management mechanisms can vary significantly from vendor to vendor,
and they are usually undocumented.

Voltage regulation for all components in a SoC is typically managed by a
dedicated component known as the Power Management Integrated Circuit (PMIC).
Typically, a single power rail supplies one core cluster, meaning that each
core within the cluster operates with the same supply voltage. Conversely, in
multicore embedded systems, frequency dividers are internally managed by a
core, enabling each processor to have its own clock domain and operate at its
own frequency. With the trend toward more aggressive power management
mechanisms, per-core voltage domains for supply voltage are becoming more
common, as implemented in some recent Intel processors [21]. At the software
level, in Linux-based systems, the OS kernel requests frequency changes
through modules such as cpufreq, either using an automatic governor or
manually setting an operating frequency, such as through model-specific
registers. The supply voltage is adjusted accordingly based on the vendor-
defined OPPs.

On x86 processors, energy consumption can be measured from software using the
Running Average Power Limit (RAPL) interface. This interface does not rely on
physical power sensors, but instead utilizes a modelling approach based on
architectural events communicated by peripherals [22]. This is also the case
for operating frequency, e.g., the Linux kernel support for Intel processors
where frequency is not given by a physical sensor, but estimated instead by
differentiating the value of incrementing counters — one incrementing with a
reference frequency and the other incrementing in proportion to the actual
performance111See: aperfmperf.c in the Linux-kernel source code. [23]. In
embedded devices, the way that clock frequency and power consumption are
retrieved is dependent on the SoC hardware design, on which little information
is publicly disclosed. Contrary to x86 systems, here energy consumption may be
retrieved from physical sensors, e.g., mobile Android devices where the power
supply module communicates battery status to privileged software.

The switching time of transistors is inversely proportional to their supply
voltage. Therefore, high voltage is required to achieve high operating
frequencies; otherwise, timing conditions at the transistor level are not met,
resulting in device instability and _clock glitches_ [24]. Although supply
voltage is typically adjusted based on operating frequency, it is possible to
independently adjust them by directly writing in dedicated MSRs. This presents
an entry point for internal energy-based fault attacks, which intentionally
trigger clock glitches by configuring a high clock frequency and a low supply
voltage.

###  II-C Trusted Execution Environments

Some privileged components, such as rich operating systems, have extensive
attack surfaces that make them challenging to secure. For example, the Linux
kernel comprised over 27 million lines of code in 2020, with nearly two
thousand vulnerabilities disclosed [25]. Therefore, these privileged
components cannot be relied upon to ensure the security of critical programs.
This realization gave rise to the concept of relying on a minimal set of
security-oriented components to form a Trusted Computing Base (TCB). The aim
is to keep the TCB as small as possible, providing hardware-assisted
mechanisms to isolate critical programs from the main computing environment.
Since the late 1990s, separate co-processors known as Trusted Platform Modules
(TPMs) have been utilized for this purpose [26]. However, Trusted Platform
Modules can only protect a predefined set of functionalities. The necessity to
extend this protection to third-party programs on rich, performance-oriented
processors led to the development and standardization of TEEs in the early
2010s [27].

A TEE is a secure environment comprising memory, storage, and processing
capabilities, isolated from the rest of the system, often referred to as the
RE [28]. While a TPM relies on executing security-critical programs on an
external, isolated component, in a TEE, both trusted, and untrusted programs
run on the same CPU/microcontroller and share the same hardware resources,
with access mediated by a dedicated component known as the Security Monitor
(SM). The TEE utilizes on-chip hardware mechanisms to isolate and provide
integrity and confidentiality to security-critical programs in systems where
privileged software, such as kernels and hypervisors in the RE, is untrusted.
This includes servers used by stakeholders for data storage and computation
outsourcing (cloud computing), where trust in the cloud provider may be
lacking. This scenario is a common use case for Intel and AMD TEEs,
specifically SGX and SEV. In the embedded market, ARM TrustZone provides
hardware support for TEEs to SoC designers. More recently, numerous research
papers have leveraged the open RISC-V Instruction Set Architecture (ISA) to
propose new hardware designs for TEE support, such as Sanctum [1] or Keystone
[2], among others.

TEE implementations vary based on the hardware and software mechanisms they
employ to secure trusted applications. A notable distinction between TrustZone
and SGX-type TEEs, which encompasses most academic proposals [1, 18, 3], is
that in the former, the entire system is divided into two _worlds_. Secure OSs
and potentially hypervisors can operate in the trusted world. This approach
offers significant flexibility: TEE implementations can prioritize providing
extensive functionalities to trusted applications or aim for the smallest
possible Trusted Computing Base (TCB), as demonstrated in some studies [8].
However, in the latter approach, untrusted user-level applications, referred
to as enclaves, can be individually isolated without needing to trust the
kernel and other privileged software. In this protection model, there is a
risk of potential malicious enclaves being spawned.

Another essential feature of a TEE is attestation, which ensures that it
operates on a physically certified device. This serves various purposes, such
as allowing a trusted application to verify that the host system is running an
up-to-date version. Additionally, TEEs rely on security primitives like Secure
Boot, typically ensured by firmware, which forms part of the TCB of the
system. Most academic TEE designs utilize a Secure Monitor (SM) that leverages
RISC-V’s _Machine Mode_ privilege level for this purpose.

##  III Internal energy-based attacks

As detailed in Section II-A, physical access to the victim device enables
potent power and clock-based attack scenarios, which have been studied and
utilized for over two decades. However, lately, several studies have shown
that similar attacks can be executed internally using software-accessible
energy management mechanisms. This discovery is relatively recent, with such
attacks first demonstrated in 2015 for SCAs [29] and in 2017 for fault attacks
[4]. Consequently, they pose an emerging threat that may become increasingly
dangerous with further discoveries and when combined with other attack
vectors.

Most energy-based attacks, including fault attacks and certain SCAs, require
access to kernel-restricted registers. Therefore, the attacker must possess
kernel-level privileges within the RE. In such scenarios, the attacker targets
assets protected against direct access from the rich OS, namely assets within
the TEE. While TEEs offer hardware-enforced isolation for trusted assets,
energy management mechanisms, such as voltage and frequency regulators, as
well as sensors, are shared across power domains, even spanning TEEs and REs.
An attacker with full control over the RE can exploit these energy management
mechanisms as a side channel to access TEE assets. The methods by which these
mechanisms can facilitate fault attacks, SCAs, and covert communication will
be described in the following paragraphs.

##### Attacker model

Internal energy-based attacks employ methods similar to physical attacks
described in Section II-A: they monitor programs using external power sensors
and/or manipulate their execution using external sources of glitches. However,
they differ significantly in a crucial aspect: internal attacks utilize
software-accessible energy management mechanisms, eliminating the need for the
attacker to physically access the device. While traditional physical attacks
involve the attacker utilizing off-chip equipment to extract information or
manipulate the execution flow, internal attacks are entirely internal and
software-driven, thus expanding the threat model to include remote attackers.
This significantly increases the attack surface. Moreover, these internal
attacks are more cost-effective and carry no risk of damaging the targeted
platform, while also posing a serious potential for widespread exploitation
[30].

In the following paragraphs, we consider an attacker who has full control over
the RE, including the untrusted OS and its drivers. Their objective is to
compromise key security properties of the TEE and trusted
applications/enclaves, including confidentiality (e.g., stealing cryptographic
keys), integrity (e.g., altering processed data), availability (e.g.,
conducting Denial-of-Service attacks), or authenticity (e.g., loading a self-
signed application into the TEE). The attacker is remote; they do not have
physical access or proximity to the victim’s device but can execute software
on the device. Additionally, they may utilize physical equipment on a copy of
the device for profiling purposes before conducting the actual attack. For
example, they can employ physical sensors to establish a correlation between
power consumption and data on their own device during the profiling phase.
Subsequently, during the actual attack, they can exploit the developed model
on the victim device through a remote attack utilizing software-accessible
power sensors embedded on the chip. This scenario is typical in profiling
attacks.

Finally, we assume that the attack program is running on the CPU and does not
aim to compromise the security of another component of the SoC. This notably
implies that FPGA-to-CPU undervolting fault attacks [31] are outside this
review’s scope.

##### Fault injection attacks

TABLE I: Overview of fault attacks exploiting software-accessible energy management mechanisms. Attack |  Target platform (Target TEE) |  Glitch injection method |  Compromised security properties (assets)
---|---|---|---
_CLKSCREW_ [4] |  Qualcomm Krait (ARM TrustZone) |  Overclocking |  Confidentiality (extract AES keys from the TEE), Integrity (fault an RSA key during verification), Authenticity (load a self-signed application into TrustZone)
_VoltJockey_ [32, 33] |  (i) Qualcomm Krait (ARM TrustZone) (ii) Skylake CPUs (Intel SGX) |  Undervolting |  Confidentiality (extract AES keys from the TrustZone & SGX), Authenticity (load a self-signed application into TrustZone)
_Plundervolt_ [6] |  Skylake CPUs (Intel SGX) |  Undervolting |  Confidentiality (Extract AES & RSA keys from the TEE), Integrity (Out-of-Bounds memory access)
_V0ltpwn_ [34] |  Skylake CPUs (Intel SGX) |  Undervolting |  Integrity (fault SHA-256)
Noubir et al. [35] |  Exynos 5422 & Kirin 960 |  Undervolting |  Availability (denial-of-service attack)

Internal energy-based fault attacks involve installing a malicious kernel
module or driver that accesses the hardware voltage and/or frequency
regulators. By independently adjusting the voltage and frequency, the attacker
causes the device to operate beyond its specified limits. As described in
Section II-A, this results in clock glitches, leading to faults in the
processed data or instructions. Typically, an unstable state where faults
occur is reached when the supply voltage is low and the frequency is high. The
attacker can induce a glitch either by (i) transiently increasing the
frequency to an unstable value, referred to as ’overclocking’ attacks [4], or
by (ii) reducing the power domain’s supply voltage while the clock frequency
of the victim core is high, known as _undervolting_ attacks. Additionally, as
discussed in Section II-B, in most DVFSs implementations, each core (or
cluster) has its own frequency domain. Attackers exploit this feature to
target a victim core (or cluster) without affecting their own attack program.

Software-induced clock glitches represent an emerging threat first
demonstrated in [4]. In this study, attackers overclock the device to induce a
transient clock glitch, which they utilize to target Qualcomm Secure Execution
Environment (QSEE), a TrustZone-based TEE. Through this method, the authors
successfully extract secret AES keys via DFA. Moreover, they demonstrate the
loading of a self-signed application into the TEE by disrupting RSA
certificate verification. Subsequent research has shown that transient
undervolting can achieve similar results [32], and that Intel SGX can also be
compromised through energy management mechanisms, by directly manipulating the
corresponding MSR [6, 33, 34]. Table I provides an overview of internal
energy-based fault attacks published recently, highlighting their distinctive
characteristics. The target platforms encompass a range of devices, from
smartphone processors (e.g., Qualcomm Krait) to high-end Intel CPUs. Both ARM
TrustZone and Intel SGX are shown to be vulnerable to Fault Injection Attack
(FIA). These attacks illustrate various use cases, compromising different
security properties of the victim device and targeting diverse assets.

These studies present powerful attack scenarios but also reveal numerous
limitations. First, achieving precise timing for glitch injection isn’t always
feasible, depending on how quickly the victim device can switch between
different OPP. In [4], attackers could induce a glitch within a
$65\,000$-cycle time window, targeting a specific part of the victim program.
However, in Intel architectures targeted in [6, 34], over $500\,000$
instructions are executed between consecutive OPP change requests, making
transient glitch injection impractical. Attackers rely on the fact that
certain instructions, such as multiplications [6] and vector operations [34],
are more likely to cause faults, allowing them to target specific parts of a
program to some extent. When the victim device does not exhibit such
behaviour, supply voltage manipulation can still be used for denial-of-service
attacks [35]. Second, not all devices may grant direct access to voltage and
frequency regulators. With devices lacking an open-source OS or detailed
technical documentation, the corresponding registers remain unknown. The
attacks on Intel SGX [6, 34, 33] were made possible by prior research efforts
that uncovered the MSR used for voltage control [6]. Third, each device
possesses unique properties that can make fault injection via voltage and
frequency control challenging, if not impossible. The unstable area triggering
faults without device rebooting or freezing may be very narrow on some CPUs.
With discrete voltage control precision (e.g., 5 steps), reaching this area
may prove unattainable, as observed in AMD Zen processors [36].

##### Side-Channel Analysis

In addition to fault injection, recent research efforts have highlighted the
emergence of various software-accessible side channels stemming from energy
management mechanisms present in today’s systems-on-chip. These side channels
can be exploited by attackers seeking to retrieve sensitive assets. Several
studies demonstrate different malicious uses of energy management mechanisms
targeting various assets. Two primary attack vectors can be exploited for
SCAs. The first involves directly reading the device’s data-dependent energy
metrics (such as power consumption and clock frequency) using embedded on-chip
sensors. The second involves analysing the data-dependent frequency throttling
induced by DVFS based on the system load.

The first attack vector has been extensively studied across various devices.
In the context of Android smartphones, interfaces providing battery status
have been exploited in SCAs for activities such as website fingerprinting
[37], location tracking [38], and inferring running apps, including sensitive
UI interactions such as user login and password lengths [29]. In [12], Linux’s
cpufreq module, along with machine learning techniques, is utilized as a low-
resolution side-channel for website fingerprinting and input sniffing. On
Intel CPUs, the RAPL energy reporting counters were initially identified as a
vulnerability by Mantel et al. in [15]. More recently, Lipp et al. utilized
them in the _Platypus_ attack [13]. In this latter work, a privileged attacker
leverages RAPL counters to extract sensitive information, such as AES secret
keys, from an SGX-enclaved application.

The second attack vector is explored in [39, 40, 5, 41], where the attacker
analyses the behaviour of frequency throttling automatically induced by DVFS
to maintain a balance between power, frequency, and temperature. These
frequency adjustments are shown to be both instruction and data-dependent
[39]. An attacker can trigger them forcefully by subjecting the processor to
heavy workloads. Moreover, a privileged user can manipulate the power budget
threshold at which throttling occurs, facilitating the exploitation of the
attack. This methodology has been employed to compromise AES encryption within
an SGX enclave [39]. This vulnerability also extends to ARM SoCs, as
demonstrated in [40], potentially making it exploitable against TrustZone as
well. It is noteworthy that program execution time is directly proportional to
clock frequency. Therefore, in attacks where clock frequency serves as the
side-channel, attackers can measure the execution time of a dummy program
instead of directly accessing frequency metrics, as demonstrated in [5]. This
renders frequency throttling attacks difficult to detect and prevent.

Finally, in [42], Kogler et al. show that these software-based power SCAs can
reveal any arbitrary value in a shared memory component, such as caches. They
observe that power consumption subtly varies when an attacker-controlled value
is replaced by a victim program’s value. This power consumption variation
depends on the Hamming distance between the two values. Therefore, by using
two inverted attacker values and differentiating the impact of their eviction
on power consumption, they amplify this subtle leakage signal. With this
method, an attacker can leak single-bit differences in the victim data, at the
maximum rate of 4.82bit/h on the tested CPU (_Intel Core i7-8700K_). This
attack is CPU-agnostic, and can be used with either direct measurement or
frequency throttling to monitor power consumption.

Table II provides an overview of the software SCAs based on energy management
mechanisms outlined in this section. It is evident that despite relying on
low-resolution measurements, some attacks can still infer sensitive
information.

TABLE II: Overview of Side-Channel Attacks exploiting software-accessible energy management mechanisms. The resolution column defines the minimum time between 2 consecutive measurements. Attack |  Target Platform |  Attack Vector |  Resolution |  Compromised assets
---|---|---|---|---
_PowerSpy_ [38] |  Android smartphones |  Unprivileged reading of battery level |  100 |  Geo-localisation.
Yan et al. [29] |  Android smartphones |  Unprivileged reading of battery level |  175 |  Running applications, password lengths guessing.
Qin and Yue [37] |  Android smartphones |  Unprivileged reading of battery level after an offline analysis with a physical probe |  1 |  Website fingerprints.
_DF-SCA_ [12] |  Linux-based systems (x86 and ARM) |  Unprivileged use of the cpufreq module |  10 |  Website fingerprints, keystrokes.
Mantel et al. [15] |  Intel CPUs |  Unprivileged access to the RAPL energy counters |  1 |  RSA keys.
_Platypus_ [13] |  Intel CPUs |  Privileged access to the RAPL energy counters |  50 |  AES keys from an SGX-enclaved program, KASLR addresses.
Liu et al. [39] |  x86 CPUs |  Manipulation and analysis of the frequency throttling mechanism (privileged attacker) |  — |  AES keys from an SGX-enclaved program.
_Hertzbleed_ [5, 41] |  x86 CPUs, ARM SoCs and GPUs |  Analysis of the timing differences induced by the throttling mechanism (privileged or unprivileged attacker) |  — |  Cryptographic keys, break KASLR addresses, pixel sniffing, website history.
_Collide+Power_ [42] |  Any |  Analysis of the power variation during replacement of attacker-controlled data by victim data, using direct measurement or frequency throttling. |  — |  Any value in a co-located memory (e.g. caches).

##### Covert communication

Covert communication is a type of attack similar to SCAs in that it exploits
side channels not intended for communication. However, unlike SCAs where a
victim program inadvertently discloses secret information, covert
communication employs side channels to clandestinely transfer data between a
Trojan and a monitoring program. Thus, covert channel attacks utilizing energy
management mechanisms closely resemble the SCAs discussed in the previous
section. Several studies have demonstrated that frequency and power management
mechanisms can serve as covert communication channels between a Trojan and a
monitoring program, simply by modulating frequency, voltage, or both [43, 44,
7, 14] to encode information.

In these attacks, a program manipulates the device or CPU core voltage and
frequency via DVFS, subjecting it to specific workloads, similar to a side-
channel attack using frequency throttling. This method can establish covert
channels between programs executing within the TEE and those on the RE, such
as from a secure CPU core to a non-secure one, or to components outside the
SoC like an FPGA [14], provided voltage or frequency regulators are
accessible. Even when each core has its frequency/power controller, covert
channels can arise from a shared global power controller, as demonstrated in
[45].

The throughput of these covert channels varies significantly, ranging from a
few bits per second [44] to several megabytes per second [14], primarily
depending on the processor and the responsiveness of its frequency changes.
Once information is encoded into a covert channel by the Trojan, the
monitoring program can detect it directly using software-accessible embedded
sensors. However, similar to SCAs, the monitoring program may not necessarily
require direct access to frequency registers; monitoring program execution
time is an equivalent approach [46, 45].

Although existing research typically adopts a device-agnostic approach,
tailoring the attack method to the specific power management mechanisms of the
targeted device can yield better results. For example, in [47], Kalmbach _et
al._ develop a covert channel designed specifically for Intel’s _Turbo Boost
2_ power management technology, which exhibits greater resilience to
background noise compared to previous approaches.

##  IV Discussion and Countermeasures

TABLE III: Overview of existing countermeasures against energy-based attacks. Countermeasure |  Countered attack type |  Implementation status |  Main advantages |  Main shortcomings
---|---|---|---|---
Restrict the RE’s access to hardware regulators |  Fault attacks |  Implemented in Intel SGX [6], recommended by ARM [16] |  Simple implementation, implies no overhead |  Hinders the capabilities of DVFS, does not address the root cause of the vulnerability
Enforce operating limits with a hardware coprocessor |  Fault attacks |  Proof-of-Concept (PoC) presented in [19] |  Does not restrict the use of DVFS, hardware-level implementation |  Area, latency and power consumption overhead (resp. 0.09□, 1.11, 10.5)
Separate hardware regulators across security boundaries |  Fault attacks |  Hypothetical countermeasure formulated in [4, 32, 6] |  Does not restrict the use of DVFS, hardware-level implementation |  Costly and challenging implementation, area overhead, increase in the TCB’s size
Harden trusted programs against faults |  Fault attacks |  PoC presented in [48], other solutions studied in [41, 49] |  Does not restrict the use of DVFS, no hardware modification required |  Significant (dozens %) performance overhead for trusted apps
Scramble software-accessible power traces |  SCAs (direct reading) |  Implemented for Intel SGX [50] |  Simple implementation, does not affect other hardware components which need energy reporting |  Reduces the accuracy of energy reports ($\sim$5-10%)
Prevent the attacker from manually setting an energy budget |  SCAs (frequency throttling) |  Hypothetical countermeasure formulated in [39] |  Makes frequency throttling attacks less practical |  Restricts the use of power clamping, doesn’t fully prevent frequency throttling attacks

As observed in Section III, internal energy-based attacks, encompassing fault
attacks, SCAs, and covert communication, are not only potent but also cost-
effective, posing a substantial threat to all commercial TEE designs.

Despite the multiple demonstrations of these emerging attacks lately, academic
RISC-V-based TEE technologies have yet to incorporate protection against them.
This is either because such vulnerabilities are perceived as hardware flaws
[18, 1] or because their mitigation is believed to be unrelated to TEE
protection mechanisms [2, 3]. However, internal energy-based attacks do not
exploit flaws in a single hardware block that can be remedied by strengthening
its design. Instead, they capitalize on a fundamental vulnerability in the TEE
protection model: hardware regulators, accessible by the RE without
protection, inherently serve as a side-channel. This side-channel is
particularly potent, as it yields results comparable to those of energy and
clock-based physical attacks, which are well-recognized and considered
significant threats. However, internal energy-based attacks cannot be
classified in the same category as traditional physical attacks in terms of
the threat model. This is primarily because they do not utilize off-chip
equipment but rather leverage equipment already embedded in the hardware
device, thus circumventing their primary objective of energy optimization.
When no countermeasure is in place, any attacker with kernel-level privileges
in the untrusted world—assumed in most TEEs’ adversary models—can execute this
type of attack against an application running within the trusted world.
Consequently, addressing this vulnerability at its root necessitates designing
TEE software and hardware mechanisms to either eliminate or render this side-
channel unusable for potential attackers.

Thus, we advocate for the inclusion of mitigation measures against internal
energy-based attacks in next-generation TEEs. Such countermeasures do exist.
First, certain widely used TEE implementations (such as Intel SGX and ARM
TrustZone) embed mitigations against the FIA and some SCAs outlined in section
III, although they greatly hinder the use of power management mechanisms.
Second, several studies have proposed proof-of-concepts countermeasures
against energy-based fault attacks [48, 51, 19]. Finally, some well-
established methods traditionally employed to counter hardware attacks are
also applicable to internal energy-based attacks, given the similarity in
their methodologies. All of these avenues offer potential inspiration for
next-generation TEE designs to incorporate their own countermeasures. In this
section, we first provide an overview of existing mitigation measures against
energy-based fault and side-channel attacks, analysing the main advantages and
shortcomings of each strategy. We highlight the challenges associated with
implementing these countermeasures in real-world hardware TEE. Table III
summarizes said countermeasures, and gives their main advantages and
shortcomings. We describe them further in this section.

###  IV-A Fault attacks countermeasures

####  IV-A1 Forbid the rich OS to access hardware regulators

To execute a fault attack as described in Section III, the attacker loads a
malicious kernel module that directly accesses hardware regulators. Therefore,
preventing direct access to these regulators by the rich OS disarms the
attacker and effectively prevents DVFS fault attacks. This countermeasure is
recommended by manufacturers for TEE implementations that have been targeted
in this manner [16, 6]. Regarding ”CLKScrew”-like attacks [4], ARM recommends
prohibiting the kernel from having ”direct and independent control of clock
and voltage” and suggests performing regular checks on the requested OPP using
a trusted entity such as firmware [16]. However, to our knowledge, no
published documents indicate that vendors (e.g., Qualcomm, Samsung, etc.) have
implemented this countermeasure in their TrustZone-enabled TEE. Furthermore,
in response to undervolting attacks on SGX [6], Intel disabled access to the
voltage control MSR when SGX is enabled through a BIOS update. This update is
also included in the TCB attestation that an enclave can request to verify the
effectiveness of the update.

This countermeasure could be applied to proof-of-concept RISC-V-based TEE
technologies by allocating the M-mode SM for direct access to hardware
regulators. If the stability boundaries of the voltage and frequency space are
known — which is not trivial, as we discuss in the following paragraph — then
the SM can serve as a delegate actor for managing OPP change requests
initiated by less privileged software. It would verify that the requested OPP
is safe for the system. Alternatively, the system could employ a governor
based on system load or scheduler, akin to a Linux-based OS, which can be
implemented in two primary ways. Firstly, workload measurements could be
performed using either the SM directly or a trusted enclave with exclusive
access to associated performance counters. Secondly, a kernel module could be
utilized to provide these measurements along with local attestation to ensure
its integrity. The overhead associated with this communication remains to be
determined. Consequently, implementing this countermeasure may not be
straightforward and necessitates well-informed design decisions.

Moreover, we assert that these solutions are not sustainable in the long term
as they run counter to the primary objective of power optimization techniques.
Indeed, this category of solutions limits power management options to vendor-
prescribed OPPs, which may diverge significantly from a device’s actual
operating limits [19]. It also precludes the ability to adjust them
dynamically for precise control over the device’s power consumption.
Consequently, we can infer that this type of solution has two main drawbacks.
Firstly, it impedes the utilization of DVFS to its fullest extent for
enhancing performance, minimizing energy consumption, and optimizing
temperature, which is particularly crucial in resource-constrained embedded
devices, as well as in standard computers and servers where effective power
and temperature management are vital. Secondly, it fails to address the
underlying vulnerability, as there are likely additional undocumented methods
to manipulate voltage and frequency from the kernel [6].

####  IV-A2 Enforce the operating limits

Fault attacks exploiting power management mechanisms rely on glitches
occurring when the processor operates beyond its specified operating limits.
Therefore, enforcing these limits would render such attacks impractical.
However, implementing this in reality may pose challenges. Firstly,
determining the actual operating limits of a device is only feasible after a
post-manufacturing testing phase, making it practically difficult to enforce
hardware-enforced hard limits [4]. Secondly, various factors contribute to the
fact that even two similar devices manufactured on the same wafer may have
different limits, such as variations and uncertainties during the
manufacturing process, temperature fluctuations, and ageing effects. As a
result, either a broad security margin must be applied, which restricts the
optimal utilization of DVFS, or the limits must be dynamically updated.

Several works propose implementations of this countermeasure. These solutions
first subject the device to various OPPs to characterize their stability based
on the supply voltage and frequency. Then, they prevent the device from
operating with an unstable OPP using various approaches. In [51], a kernel
module polls the voltage and frequency registers to prevent using OPPs beyond
a fixed safety threshold. Although this module can be unloaded by an attacker
who controls the rich OS, an attestation can be used to verify its integrity.
However, no evidence is provided to indicate that this solution effectively
prevents undervolting attacks.

In [19], a lightweight machine-learning model is trained based on the
previously mentioned characterization. It predicts whether an OPP is safe to
use or not. Dedicated coprocessors, one per CPU core, independent of both the
CPU and the PMIC, run this model. A decision boundary controls the
restrictiveness of the blacklist core, and it is updated when a fault occurs
during runtime to account for the effects of temperature and aging. The
behaviour of the blacklist core regarding this decision boundary is to be
implemented by TEE and SoC designers. The authors measure the prediction
latency to be 1.11, which is added as overhead to each frequency change
request. One Blacklist Core consumes 10.5 at 250. This static overhead in the
device’s energy performance should be weighed against the benefits of this
countermeasure compared to simply restricting the usable operating points to a
vendor-defined discrete state, as in Intel processors which use the _Speed
Shift_ technology, for instance.

In [52], Juffinger et al. present a hardware-software co-design introducing a
second set of OPP to the device. This supplementary set offers more aggressive
energy savings compared to the base one, featuring lower supply voltages for
the same operating frequencies while maintaining high performance. To prevent
undervolting faults, the system switches to the base conservative OPP set when
executing highly faultable instructions. Additionally, instructions that are
both faultable and frequent are made safer by relaxing their critical path;
for example, multiplications are granted one additional clock cycle. Although
the primary objective of this work is to enhance the device’s energy
efficiency safely, it also presents a promising avenue for mitigating DVFS
fault attacks.

####  IV-A3 Keep separate hardware regulators

Another countermeasure is to split the regulators so that they are not shared
between trusted and untrusted programs. If regulators were common to all
cores, or if the victim and attacker’s applications shared the same regulator,
faults would impact not only the victim application but also the attacker’s
own program [32]. Another option is to use separate regulators, depending on
whether a CPU core is in a secure or non-secure state [4].

Implementing such a solution poses several challenges. First, maintaining
multiple physical regulators per core may incur significant costs. Second, at
the software level, access to the regulators must be restricted based on the
core and execution environment of the current program. This necessitates a
comprehensive power management solution across different software layers in
the trusted world, which could introduce performance overhead and enlarge the
size of the TCB [4]. Reserving one or several CPU cores exclusively for
trusted programs, equipped with dedicated hardware regulators, would simplify
the implementation of this countermeasure, as suggested in [32]. However, this
approach would essentially resemble using a TPM or a coprocessor. As
demonstrated in section II-C, this contradicts the goals of TEEs, which strive
to offer isolation while utilizing the same hardware resources for both
trusted and untrusted programs. To the best of our knowledge, no published
work has implemented this countermeasure.

####  IV-A4 Harden trusted programs and hardware against faults

Countermeasures outlined in the preceding paragraphs effectively prevent
attackers from injecting faults into trusted programs, thereby thwarting all
known DVFS fault attacks. However, in this paragraph, we delve into
alternative approaches aimed at securing trusted programs against these
attacks. These strategies involve modifying trusted programs themselves to
render them resilient to faults. While these countermeasures do not preempt
DVFS attacks, they either detect faults upon occurrence and rectify their
effects or render faults impractical for exploitation by attackers. Although
these countermeasures typically introduce more overhead than the
aforementioned solutions, this overhead is confined to trusted programs, with
no impact on the rest of the system. Another notable distinction from the
above solutions is that these countermeasures assume that developers of
trusted software bear the responsibility for safeguarding their programs from
potential attackers. Consequently, they are only pertinent in cases where TEE
vendors have not furnished lower-level mitigations against fault attacks from
the outset.

Redundancy and error detection codes, such as parity checks, are commonly
utilized to both detect and mitigate the effects of faults. This can be
achieved through software means by duplicating instructions at compilation,
manually implementing redundancy checks in the code software, or even
duplicating the entire encryption or decryption process, although the latter
incurs significant overheads [30]. Another approach is infection, wherein a
completely erroneous cipher is produced in the event of a fault during
encryption, rendering the output cipher unusable for attackers. Tao et al.
explore the potential use of these three countermeasures (parity codes,
redundancy-based methods, ineffective computation) against DVFS fault attacks
targeting AES encryption in [53]. They determine that the most cost-effective
countermeasure, in terms of both performance and code size overheads, is
temporal redundancy (i.e., running the encryption process twice serially),
with overheads of 34.18 and 12.04 in performance and code size, respectively.
However, they do not empirically assess the robustness of this countermeasure
against actual overclocking or undervolting attacks. In [49], Huang et al.
propose to substitute the most faultable instructions with safer ones. Some
instructions can’t be replaced, and for some others the substitutes don’t
provide a satisfying protection against DVFS fault attacks, the fault rate
being reduced by about half or less.

A countermeasure proposed in [48] detects undervolting fault attacks using a
compiler extension. It involves inserting _trap_ instructions into the victim
code. As mentioned in Section III, undervolting Intel processors increases the
likelihood of certain instructions being faulted, such as multiplications and
vector operations. However, this countermeasure introduces significant
overhead in terms of both execution time and code size of the protected
program. For instance, in the tested scenarios, it resulted in a performance
overhead of 148.4 and a code size overhead ranging from 50150 to mitigate 99
of DVFS fault attacks. Additionally, this approach is tailored specifically
for undervolting-based attacks on x86 Intel platforms and may not generalize
well to other architectures.

Redundancy can also be implemented at the hardware level, such as duplicating
the entire instruction stream, but this approach comes with significant cost
and area overhead. Alternatively, hardware-based methods to defend against
fault attacks can be explored, such as control-flow integrity enforcement
[54]. Moreover, leveraging the RISC-V ISA opens up opportunities for hardware
and cross-layer countermeasures that operate at both the compiler and hardware
levels [55, 56, 57]. As of now, there have been no published attempts to
utilize these methods to mitigate software-induced energy-based fault attacks.

###  IV-B Side-Channel Attacks Countermeasures

Unlike fault attacks, SCAs are passive and thus more challenging to detect and
thwart. Because they exploit the same vectors as covert channel attacks, it’s
reasonable to assume that similar countermeasures could mitigate both types of
attacks. Just as with fault attacks, some of these countermeasures aim to
entirely block attackers from carrying out SCAs, while others concentrate on
making the attacks harder to exploit by obscuring results or concealing
sensitive information.

Firstly, let’s describe countermeasures that effectively prevent attackers
from exploiting the side channels outlined in Section III. To thwart attacks
like _Platypus_ [13], which derive information from direct readings of
instantaneous power consumption or frequency, several solutions can make the
side channel challenging for attackers to exploit. Intel’s approach against
_Platypus_ involves scrambling software-accessible power traces when SGX is
enabled [50]. Power traces sent directly to hardware components remain
unaffected. The scrambling is achieved by randomizing the values sent to the
software-accessible voltage MSRs. This practically makes this internal power
side-channel unusable for the attacker, but it also induces a variation in the
energy reporting of about 5-10%, which can potentially harm some energy-aware
programs which need precise data on the energy consumption. However, this
imprecision is to be put in perspective with the inherent approximation of the
estimation-based RAPL energy reporting [58]. Another tactic is to reduce the
granularity of software-accessible counters and embedded sensors to hinder
energy-based SCAs. However, even with a low-resolution channel (e.g., one
measurement every 10 [12]), attackers may still infer sensitive information.

For the other category of energy-management-related SCAs, which employs
frequency throttling as the side channel [5, 39, 40, 41], attackers can
facilitate the attack by altering the power or temperature threshold at which
throttling occurs [39]. This can be effectively mitigated using TEEs by
restricting access to corresponding configuration registers or files to
trusted programs. Such restriction compels attackers to increase the system
workload to induce throttling, which is less practical. However, this comes in
contradiction with one of the main reasons for which this throttling mechanism
exists in the first place: power clamping, i.e., allowing the user to define
an energy budget over a given period of time [59].

Secondly, traditional algorithm-level countermeasures against power analysis
(both physical and remote) can be employed to increase the difficulty of
exploiting these attacks. These solutions encompass masking, threshold
implementations, and key refreshing, which may be implemented in trusted
programs to shield them against both types of attacks [60, 39].

###  IV-C Summary on existing countermeasures against internal energy-based
attacks

As demonstrated in the preceding paragraphs, the focus on internal energy-
based attacks has predominantly centred on securing processors against fault
attacks. However, the solutions adopted by manufacturers — namely, restricting
direct kernel control over OPP and relying on governor-based DVFS management —
limit the optimal utilization of DVFS, resulting in energy inefficiency.
Furthermore, the emergence of throttling-based attacks [5] underscores that
governor-based DVFS also presents an exploitable side-channel for attackers.
This approach fails to address the underlying cause of these attacks: the
shared and accessible nature of energy management mechanisms by both the TEE
and the RE, inherently constituting a side-channel. Nevertheless, the
implementation of separate regulators for the two domains may prove costly and
challenging to justify. Recent works proposing specific countermeasures
against energy-based fault injection attacks [48, 19, 51] offer promising
avenues for securing TEEs, albeit highlighting the substantial challenges in
terms of overhead and implementation complexity. Additionally, we posit that
leveraging features of modern TEE designs, such as the exclusive assignment of
hardware peripherals [18] or attestation, could enhance countermeasure
effectiveness. Besides, this allows the TEE to stay the sole trusted actor in
the system, thereby centralizing the TCB.

Meanwhile, while specific countermeasures against fault attacks proposed to
date [48, 19] show promise, they await implementation in actual hardware TEE
technologies. Lastly, to our knowledge, no published work has proposed
countermeasures against energy-based software SCAs beyond hardening the
algorithms under attack or restricting access to their interfaces, akin to
fault attacks. However, the efficacy of the latter countermeasure may vary for
frequency-based SCAs, as attackers can simply measure program execution time
instead of directly accessing frequency registers [5].

##  V Conclusion

In this article, we conducted a thorough literature review of a novel category
of software-induced hardware attacks, focusing on the malicious exploitation
of power management mechanisms. We also examined existing countermeasures
aimed at mitigating these attacks and explored potential strategies for
integrating them into TEEs. Our analysis underscores the considerable
challenges inherent in safeguarding TEE implementations against energy-based
attacks, highlighting this as a promising avenue for future research. Our key
conclusions can be summarized as follows.

Firstly, internal energy-based attacks, including fault attacks, SCAs, and
covert communications, pose a significant threat to TEE implementations. This
evolving threat landscape demands attention as attackers continue to develop
more sophisticated and potent attack vectors, such as frequency throttling.
Despite the increasing prominence of these attacks, previous academic work on
hardware TEE designs has largely overlooked them. Therefore, it is imperative
that next-generation TEE technologies integrate robust countermeasures to
address this evolving threat landscape.

Emerging countermeasures against internal energy-based fault attacks, as
evidenced in recent literature [48, 19], offer promising avenues to secure
TEEs against these threats without overly constraining their power management
mechanisms. Nonetheless, the practical implementation and testing of these
countermeasures, especially in next-generation RISC-V based TEE designs,
require further evaluation. Additionally, the exploration of mitigation
strategies for energy-management-based SCAs remains an open area for future
research.

## Acknowledgments

This research is supported by the French Research Agency (ANR) under the
CoPhyTEE JCJC project contract ANR-23-CE39-0003-01.

## References

  * [1] V. Costan, I. Lebedev, and S. Devadas, “Sanctum: Minimal hardware extensions for strong software isolation,” in _25th USENIX Security Symposium (USENIX Security 16)_. Austin, TX: USENIX Association, Aug. 2016, pp. 857–874.
  * [2] D. Lee, D. Kohlbrenner, S. Shinde, K. Asanović, and D. Song, “Keystone: an open framework for architecting trusted execution environments,” in _Proceedings of the Fifteenth European Conference on Computer Systems_ , ser. EuroSys ’20. New York, NY, USA: Association for Computing Machinery, 2020.
  * [3] D. Schrammel, M. Waser, L. Lamster, M. Unterguggenberger, and S. Mangard, “Spear-v: Secure and practical enclave architecture for risc-v,” in _Proceedings of the 2023 ACM Asia Conference on Computer and Communications Security_ , ser. ASIA CCS ’23. New York, NY, USA: Association for Computing Machinery, 2023, p. 457–468.
  * [4] A. Tang, S. Sethumadhavan, and S. Stolfo, “CLKSCREW: Exposing the perils of Security-Oblivious energy management,” in _26th USENIX Security Symposium (USENIX Security 17)_. Vancouver, BC: USENIX Association, Aug. 2017, pp. 1057–1074.
  * [5] Y. Wang, R. Paccagnella, E. T. He, H. Shacham, C. W. Fletcher, and D. Kohlbrenner, “Hertzbleed: Turning power Side-Channel attacks into remote timing attacks on x86,” in _31st USENIX Security Symposium (USENIX Security 22)_. Boston, MA: USENIX Association, Aug. 2022, pp. 679–697.
  * [6] K. Murdock, D. Oswald, F. D. Garcia, J. Van Bulck, D. Gruss, and F. Piessens, “Plundervolt: Software-based fault injection attacks against intel sgx,” in _Proceedings of the 41st IEEE Symposium on Security and Privacy (S &P’20)_, 2020.
  * [7] J. Haj-Yahya, L. Orosa, J. S. Kim, J. G. Luna, A. Yaglikci, M. Alser, I. Puddu, and O. Mutlu, “Ichannels: Exploiting current management mechanisms to create covert channels in modern processors,” in _2021 ACM/IEEE 48th Annual International Symposium on Computer Architecture (ISCA)_. Los Alamitos, CA, USA: IEEE Computer Society, jun 2021, pp. 985–998.
  * [8] S. Pinto and N. Santos, “Demystifying arm trustzone: A comprehensive survey,” _ACM Comput. Surv._ , vol. 51, no. 6, jan 2019.
  * [9] S. Fei, Z. Yan, W. Ding, and H. Xie, “Security vulnerabilities of sgx and countermeasures: A survey,” _ACM Comput. Surv._ , vol. 54, no. 6, jul 2021\.
  * [10] G. Dessouky, A.-R. Sadeghi, and E. Stapf, “Enclave computing on risc-v: A brighter future for security?” in _1st International Workshop on Secure RISC-V Architecture Design Exploration (SECRISC-V)_ , April 2020.
  * [11] D. Gruss, C. Maurice, and S. Mangard, “Rowhammer.js: A Remote Software-Induced Fault Attack in JavaScript,” in _Detection of Intrusions and Malware, and Vulnerability Assessment_ , J. Caballero, U. Zurutuza, and R. J. Rodríguez, Eds. Cham: Springer International Publishing, 2016, pp. 300–321.
  * [12] D. R. Dipta and B. Gulmezoglu, “Df-sca: Dynamic frequency side channel attacks are practical,” in _Proceedings of the 38th Annual Computer Security Applications Conference_ , ser. ACSAC ’22. New York, NY, USA: Association for Computing Machinery, 2022, p. 841–853.
  * [13] M. Lipp, A. Kogler, D. Oswald, M. Schwarz, C. Easdon, C. Canella, and D. Gruss, “Platypus: Software-based power side-channel attacks on x86,” in _2021 IEEE Symposium on Security and Privacy (SP)_ , 2021, pp. 355–371.
  * [14] E. M. Benhani and L. Bossuet, “Dvfs as a security failure of trustzone-enabled heterogeneous soc,” in _2018 25th IEEE International Conference on Electronics, Circuits and Systems (ICECS)_ , 2018, pp. 489–492.
  * [15] H. Mantel, J. Schickel, A. Weber, and F. Weber, “How secure is green it? the case of software-based energy side channels,” in _Computer Security_ , J. Lopez, J. Zhou, and M. Soriano, Eds. Cham: Springer International Publishing, 2018, pp. 218–239.
  * [16] ARM, “Power and Performance Management using Arm SCMI Specification,” 2019.
  * [17] S. Weiser, M. Werner, F. Brasser, M. Malenko, S. Mangard, and A.-R. Sadeghi, “TIMBER-V: Tag-Isolated Memory Bringing Fine-grained Enclaves to RISC-V,” in _Proceedings 2019 Network and Distributed System Security Symposium_. San Diego, CA: Internet Society, 2019.
  * [18] R. Bahmani, F. Brasser, G. Dessouky, P. Jauernig, M. Klimmek, A.-R. Sadeghi, and E. Stapf, “CURE: A security architecture with CUstomizable and resilient enclaves,” in _30th USENIX Security Symposium (USENIX Security 21)_. USENIX Association, Aug. 2021, pp. 1073–1090.
  * [19] S. Zhang, A. Tang, Z. Jiang, S. Sethumadhavan, and M. Seok, “Blacklist core: Machine-learning based dynamic operating-performance-point blacklisting for mitigating power-management security attacks,” in _Proceedings of the International Symposium on Low Power Electronics and Design_ , ser. ISLPED ’18. New York, NY, USA: Association for Computing Machinery, 2018.
  * [20] R. Schone, T. Ilsche, M. Bielert, M. Velten, M. Schmidl, and D. Hackenberg, “Energy efficiency aspects of the amd zen 2 architecture,” in _2021 IEEE International Conference on Cluster Computing (CLUSTER)_. Los Alamitos, CA, USA: IEEE Computer Society, sep 2021, pp. 562–571.
  * [21] M. Schweikhardt and M. Hahn, “DFS for mixed criticality real time scenarios on 11th generation intel core processors,” Mar. 2022.
  * [22] P. Bose, A. Buyuktosunoglu, J. A. Darringer, M. S. Gupta, M. B. Healy, H. Jacobson, I. Nair, J. A. Rivers, J. Shin, A. Vega, and A. J. Weger, “Power management of multi-core chips: Challenges and pitfalls,” in _2012 Design, Automation & Test in Europe Conference & Exhibition (DATE)_, 2012, pp. 977–982.
  * [23] Intel, “Intel® 64 and IA-32 Architectures Software Developer’s Manual. Vol. 3, part 15.4,” 2021.
  * [24] K. Gomina, J.-B. Rigaud, P. Gendrier, P. Candelier, and A. Tria, “Power supply glitch attacks: Design and evaluation of detection circuits,” in _2014 IEEE International Symposium on Hardware-Oriented Security and Trust (HOST)_ , 2014, pp. 136–141.
  * [25] A. Shameli-Sendi, “Understanding linux kernel vulnerabilities,” _Journal of Computer Virology and Hacking Techniques_ , vol. 17, 12 2021.
  * [26] J. Osborn and D. Challener, “Trusted platform module evolution,” _John Hopkins APL Technical Digest_ , vol. 32, pp. 536–543, 09 2013.
  * [27] M. Sabt, M. Achemlal, and A. Bouabdallah, “Trusted execution environment: What it is, and what it is not,” in _2015 IEEE Trustcom/BigDataSE/ISPA_ , vol. 1, 2015, pp. 57–64.
  * [28] J.-E. Ekberg, K. Kostiainen, and N. Asokan, “Trusted execution environments on mobile devices,” in _Proceedings of the 2013 ACM SIGSAC Conference on Computer & Communications Security_, ser. CCS ’13. New York, NY, USA: Association for Computing Machinery, 2013, p. 1497–1498.
  * [29] L. Yan, Y. Guo, X. Chen, and H. Mei, “A study on power side channels on mobile devices,” in _Proceedings of the 7th Asia-Pacific Symposium on Internetware_ , ser. Internetware ’15, 2015, p. 30–38.
  * [30] A. M. Shuvo, T. Zhang, F. Farahmandi, and M. Tehranipoor, “A Comprehensive Survey on Non-Invasive Fault Injection Attacks,” _Sensors_ , 2022\.
  * [31] D. G. Mahmoud, S. Hussein, V. Lenders, and M. Stojilović, “FPGA-to-CPU undervolting attacks,” in _2022 Design, Automation & Test in Europe Conference & Exhibition (DATE)_, 2022, pp. 999–1004.
  * [32] P. Qiu, D. Wang, Y. Lyu, and G. Qu, “Voltjockey: Breaching trustzone by software-controlled voltage manipulation over multi-core frequencies,” in _Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security_ , ser. CCS ’19. New York, NY, USA: Association for Computing Machinery, 2019, p. 195–209.
  * [33] ——, “Voltjockey: Breaking sgx by software-controlled voltage-induced hardware faults,” in _2019 Asian Hardware Oriented Security and Trust Symposium (AsianHOST)_ , 2019, pp. 1–6.
  * [34] Z. Kenjar, T. Frassetto, D. Gens, M. Franz, and A.-R. Sadeghi, “V0LTpwn: Attacking x86 processor integrity from software,” in _29th USENIX Security Symposium (USENIX Security 20)_. USENIX Association, Aug. 2020, pp. 1445–1461.
  * [35] S. Noubir, M. Mendez Real, and S. Pillement, “Towards malicious exploitation of energy management mechanisms,” in _2020 Design, Automation & Test in Europe Conference & Exhibition (DATE)_, 2020, pp. 1043–1048.
  * [36] A. Rabich, “Software-based Undervolting Faults in AMD Zen Processors,” Ph.D. dissertation, Aug. 2020.
  * [37] Y. Qin and C. Yue, “Website fingerprinting by power estimation based side-channel attacks on android 7,” in _2018 17th IEEE International Conference On Trust, Security And Privacy In Computing And Communications/ 12th IEEE International Conference On Big Data Science And Engineering (TrustCom/BigDataSE)_ , 2018, pp. 1030–1039.
  * [38] Y. Michalevsky, A. Schulman, G. A. Veerapandian, D. Boneh, and G. Nakibly, “PowerSpy: Location tracking using mobile device power analysis,” in _24th USENIX Security Symposium (USENIX Security 15)_. Washington, D.C.: USENIX Association, Aug. 2015, pp. 785–800.
  * [39] C. Liu, A. Chakraborty, N. Chawla, and N. Roggel, “Frequency throttling side-channel attack,” in _Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security_ , ser. CCS ’22. New York, NY, USA: Association for Computing Machinery, 2022, p. 1977–1991.
  * [40] H. Taneja, J. Kim, J. J. Xu, S. Van Schaik, D. Genkin, and Y. Yarom, “Hot pixels: frequency, power, and temperature attacks on gpus and arm socs,” in _Proceedings of the 32nd USENIX Conference on Security Symposium_ , ser. SEC ’23. USA: USENIX Association, 2023\.
  * [41] Y. Wang, R. Paccagnella, A. Wandke, Z. Gang, G. Garrett-Grossman, C. W. Fletcher, D. Kohlbrenner, and H. Shacham, “Dvfs frequently leaks secrets: Hertzbleed attacks beyond sike, cryptography, and cpu-only data,” in _2023 IEEE Symposium on Security and Privacy (SP)_ , 2023, pp. 2306–2320.
  * [42] A. Kogler, J. Juffinger, L. Giner, L. Gerlach, M. Schwarzl, M. Schwarz, D. Gruss, and S. Mangard, “Collide+Power: Leaking Inaccessible Data with Software-based Power Side Channels,” in _USENIX Security_ , 2023.
  * [43] M. Yue, W. H. Robinson, L. Watkins, and C. Corbett, “Constructing timing-based covert channels in mobile networks by adjusting cpu frequency,” in _Proceedings of the Third Workshop on Hardware and Architectural Support for Security and Privacy_ , ser. HASP ’14. New York, NY, USA: Association for Computing Machinery, 2014.
  * [44] M. Alagappan, J. Rajendran, M. Doroslovački, and G. Venkataramani, “DFS covert channels on multi-core platforms,” in _2017 IFIP/IEEE International Conference on Very Large Scale Integration (VLSI-SoC)_ , 2017, pp. 1–6.
  * [45] S. K. Khatamifard, L. Wang, A. Das, S. Kose, and U. R. Karpuzcu, “Powert channels: A novel class of covert communication exploiting power management vulnerabilities,” in _2019 IEEE International Symposium on High Performance Computer Architecture (HPCA)_ , 2019, pp. 291–303.
  * [46] P. Miedl, X. He, M. Meyer, D. B. Bartolini, and L. Thiele, “Frequency scaling as a security threat on multicore systems,” _IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems_ , vol. 37, no. 11, pp. 2497–2508, 2018.
  * [47] M. Kalmbach, M. Gottschlag, T. Schmidt, and F. Bellosa, “TurboCC: A practical frequency-based covert channel with intel turbo boost,” 2020.
  * [48] A. Kogler, D. Gruss, and M. Schwarz, “Minefield: A software-only protection for SGX enclaves against DVFS attacks,” in _31st USENIX Security Symposium (USENIX Security 22)_. Boston, MA: USENIX Association, Aug. 2022, pp. 4147–4164.
  * [49] J. Huang, J. Ye, X. Ye, D. Wang, D. Fan, H. Li, X. Li, and Z. Zhang, “Instruction vulnerability test and code optimization against dvfs attack,” in _2019 IEEE International Test Conference in Asia (ITC-Asia)_ , 2019, pp. 49–54.
  * [50] Intel, “Running Average Power Limit Energy Reporting CVE-2020-8694, CVE-2020-8695,” Feb. 2022.
  * [51] N. Mishra, R. A. Mool, and A. Chakraborty, “Plug Your Volt: Protecting Intel Processors against Dynamic Voltage Frequency Scaling based Fault Attacks,” 2023.
  * [52] J. Juffinger, S. Kalinin, D. Gruss, and F. Mueller, “Suit: Secure undervolting with instruction traps,” in _Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2_ , ser. ASPLOS ’24. New York, NY, USA: Association for Computing Machinery, 2024, p. 1128–1145.
  * [53] Z. Tao, R. Sun, and J. Dong, “Software countermeasures against DVFS fault attack for AES,” in _2023 10th International Conference on Dependable Systems and Their Applications (DSA)_ , 2023, pp. 575–582.
  * [54] M. Werner, R. Schilling, T. Unterluggauer, and S. Mangard, “Protecting risc-v processors against physical attacks,” in _2019 Design, Automation & Test in Europe Conference & Exhibition (DATE)_, 2019, pp. 1136–1141.
  * [55] J. Laurent, V. Beroulle, C. Deleuze, F. Pebay-Peyroula, and A. Papadimitriou, “Cross-layer analysis of software fault models and countermeasures against hardware fault attacks in a risc-v processor,” _Microprocessors and Microsystems_ , vol. 71, p. 102862, 2019.
  * [56] S. Michelland, C. Deleuze, and L. Gonnord, “From low-level fault modeling (of a pipeline attack) to a proven hardening scheme,” in _Compiler Construction (CC’24)_ , Edinburgh (Scotland), United Kingdom, Mar. 2024.
  * [57] B. Yuce, N. F. Ghalaty, C. Deshpande, C. Patrick, L. Nazhandali, and P. Schaumont, “FAME: Fault-attack Aware Microprocessor Extensions for Hardware Fault Detection and Software Fault Response,” in _Proceedings of the Hardware and Architectural Support for Security and Privacy 2016_. Seoul Republic of Korea: ACM, Jun. 2016, pp. 1–8.
  * [58] D. Hackenberg, T. Ilsche, R. Schöne, D. Molka, M. Schmidt, and W. E. Nagel, “Power measurement techniques on standard compute nodes: A quantitative comparison,” in _2013 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS)_ , Apr. 2013, pp. 194–204.
  * [59] B. Rountree, D. H. Ahn, B. R. de Supinski, D. K. Lowenthal, and M. Schulz, “Beyond DVFS: A First Look at Performance under a Hardware-Enforced Power Bound,” in _2012 IEEE 26th International Parallel and Distributed Processing Symposium Workshops & PhD Forum_, May 2012, pp. 947–953.
  * [60] E. De Mulder, S. Gummalla, and M. Hutter, “Protecting RISC-V against Side-Channel Attacks,” in _Proceedings of the 56th Annual Design Automation Conference 2019_. Las Vegas NV USA: ACM, Jun. 2019, pp. 1–4.

EIST

    Enhanced Intel Speedstep Technology
OPP

    Operating Point
CPU

    central processing unit
MSR

    model-specific register
DFA

    Differential Fault Analysis
DVFS

    Dynamic Voltage and Frequency Scaling
TEE

    Trusted Execution Environment
RE

    Rich Execution Environment
ISA

    Instruction Set Architecture
TPM

    Trusted Platform Module
OS

    Operating System
TA

    Trusted Applications
SE

    Secure Element
SGX

    Software Guard Extension
SEV

    Secure Encrypted Virtualization
MMU

    Memory Management Unit
SE

    Secure Element
QSEE

    Qualcomm Secure Execution Environment
TCB

    Trusted Computing Base
RoT

    Root of Trust
NS

    Non-Secure
SCR

    Secure Configuration Register
SM

    Secure Monitor
EPC

    Enclave Page Cache
EPCM

    Enclave Page Cache Map
PRM

    Processor Reserved Memory
AEX

    Asynchronous Enclave Exit
LLC

    Last-Level Cache
TLB

    Translation Lookaside Buffer
PTW

    Page Table Walker
PMP

    Physical Memory Protection
MPU

    Memory Protection Unit
SCA

    Side-Channel Attack
DFA

    Differential Fault Analysis
DoS

    Denial-of-Service
FIA

    Fault Injection Attack
PMIC

    Power Management Integrated Circuit
RAPL

    Running Average Power Limit
KASLR

    Kernel Address Space Layout Randomization
UI

    User Interface
SoC

    System on Chip
RE

    Rich Environment
OS

    Operating System
PoC

    Proof-of-Concept
  *[TEE]: Trusted Execution Environment
  *[TEEs]: Trusted Execution Environment
  *[RE]: Rich Environment
  *[OS]: Operating System
  *[SCA]: Side-Channel Attack
  *[SGX]: Software Guard Extension
  *[SCAs]: Side-Channel Attack
  *[DFA]: Differential Fault Analysis
  *[SoCs]: System on Chip
  *[DVFS]: Dynamic Voltage and Frequency Scaling
  *[OPP]: Operating Point
  *[CPU]: central processing unit
  *[OPPs]: Operating Point
  *[SoC]: System on Chip
  *[PMIC]: Power Management Integrated Circuit
  *[RAPL]: Running Average Power Limit
  *[MSRs]: model-specific register
  *[TPM]: Trusted Platform Module
  *[ISA]: Instruction Set Architecture
  *[OSs]: Operating System
  *[TCB]: Trusted Computing Base
  *[SM]: Secure Monitor
  *[REs]: Rich Environment
  *[DVFSs]: Dynamic Voltage and Frequency Scaling
  *[QSEE]: Qualcomm Secure Execution Environment
  *[MSR]: model-specific register
  *[CPUs]: central processing unit
  *[FIA]: Fault Injection Attack