SUIT: Secure Undervolting with Instruction Traps

To save power, CPUs lower their voltage, but if they go too low some instructions silently compute wrong answers — a hole that real attacks have exploited — so chipmakers keep a wasteful voltage safety margin; this work from Graz and NC State observes that only a few rare instructions are actually fragile at low voltage, and builds SUIT, which runs the CPU on a bold undervolted setting most of the time, traps the rare fragile instructions to a safe fallback, and hardens the one common troublemaker in hardware, cutting energy by up to about 21 percent with no loss of speed, reliability, or security.

The argument in one glance

Problem

The voltage safety margin that keeps CPUs correct wastes energy

CPUs save power by lowering their voltage, since dynamic power grows with the square of the voltage. But drop too low and some instructions silently compute wrong results — a fault that real attacks have exploited to break security. So vendors keep a generous voltage guardband so every instruction is safe, and that margin burns extra energy almost all of the time.
What people did

Undervolt aggressively for efficiency

Prior work reduces the voltage margin to save energy, sometimes eating into the aging and temperature guardbands and relying on error-correction or detection to catch the resulting faults.
Why it fell short

Aggressive undervolting risks faults, reliability, and security

Trimming the margin blindly can make fragile instructions fault, which is both a reliability hazard and a security hole that undervolting-fault attacks exploit. Eating into the aging and temperature guardbands can shorten the chip's life. The margin was there for a reason, and removing it uniformly reintroduces exactly the danger it prevented.
This paper's idea

Trap the few fragile instructions; harden the frequent one (SUIT)

SUIT observes that only a few instructions are fragile at low voltage, and they are rare in real code. It adds a second, more efficient DVFS curve that is safe for every instruction except that small set, which is disabled on it. The CPU runs undervolted by default; a trap and deadline mechanism handles the rare fragile instructions, and the one frequent fragile instruction, integer multiply, is hardened in hardware. Energy efficiency rises by up to 20.8 percent with no loss of performance, reliability, or security.

Why this problem is worth solving

Lowering voltage is the most powerful efficiency lever a CPU has, and also its most dangerous.

A processor trades performance against power using dynamic voltage and frequency scaling, or DVFS: depending on the workload it raises or lowers both its clock frequency and its supply voltage. Voltage is the key to energy, because the dynamic power a chip burns grows with the square of its supply voltage — so shaving even a little voltage saves a disproportionate amount of energy. Lowering the voltage below what the chip strictly needs is called undervolting. The danger is that a transistor switches more slowly at lower voltage, and if the voltage falls too far, signals arrive too late and the circuit computes wrong values. These are silent faults: no crash, no error message, just an incorrect result. Worse, they are a security problem, not only a reliability one. Real attacks, such as Plundervolt, have deliberately undervolted a CPU to induce faults in sensitive computations — for instance corrupting an encryption step to leak a secret key. To keep every instruction correct under the worst case of manufacturing variation, aging, and temperature, vendors run the chip with a generous safety margin called a voltage guardband. It works, but it means the CPU carries extra voltage, and wastes extra energy, essentially all the time.

The waste is concentrated: the whole chip pays a high voltage for the sake of a rare few instructions.

SUIT builds on a striking finding from prior measurement studies: instructions are not equally susceptible to undervolting faults. As the voltage drops, a small number of instructions start producing wrong results first, while the rest of the instruction set keeps computing correctly at much lower voltages. The gap is large — up to about 150 millivolts of difference between the voltage the most fragile instruction needs and what the rest need. The usual culprits are the integer multiply instruction (IMUL), some vector (SIMD) instructions, and the AES encryption instructions, because these have unusually long internal circuit paths that fail first when starved of voltage. Just as important, these fragile instructions are rare in real programs. Across the SPEC CPU2017 benchmarks, a fault-prone instruction of the infrequent kind shows up on average only once every roughly 5 billion instructions, and they tend to appear in short bursts, for example during a stretch of encryption. Integer multiply is the one exception — it can occur as often as every few hundred instructions. So the voltage guardband that protects the whole chip exists almost entirely to keep a handful of rarely-used, fragile instructions correct, while every other instruction is forced to run at that same cautious voltage.

What people did before, and where it broke

Keep a single conservative DVFS curve. Set one voltage-frequency schedule with a guardband high enough that every instruction is always safe. Where it broke. The margin is sized for the most fragile instruction and the worst case, so the chip carries and wastes that extra voltage almost all of the time.
Undervolt aggressively across the board. Push the voltage lower to save energy, trusting that faults are rare. Where it broke. Fragile instructions then fault, silently corrupting results — a reliability hazard and a security hole that undervolting-fault attacks exploit.
Eat into the aging and temperature guardbands. Reclaim the margins reserved for wear and heat to gain more headroom. Where it broke. Those guardbands protect the chip over its lifetime; spending them can shorten its life or cause failures as it ages and heats.
The gap. No approach reclaimed the wasted voltage margin by recognizing that only a few rare instructions actually need it, while keeping the aging and temperature guardbands intact and the security level unchanged. Doing exactly that is what SUIT contributes.

