CLKSCREW: Exposing the Perils of Security- Oblivious Energy Management
Adrian Tang, , and , Columbia University https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/tang
This paper is included in the Proceedings of the 26th USENIX Security Symposium
August 16–18, 2017 • Vancouver, BC, Canada
Copyright By PowCoder代写 加微信 powcoder
ISBN 978-1-931971-40-9
Open access to the Proceedings of the 26th USENIX Security Symposium
is sponsored by USENIX
CLKSCREW: Exposing the Perils of Security-Oblivious Energy Management
Adrian University
The need for power- and energy-efficient computing has resulted in aggressive cooperative hardware-software en- ergy management mechanisms on modern commodity devices. Most systems today, for example, allow soft- ware to control the frequency and voltage of the under- lying hardware at a very fine granularity to extend bat- tery life. Despite their benefits, these software-exposed energy management mechanisms pose grave security im- plications that have not been studied before.
In this work, we present the CLKSCREW attack, a new class of fault attacks that exploit the security- obliviousness of energy management mechanisms to break security. A novel benefit for the attackers is that these fault attacks become more accessible since they can now be conducted without the need for physical access to the devices or fault injection equipment. We demonstrate CLKSCREW on commodity ARM/Android devices. We show that a malicious kernel driver (1) can extract secret cryptographic keys from Trustzone, and (2) can escalate its privileges by loading self-signed code into Trustzone. As the first work to show the security ramifications of en- ergy management mechanisms, we urge the community to re-examine these security-oblivious designs.
1 Introduction
The growing cost of powering and cooling systems has made energy management an essential feature of most commodity devices today. Energy management is cru- cial for reducing cost, increasing battery life, and im- proving portability for systems, especially mobile de- vices. Designing effective energy management solutions, however, is a complex task that demands cross-stack de- sign and optimizations: Hardware designers, system ar- chitects, and kernel and application developers have to coordinate their efforts across the entire hardware/soft- ware system stack to minimize energy consumption and
Columbia University Columbia University
maximize performance. Take as an example, Dynamic Voltage and Frequency Scaling (DVFS) [47], a ubiq- uitous energy management technique that saves energy by regulating the frequency and voltage of the proces- sor cores according to runtime computing demands. To support DVFS, at the hardware level, vendors have to de- sign the underlying frequency and voltage regulators to be portable across a wide range of devices while ensur- ing cost efficiency. At the software level, kernel devel- opers need to track and match program demands to oper- ating frequency and voltage settings to minimize energy consumption for those demands. Thus, to maximize the utility of DVFS, hardware and software function cooper- atively and at very fine granularities.
Despite the ubiquity of energy management mecha- nisms on commodity systems, security is rarely a consid- eration in the design of these mechanisms. In the absence of known attacks, given the complexity of hardware- software interoperability needs and the pressure of cost and time-to-market concerns, the designers of these mechanisms have not given much attention to the secu- rity aspects of these mechanisms; they have been focused on optimizing the functional aspects of energy manage- ment. These combination of factors along with the per- vasiveness of these mechanisms makes energy manage- ment mechanisms a potential source of security vulnera- bilities and an attractive target for attackers.
In this work, we present the first security review of a widely-deployed energy management technique, DVFS. Based on careful examination of the interfaces between hardware regulators and software drivers, we uncover a new class of exploitation vector, which we term as CLKSCREW. In essence, a CLKSCREW attack exploits unfettered software access to energy management hard- ware to push the operating limits of processors to the point of inducing faulty computations. This is dangerous when these faults can be induced from lower privileged software across hardware-enforced boundaries, where security sensitive computations are hosted.
USENIX Association
26th USENIX Security Symposium 1057
We demonstrate that CLKSCREW can be conducted using no more than the software control of energy management hardware regulators in the target devices. CLKSCREW is more powerful than traditional physi- cal fault attacks [19] for several reasons. Firstly, un- like physical fault attacks, CLKSCREW enables fault at- tacks to be conducted purely from software. Remote ex- ploitation with CLKSCREW becomes possible without the need for physical access to target devices. Secondly, many equipment-related barriers, such as the need for soldering and complex equipment, to achieve physical fault attacks are removed. Lastly, since physical attacks have been known for some time, several defenses, such as special hardened epoxy and circuit chips that are hard to access, have been designed to thwart such attacks. Ex- tensive hardware reverse engineering may be needed to determine physical pins on the devices to connect the fault injection circuits [45]. CLKSCREW sidesteps all these risks of destroying the target devices permanently.
To highlight the practical security impact of our attack, we implement the CLKSCREW attack on a commodity ARMv71 phone, Nexus 6. With only publicly available knowledge of the Nexus 6 device, we identify the operat- ing limits of the frequency and voltage hardware mecha- nisms. We then devise software to enable the hardware to operate beyond the vendor-recommended limits. Our at- tack requires no further access beyond a malicious kernel driver. We show how the CLKSCREW attack can sub- vert the hardware-enforced isolation in ARM Trustzone in two attack scenarios: (1) extracting secret AES keys embedded within Trustzone and (2) loading self-signed code into Trustzone. We note that the root cause for CLKSCREW is neither a hardware nor a software bug: CLKSCREW is achievable due to the fundamental design of energy management mechanisms.
We have responsibly disclosed the vulnerabilities identified in this work to the relevant SoC and device vendors. They have been very receptive to the disclosure. Besides acknowledging the highlighted issues, they were able to reproduce the reported fault on their internal test device within three weeks of the disclosure. They are working towards mitigations.
In summary, we make the following contributions in this work:
1. We expose the dangers of designing energy man- agement mechanisms without security in mind by introducing the concept of the CLKSCREW attack. Aggressive energy-aware computing mechanisms can be exploited to influence isolated computing.
2. We present the CLKSCREW attack to demonstrate a new class of energy management-based exploitation
1As of Sep 2016, ARMv7 devices capture over 86% of the world- wide market share of mobile phones [7].
vector that exploits software-exposed frequency and voltage hardware regulators to subvert trusted com- putation.
3. We introduce a methodology for examining and demonstrating the feasibility of the CLKSCREW at- tack against commodity ARM devices running a full complex OS such as Android.
4. We demonstrate that the CLKSCREW attack can be used to break the ARM Trustzone by extracting se- cret cryptographic keys and loading self-signed ap- plications on a commodity phone.
The remainder of the paper is organized as follows. We provide background on DVFS and its associated hardware and software support in § 2. In § 3, we de- tail challenges and steps we take to achieving the first CLKSCREW fault. Next, we present two attack case studies in § 4 and § 5. Finally, we discuss countermea- sures and related work in § 6, and conclude in § 7.
2 Background
In this section, we provide the required background in energy management to understand CLKSCREW. We first describe DVFS and how it relates to saving energy. We then detail key classes of supporting hardware regulators and their software-exposed interfaces.
2.1 Dynamic Voltage & Frequency Scaling
DVFS is an energy management technique that trades off processing speed for energy savings. Since its debut in 1994 [60], DVFS has become ubiquitous in almost all commodity devices. DVFS works by regulating two im- portant runtime knobs that govern the amount of energy consumed in a system – frequency and voltage.
To see how managing frequency and voltage can save energy, it is useful to understand how energy consump- tion is affected by these two knobs. The amount of en- ergy2 consumed in a system is the product of power and time, since it refers to the total amount of resources uti- lized by a system to complete a task over time. Power3, an important determinant of energy consumption, is di- rectly proportional to the product of operating frequency and voltage. Consequently, to save energy, many energy management techniques focus on efficiently optimizing both frequency and voltage.
2Formally, the total amount of energy consumed, ET , is the integral of instantaneous dynamic power, Pt over time T : ET = 0T Pt dt .
3In a system with a fixed capacitative load, at any time t, the instan- taneous dynamic power is proportional to both the voltage, Vt and the frequency Ft as follows: Pt ∝ Vt2 × Ft .
1058 26th USENIX Security Symposium
USENIX Association
Voltage output to cores
Voltage output to other peripherals
SoC Processor
Core 0 SPM Core 0
CCoorere00
Voltage Domain (All cores)
(All cores)
Voltage Control
SoC Processor
Clock Domain (per-core)
Source Selector
PLL (fixed rate)
HFPLL (variable rate)
Half Divider
N Multiplier
N * 19.2MHz 1Clock MUX
N/2 * 19.2 MHz 2
Figure 1: Shared voltage regulator for all Krait cores.
DVFS regulates frequency and voltage according to runtime task demands. As these demands can vary dras- tically and quickly, DVFS needs to be able to track these demands and effect the frequency and voltage adjust- ments in a timely manner. To achieve this, DVFS re- quires components across layers in the system stack. The three primary components are (1) the voltage/frequency hardware regulators, (2) vendor-specific regulator driver, and (3) OS-level CPUfreq power governor [46]. The combined need for accurate layer-specific feedback and low voltage/frequency scaling latencies drives the preva- lence of unfettered and software-level access to the fre- quency and voltage hardware regulators.
2.2 Hardware Support for DVFS
Voltage Regulators. Voltage regulators supply power to various components on devices, by reducing the volt- age from either the battery or external power supply to a range of smaller voltages for both the cores and the pe- ripherals within the device. To support features, such as camera and sensors that are sourced from different ven- dors and hence operating at different voltages, numerous voltage regulators are needed on devices. These regu- lators are integrated within a specialized circuit called Power Management Integrated Circuit (PMIC) [53].
Power to the application cores is typically supplied by the step-down regulators within the PMIC on the System-on-Chip (SoC) processor. As an example, Fig- ure 1 shows the PMIC that regulates the shared voltage supply to all the application cores (a.k.a. Krait cores) on the Nexus 6 device. The PMIC does not directly ex- pose software interfaces for controlling the voltage sup- ply to the cores. Instead, the core voltages are indirectly managed by a power management subsystem, called the Subsystem Power Manager (SPM) [2]. The SPM is a hardware block that maintains a set of control registers which, when configured, interfaces with the PMIC to ef- fect voltage changes. Privileged software like a kernel driver can use these memory-mapped control registers
Figure 2: Separate clock sources for each Krait core.
to direct voltage changes. We highlight these software- exposed controls as yellow-shaded circles in Figure 1.
FrequencyPLL-basedRegulators. Theoperatingfre- quency of application cores is derived from the frequency of the clock signal driving the underlying digital logic circuits. The frequency regulator contains a Phase Lock Loop (PLL) circuit, a frequency synthesizer built into modern processors to generate a synchronous clock sig- nal for digital components. The PLL circuit generates an output clock signal of adjustable frequency, by receiving a fixed-rate reference clock (typically from a crystal os- cillator) and raising it based on an adjustable multiplier ratio. The output clock frequency can then be controlled by changing this PLL multiplier.
For example, each core on the Nexus 6 has a dedicated clock domain. As such, the operating frequency of each core can be individually controlled. Each core can oper- ate on three possible clock sources. In Figure 2, we illus- trate the clock sources as well as the controls (shaded in yellow) exposed to the software from the hardware reg- ulators. A multiplexer (MUX) is used to select amongst the three clock sources, namely (1) a PLL supplying a fixed-rate 300-MHz clock signal, (2) a High-Frequency PLL (HFPLL) supplying a clock signal of variable fre- quency based on a N multiplier, and (3) the same HFPLL supplying half the clock signal via a frequency divider for finer-grained control over the output frequency.
As shown in Figure 2, the variable output frequency of the HFPLL is derived from a base frequency of 19.2MHz and can be controlled by configuring the N multiplier. For instance, to achieve the highest core operating fre- quency of 2.65GHz advertised by the vendor, one needs to configure the N multiplier to 138 and the Source Se- lector to 1 to select the use of the full HFPLL. Similar to changing voltage, privileged software can initiate per- core frequency changes by writing to software-exposed memory-mapped PLL registers, shown in Figure 2.
USENIX Association
26th USENIX Security Symposium 1059
1 clock pulse
input (0 1)
output (0 1)
FFsrc Intermediate FFdst combinatorial logic
colomcmkosnigcnloaclk prosivgindaelr
TFF Tsetup TFF
2.3 Software Support for DVFS
On top of the hardware regulators, additional software support is needed to facilitate DVFS. Studying these sup- porting software components for DVFS enables us to better understand the interfaces provided by the hard- ware regulators. Software support for DVFS comprises two key components, namely vendor-specific regulator drivers and OS-level power management services.
Besides being responsible for controlling the hardware regulators, the vendor-provided PMIC drivers [5, 6] also provide a convenient means for mechanisms in the up- per layers of the stack, such as the Linux CPUfreq power governor [46] to dynamically direct the voltage and fre- quency scaling. DVFS requires real-time feedback on the system workload profile to guide the optimization of performance with respect to power dissipation. This feedback may rely on layer-specific information that may only be efficiently accessible from certain system layers. For example, instantaneous system utilization levels are readily available to the OS kernel layer. As such, the Linux CPUfreq power governor is well-positioned at that layer to initiate runtime changes to the operating voltage and frequency based on these whole-system measures. This also provides some intuition as to why DVFS can- not be implemented entirely in hardware.
3 Achieving the First CLKSCREW Fault
In this section, we first briefly describe why erroneous computation occurs when frequency and voltage are stretched beyond the operating limits of digital circuits. Next, we outline challenges in conducting a non-physical probabilistic fault injection attack induced from soft- ware. Finally, we characterize the operating limits of regulators and detail the steps to achieving the first CLKSCREW fault on a real device.
3.1 How Timing Faults Occur
To appreciate why unfettered access to hardware regula- tors is dangerous, it is necessary to understand in general why over-extending frequency (a.k.a. overclocking) or under-supplying voltage (a.k.a. undervolting) can cause unintended behavior in digital circuits.
Synchronous digital circuits are made up of mem- ory elements called flip-flops (FF). These flip-flops store stateful data for digital computation. A typical flip-flop has an input D, and an output Q, and only changes the output to the value of the input upon the receipt of the rising edge of the clock (CLK) signal. In Figure 3, we show two flip-flops, FFsrc and FFdst sharing a com- mon clock signal and some intermediate combinatorial
Figure 3: Timing constraint for error-free data propaga- tion from input Qsrc to output Ddst for entire circuit.
logic elements. These back-to-back flip-flops are build- ing blocks for pipelines, which are pervasive throughout digital chips and are used to achieve higher performance.
Circuit timing constraint. For a single flip-flop to properly propagate the input to the output locally, there are three key timing sub-constraints. (1) The incoming data signal has to be held stable for T setup during the re- ceipt of the clock signal, and (2) the input signal has to be held stable for T FF within the flip-flop after the clock sig- nal arrives. (3) It also takes a minimum of T max_path for the output Qsrc of FFsrc to propagate to the input Ddst of F F dst . For the overall circuit to propagate input Dsrc → output Qdst , the minimum required clock cycle period4 , T clk , is bounded by the following timing constraint (1) for some microarchitectural constant K:
Tclk ≥ TFF +Tmax_path +Tsetup +K (1)
Violation of timing constraint. When the timing con- straint is violated during two consecutive rising edges of the clock signal, the output from the source flip-flop FFsrc fails to latch properly in time as the input at the destination flip-flop FFdst. As such, the FFdst continues to operate with stale data. There are two situations where this timing constraint can be violated, namely (a) over- clocking to reduce T clk and (b) undervolting to increase the overall circuit propagation time, thereby increasing Tmax_path. Figure 4 illustrates how the output results in an unintended erroneous value of 0 due to overclocking. For comparison, we show an example of a bit-level fault due to undervolting in Figure 15 in Appendix A.1.
4Tclk is simply the reciprocal of the clock frequency.
1060 26th USENIX Security Symposium
USENIX Association
3.5 3.0 2.5 2.0 1.5 1.0 0.5
Maximum OPP Vendor stock OPP
0.9 1.0 Voltage (V)
1.1 1.2 1.3
1 clock pulse
input (0 1)
output (0 0) 0
glitched output 0
Figure 4: Bit-level fault due to overclocking: Reducing clock period T clk → T clk ′ results in a bit-flip in output 1→0.
3.2 Challenges of CLKSCREW Attacks
Mounting a fault attack purely from software on a real- world commodity device using its internal voltage/fre- quency hardware regulators has numerous difficulties. These challenges are non-existent or vastly different from those in traditional physical fault attacks (that com- monly use laser, heat and radiation).
Regulator operating limits. Overclocking or under- volting attacks require the hardware to be configured far beyond its vendor-suggested operatin
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com