How SUIT works

From one cautious voltage for all instructions to a bold curve with targeted safety

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Single out the few instructions that actually need the margin. SUIT’s foundation is that the expensive voltage guardband exists almost entirely for a small, identifiable set of fragile instructions, while the rest of the instruction set is safe at much lower voltage. So instead of penalizing every instruction, SUIT treats that fragile set specially and lets everything else run cheaply. Isolating the specific instructions whose low-level hardware behavior is a security liability, and handling exactly those differently from the ordinary majority, is the same move the leaky-instruction hardening work covered elsewhere on this site makes, pinpointing the particular instructions whose operand-dependent hardware shortcuts can expose secrets and rewriting only those rather than slowing down all code.

Trap the rare offender and return on a deadline. For fragile instructions that are infrequent, SUIT runs the CPU on the bold efficient curve with those instructions disabled, and catches any attempt to execute one with a special disabled-opcode exception. The operating system then either emulates the instruction in software or temporarily switches to the safe conservative curve, and a countdown deadline decides when to switch back to the efficient curve once no fragile instruction has run for a while. Running in an efficient mode by default and switching to a costlier safe mode only transiently, governed by a timer that bounds how long the expensive mode lasts, is the same discipline the controlled-preemption work covered elsewhere on this site follows, staying in the efficient regime and bounding, by a deadline, the windows in which the more expensive behavior is allowed.

Pay a tiny fixed hardware cost to remove the frequent offender. Integer multiply is fragile but far too common to trap on every use, so SUIT takes a different tack for it: relax its critical path in the hardware by adding a single clock cycle of latency, which makes it stable even at the low efficient-curve voltage, at a performance cost of almost nothing because out-of-order execution hides it. Adding a small, targeted change inside the processor pipeline to eliminate a recurring hazard cheaply, rather than paying a penalty on every occurrence, is the same kind of microarchitectural fix the redundant-writeback work covered elsewhere on this site applies, building a little extra logic into the core so that a frequent, costly operation is quietly turned into a safe and cheap one.

Following a program with encryption through SUIT

A program that does occasional AES encryption, running under SUIT

A trace of SUIT's behavior on a workload with bursty fragile instructions, following the paper's design.

Step 1 of 5

Run on the efficient, undervolted curve

The program executes mostly ordinary instructions with the occasional burst of AES encryption. Under SUIT the CPU runs on the efficient, lower-voltage DVFS curve, with the fragile instructions (including AES) disabled.

Ordinary code is safe at the lower voltage.

Why it works

Power falls steeply with voltage. Because a chip’s dynamic power grows with the square of its supply voltage → shaving even a little voltage saves a large fraction of energy → so undervolting is one of the most effective efficiency levers a CPU has.
The guardband is sized for a few fragile instructions. Because the voltage must be high enough for the most fragile instruction → the whole chip carries that margin even though most instructions could run much lower → so the margin is wasted almost all of the time.
Fragile instructions are rare and bursty. Because instructions like AES and the vector operations appear only occasionally and in short bursts → the CPU can run undervolted between the bursts and pay a cost only during them → so trapping them is cheap in practice.
The one frequent offender is fixed in hardware. Because integer multiply is too common to trap on every use → adding a single clock cycle to it makes it safe at low voltage for almost no performance cost → so no frequency of fragile instructions defeats the scheme.
Security is preserved by construction. Because the efficient curve is chosen by the same vendor process used today, just excluding the fragile instructions, and those instructions are disabled on it → an attacker cannot trigger an undervolting fault on the efficient curve → so SUIT is as secure as a CPU today while using less energy.

What it costs (trade-offs and scope)

It requires CPU hardware changes. SUIT needs a second DVFS curve, a way to disable specific instructions, the disabled-opcode exception, the deadline mechanism, and the one-cycle relaxation of integer multiply. These are modest but real changes to the processor, not a software-only update.
The largest gains need recompilation. SUIT improves efficiency by 11.0 percent with no software changes and no performance loss. The larger figure, 20.8 percent, comes from also compiling programs to avoid the fragile SIMD instructions so they never leave the efficient curve, which requires recompiling applications and giving up those vector instructions.
The benefit depends on the CPU and the workload. SUIT works best on CPUs with fast frequency switching and per-core voltage domains (the paper prefers Intel Xeon), and on workloads where fragile instructions are rare and bursty. A workload saturated with fragile instructions, or a CPU that switches slowly, gains less.
It leans on hardware that exhibits instruction voltage variation. The whole approach relies on different instructions needing different voltages. The paper notes some CPU generations did not exhibit this variation, in which case there is little to exploit.
It optionally borrows a little aging margin. For its larger undervolt, SUIT uses a small, time-limited fraction of the aging guardband, justified by data centers replacing CPUs within a few years. This is a deliberate, bounded trade, not a free lunch, and it keeps the temperature guardband intact.
Much of the evaluation is in simulation. SUIT is a proof-of-concept: critical parameters are measured on real AMD and Intel CPUs, but the integer-multiply latency change is evaluated in the gem5 simulator and the overall efficiency in an instruction-trace-based simulator, since the second DVFS curve and trap hardware do not exist in shipping CPUs.

The evaluation

Three ways to set a CPU's undervolting policy

Property	Single conservative curve	Aggressive undervolting
Energy efficiency
Fragile instructions stay safe
Keeps aging and temperature guardbands	Yes
Security vs undervolting-fault attacks	Safe
Needs CPU hardware changes	No	Varies

Three ways to manage a CPU's undervolting, as evaluated in the paper. A single conservative DVFS curve keeps every instruction safe but carries a wasteful voltage margin all the time. Aggressive undervolting saves energy but lets fragile instructions fault — a reliability and security hazard — and often eats into the aging and temperature guardbands. SUIT adds a second, more efficient DVFS curve that disables the small set of fragile instructions, handles them with a trap-and-deadline mechanism (emulate the rare ones, briefly switch curves, or run on the conservative curve), and hardens the one frequent one, integer multiply, by adding a single clock cycle (a 0.03 percent average slowdown, at most 1.60 percent). The paper reports the CPU runs on the efficient curve about 72.7 percent of the time, improving energy efficiency by 11.0 percent with no performance loss and no recompilation, and by 20.8 percent (with performance also improving by 3.79 percent) when programs are additionally compiled to avoid fragile vector instructions, corresponding to about a 14 percent reduction in power. The authors give a reductionist argument that SUIT's security equals that of CPUs today, because the efficient curve is chosen by the same vendor process, just excluding the fragile instructions.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

SUIT is an elegant hardware-software co-design that turns a security liability into an efficiency opportunity. Its premise is measured, not assumed: prior studies show that only a handful of instructions — integer multiply, some vector operations, and AES — fault first when a CPU is undervolted, needing up to 150 millivolts more than the rest, and those instructions are rare in real code. From that, SUIT builds a clean mechanism: a second, more efficient DVFS curve on which the fragile instructions are disabled; a trap-and-deadline scheme that catches the rare fragile instruction and either emulates it or briefly switches to the safe curve before returning; and a one-cycle hardware relaxation of the one frequent offender, integer multiply. The results are attractive and honestly reported: the CPU runs undervolted about 72.7 percent of the time, improving energy efficiency by 11.0 percent with no software changes and no performance loss, or by 20.8 percent (with performance actually improving) if programs are recompiled to avoid fragile vector instructions, all while keeping the aging and temperature guardbands essentially intact. The security argument is careful — because the efficient curve is set by the same vendor process as today’s, minus a few instructions, SUIT argues its security equals that of current CPUs, and disabling the fragile instructions on the efficient curve actually closes the undervolting-fault attack surface rather than opening it. Read the scope precisely. SUIT needs CPU hardware changes and does not ship in any product; the largest gains need recompilation and forgoing some SIMD; the benefit depends on the CPU having instruction voltage variation and on fragile instructions being rare in the workload; and while key parameters are measured on real AMD and Intel chips, the end-to-end efficiency is established in simulation. The durable idea is that a worst-case safety margin applied uniformly is almost always overpaid, and that co-designing hardware and software to spend it only where it is truly needed can reclaim large efficiency without weakening reliability or security.

Background

Why trimming a worst-case margin precisely keeps paying off

It helps to see SUIT within a recurring pattern: systems are full of conservative, worst-case safety margins that protect against a rare case but are paid for constantly, and large gains come from being precise about when the margin is actually needed. Here the margin is a voltage guardband sized for the most fragile instruction and the worst aging and temperature; SUIT keeps it only for the few instructions and moments that require it, and lets everything else run cheaply. The copy-on-write pinning work covered elsewhere on this site embodies the same discipline in a different domain, replacing a blanket, always-pay-the-safe-cost policy with careful reasoning about exactly when the expensive protective step — there, duplicating a page — is truly required, so the cost is incurred only in the cases that genuinely need it. The common thread is that safety and efficiency are not fundamentally opposed: a margin that looks essential when applied uniformly often turns out to be needed only in a small, identifiable set of cases, and separating those cases out lets a system be both safe and fast. SUIT adds a second lesson worth carrying: that security can improve alongside efficiency rather than trading against it, because disabling the fragile instructions on the bold setting closes an attack surface while saving power. As energy becomes a first-class concern in data centers and devices, reclaiming the many worst-case margins that hardware and software carry — carefully, without removing the protection where it counts — is a deep and repeatable source of efficiency.

If you remember only three things

1. CPUs save energy by lowering their supply voltage, since dynamic power grows with the square of the voltage, but undervolting too far makes some instructions silently compute wrong results — a reliability failure and a security hole that undervolting-fault attacks like Plundervolt have exploited to leak secrets. To stay safe, vendors keep a generous voltage guardband so every instruction is correct under the worst case of variation, aging, and temperature. That margin is wasteful, because the whole chip carries the extra voltage all the time even though the situations it guards against are rare.
2. SUIT builds on the measured observation that instructions are not equally fragile — only a few (integer multiply, some vector instructions, and AES) fault first at low voltage, needing up to 150 millivolts more than the rest, and they are rare in real code (an infrequent fault-prone instruction appears about once every 5 billion instructions, in short bursts). SUIT adds a second, more efficient DVFS curve that is safe for all instructions except that small set, which is disabled on it. For the rare fragile instructions it uses a trap: a disabled-opcode exception hands control to the OS, which emulates the instruction or briefly switches to the conservative curve and returns after a countdown deadline. For the one frequent fragile instruction, integer multiply, it relaxes the critical path in hardware by one clock cycle so it is safe on the efficient curve.
3. On SPEC CPU2017, SUIT runs on the efficient undervolted curve about 72.7 percent of the time, improving energy efficiency by 11.0 percent with no software changes and no performance loss, or by 20.8 percent (with performance also improving by 3.79 percent) when programs are recompiled to avoid fragile vector instructions — roughly a 14 percent power reduction — while the integer-multiply hardening costs only 0.03 percent on average. It keeps the aging and temperature guardbands essentially intact, borrowing only a small time-limited fraction of aging margin. A reductionist security argument shows SUIT is as secure as CPUs today. Scope: it needs CPU hardware changes and is a proof-of-concept evaluated partly in simulation, its largest gains need recompilation, and it relies on the CPU exhibiting instruction voltage variation. The durable lesson is that uniform worst-case safety margins are almost always overpaid, and co-designing hardware and software to spend them only where needed reclaims large efficiency without sacrificing reliability or security.

Check yourself

Check your understanding

1. Why do CPUs carry a voltage guardband, and why is it wasteful?
2. What is the key observation that makes SUIT possible?
3. How does SUIT handle fragile instructions differently depending on how often they occur?
4. How can SUIT save energy without weakening security?

Sources

The paper is “SUIT: Secure Undervolting with Instruction Traps” by Jonas Juffinger, Stepan Kalinin, Daniel Gruss, and Frank Mueller, published at ASPLOS 2024, DOI 10.1145/3620665.3640373. The authors are at Graz University of Technology and North Carolina State University.

This explainer is based on the full text of the paper, obtained as the open-access (CC-BY, gold) author copy hosted by the authors. The problem framing (dynamic voltage and frequency scaling, the dependence of dynamic power on the square of the supply voltage, voltage guardbands for process variation, aging, and temperature, and undervolting-induced silent faults and their exploitation by fault-injection attacks), the central observation (that instructions differ in their voltage requirements by up to about 150 millivolts, that the fragile instructions are integer multiply, certain SIMD instructions, and AES, and that infrequent fault-prone instructions occur on average about once every 5 billion instructions in short bursts), the design (the second efficient DVFS curve excluding the fragile instructions, the model-specific register to disable instructions and select the curve, the disabled-opcode exception, the trap handling by emulation or curve switching, the countdown deadline mechanism, and the one-clock-cycle relaxation of the integer multiply critical path), the security argument (the reductionist argument that SUIT’s security equals that of current CPUs because the efficient curve is derived by the same vendor process minus the fragile instructions), and the evaluation results (the roughly 72.7 percent of time on the efficient curve, the 11.0 percent efficiency gain with no performance loss, the 20.8 percent efficiency gain with a 3.79 percent performance improvement when compiling without fragile SIMD instructions, the roughly 14 percent power reduction, the 0.03 percent average and 1.60 percent maximum slowdown from the integer-multiply change, and the measurements on AMD and Intel CPUs together with the gem5 and instruction-trace simulations) are all drawn directly from the paper. Background explanations of CMOS power, critical paths, DVFS, and CPU exceptions are standard and provided to make the paper’s contribution understandable.