FLEXPROF: Flexible, Side-Channel-Free Memory Access

To stop one virtual machine from spying on another through the shared memory controller, secure systems give each VM fixed "turns" to use memory with safety gaps in between — but making that leak-free roughly halves performance, partly because every turn must be ready for either reads or writes; this paper (University of Utah — Jarrett Minton and Rajeev Balasubramonian) presents FlexProf, which instead gives each turn a fixed read-or-write role, uses coarse, non-leaky profiling to decide how often each kind of turn runs, and lets a read turn opportunistically slip in writes (and vice versa) to win back throughput without reopening the side channel.

The argument in one glance

Problem

Sharing one memory controller lets one VM spy on another

In a cloud server, many virtual machines (VMs) run on the same physical hardware, and they share the memory controller — the unit that decides which memory request goes to DRAM and when. That sharing is a security hole. Because the memory system is a contended resource, the timing of one VM's memory requests depends on what another VM is doing: when a victim is busy hammering memory, an attacker VM's own requests are delayed, and by watching those delays the attacker can infer the victim's activity. This is a microarchitectural side channel, and a memory-controller one is particularly hard to close because throughput and latency there depend on the fine-grained interleaving of everyone's requests. Secure processors are expected to defend against a whole array of such channels, and the shared memory controller is one of the toughest: the very scheduling decisions that make memory fast are the ones that leak. So a cloud that wants to guarantee one tenant cannot learn anything about another through memory timing has to change how the controller schedules requests — and, as it turns out, pay dearly for it.
What people did

Give each VM fixed "turns" with safety gaps between them

The established defense is temporal partitioning: divide the memory controller's time into turns and assign each co-scheduled VM its own turn, so a VM can only issue memory requests during its slot. Crucially, a gap is inserted between turns, sized so that one VM's requests can never spill over and affect the timing of the next VM's turn. Because each VM's memory timing then depends only on its own fixed turn and not on what its neighbors do, the cross-VM timing side channel is closed: an attacker watching its own delays learns nothing about the victim.
Why it fell short

Making it leak-free is worst-case rigid, and roughly halves performance

The safety comes at a steep price: prior secure memory scheduling imposes about a 2 times performance slowdown. The paper identifies one important cause. Each turn is built to accommodate the worst case — it must be prepared to serve either reads or writes. That matters because, in DRAM, reads and writes are not symmetric: the data bus has to "turn around" when switching between reading and writing, and the timing constraints for a read followed by a write differ from a write followed by a read. If a turn does not know in advance whether it will do reads or writes, it must leave conservative timing margins big enough for whichever case is worse, and those margins are dead time that wastes memory throughput. The gaps needed to prevent leakage compound this. So the schedule is rigid in a way that sacrifices a lot of bandwidth purely to be ready for any mix of requests. What was missing was a way to keep the leak-free turn structure but stop paying the worst-case read-or-write penalty on every turn.
This paper's idea

Give each turn a fixed read-or-write role, chosen by non-leaky profiling

FlexProf is a memory controller that keeps the secure turn-based schedule but makes each turn specialized instead of worst-case. Its core idea is to designate every turn to handle a fixed pattern of reads and writes: it introduces a read-optimized turn and a write-optimized turn. Because a read-optimized turn knows it is doing reads, it can use tight, read-tuned timing instead of the conservative margins a "could be either" turn needs, and likewise for writes — so the dead time that caused much of the slowdown shrinks. How often each kind of turn is scheduled is decided by coarse-grain application profiling: the controller measures roughly how read-heavy or write-heavy an application is and sets the mix of read- and write-optimized turns accordingly. Critically, this profiling is coarse enough that it does not leak sensitive information — it captures aggregate behavior, not the fine-grained, possibly secret-dependent access pattern that a side channel would exploit. Finally, FlexProf adds flexibility so the rigidity does not swing too far the other way: a read-optimized turn can opportunistically also issue a write when it has room, and a write-optimized turn can opportunistically issue a read. This strikes a balance between restriction and flexibility, and between throughput and utilization. The paper reports that FlexProf improves performance by up to 33 percent, with a geometric-mean gain of 8 percent on mixed workloads, relative to state-of-the-art secure schedulers, and that over half the memory-intensive programs evaluated gain more than 10 percent — all while preserving the side-channel-free guarantee.

Why this problem is worth solving

Multi-tenant clouds only work if tenants are truly isolated, and the memory controller is one of the last shared resources where that isolation is both essential and expensive.

Public clouds pack many customers onto the same physical machine, which is what makes them affordable — but it only works if one customer cannot learn anything about another. Microarchitectural side channels break that promise by leaking information through shared hardware, and the memory controller is a notably stubborn case: memory is heavily contended, so request timing naturally depends on what everyone else is doing, which is exactly the dependence an attacker exploits. Defenses exist, but if the only way to be safe is to accept roughly half the performance, many operators will decline to deploy them, leaving the channel open. Making a leak-free memory controller that is also fast therefore matters directly: it is the difference between a security guarantee that stays on paper and one that is actually turned on in production. Because memory bandwidth is a first-order determinant of server performance, even a modest reclaim of the lost throughput is broadly valuable across the workloads that share these machines.

The heart of the inefficiency is a worst-case assumption, and worst-case assumptions are where reclaimed performance usually hides.

Secure schedules are conservative by nature — they must hold under every possible behavior, so they tend to plan for the worst case at every step. Here the worst case is not knowing, at the time a turn is scheduled, whether it will carry reads or writes. Because DRAM treats reads and writes asymmetrically and pays a penalty to switch the data bus between them, a turn that must be ready for either has to reserve timing margin for the harder case, and that margin is wasted whenever the actual traffic was uniform. This is a classic pattern: a system pays a standing tax to be prepared for a situation that, on average, is not what happens. The opportunity is to replace “be ready for anything” with “commit to one thing, chosen safely in advance” — provided the choosing does not itself leak. FlexProf’s bet is that the mix of reads and writes an application needs can be learned at a coarse enough grain to be safe, so that most turns can commit to a role and shed the worst-case margin, while a little opportunistic flexibility recovers the cases where the commitment was slightly off.

What people did before, and where it broke

Share the memory controller normally. Let the controller schedule all VMs’ requests together for maximum throughput. Where it broke. Request timing depends on co-tenants’ activity, so an attacker VM can infer a victim VM’s behavior from its own delays — a memory-controller side channel.
Assign fixed turns to each VM with gaps between them. Temporally partition the controller so each VM’s timing depends only on its own turn, with a gap that stops spillover. Where it broke. It closes the channel but imposes about a 2 times slowdown, because partitioning and gaps sacrifice much of the memory system’s throughput.
Make every turn handle either reads or writes. Keep each turn general so it can serve whatever requests arrive. Where it broke. DRAM’s read/write asymmetry and bus turnaround force conservative worst-case timing margins on every turn, and that dead time is a major part of the slowdown.
Profile applications finely to schedule better. Use detailed access information to tune the schedule. Where it broke. Fine-grained, possibly secret-dependent profiling would itself become a side channel, reintroducing the leak the turns were meant to close.
The gap. No secure memory scheduler shed the worst-case read-or-write margin by specializing turns while keeping the profiling that drives it coarse enough not to leak.

How FlexProf works

Keeping the leak-free turn structure but specializing each turn

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

The idea

Close the channel by making one VM’s timing independent of the others. FlexProf keeps the foundational defense that its predecessors established: partition the memory controller into fixed turns with gaps, so what a neighbor does can never be read off your own request timing. Removing a shared-resource timing side channel by shaping the memory system so an observer’s measurements no longer depend on the victim is the same undertaking the work on mitigating memory timing side channels (DAGuise) covered elsewhere on this site pursues, cutting the dependence that made the channel possible. FlexProf inherits this leak-free turn structure and treats it as the fixed safety property to preserve, then attacks the cost it imposes.

Reclaim the performance a secure design gives up, without giving back the security. The whole point of FlexProf is that side-channel freedom need not cost 2 times performance; by specializing turns it recovers much of the lost throughput while keeping the guarantee intact. Redesigning a leak-free system so it is also high-performance, rather than accepting that safety must be slow, is the same balance the work on a principled framework for low-leakage, high-performance design (Untangle) covered elsewhere on this site strikes, refusing to treat the security tax as fixed. FlexProf does this specifically at the memory controller, turning the worst-case read-or-write margin into reclaimed bandwidth.

Isolate a shared resource in time, with just enough looseness to stay efficient. FlexProf’s turns-with-gaps are a temporal partitioning of the memory controller, and its opportunistic reads-in-write-turns are a controlled relaxation of that partitioning to avoid wasting slots. Isolating tenants by carving a contended resource into time slices with protective gaps, so use by one cannot bleed into another, is the same mechanism the work on blocking transient-execution attacks with core gapping (Sharing is Leaking) covered elsewhere on this site relies on, using temporal separation to stop cross-tenant leakage. FlexProf applies temporal partitioning to memory turns and then adds opportunistic flexibility so the partitioning does not leave throughput on the table.

Following a request stream through FlexProf

Serving a read-heavy VM under a secure, specialized schedule

An illustrative walkthrough, based on the paper's described mechanism (this explainer is written from the paper's abstract; exact details are in the full paper).

Step 1 of 5

The controller profiles the VM coarsely

Over a window, FlexProf measures roughly how read-heavy or write-heavy the VM is — an aggregate ratio, not a fine-grained trace. This coarse profile is safe to use because it does not reveal the secret-dependent access pattern a side channel would need.

Coarse profiling is what keeps the scheduling decision from leaking.

Why it works

Fixed turns with gaps break the cross-VM dependence. A shared controller leaks because timing depends on co-tenants → but giving each VM its own turns with safety gaps → so its timing depends only on itself and the side channel is closed.
Specialized turns shed the worst-case margin. A turn ready for either reads or writes must reserve conservative timing → but a turn that knows its role uses tight, read- or write-tuned timing → so the dead time behind much of the 2 times slowdown shrinks.
Coarse profiling picks the mix without leaking. Fine-grained profiling would itself be a side channel → but measuring only aggregate read-versus-write behavior → so the turn mix can adapt to the workload while staying safe.
Opportunistic issue keeps specialized turns busy. Committing a turn to one role risks wasting it when the other kind is pending → but letting a read turn slip in a write and vice versa → so utilization stays high despite the fixed roles.
The turn structure is untouched, so safety holds. Reclaiming throughput could reopen the leak if timing became co-tenant-dependent → but FlexProf changes only what happens inside a VM’s own turns → so the side-channel-free guarantee is preserved.

What it costs (trade-offs and scope)

It still pays for temporal partitioning. FlexProf reclaims a share of the lost performance but does not eliminate the cost of secure scheduling — the turns and gaps that provide safety still carry overhead relative to an insecure, fully shared controller; the win is measured against other secure schedulers, not against no defense.
The benefit depends on the workload’s read/write balance. The reported gains are on mixed workloads and are largest for memory-intensive programs (over half gain more than 10 percent); a workload whose read/write mix does not match well, or that is not memory-bound, will see smaller improvement.
Coarse profiling trades precision for safety. Keeping the profile coarse enough not to leak means the turn mix cannot track fast or fine-grained shifts in an application’s behavior, so the schedule is adapted at a granularity chosen for security rather than for maximum responsiveness.
It targets the memory-controller channel specifically. FlexProf addresses the shared memory controller; a secure processor must still defend the many other microarchitectural side channels (caches, ports, predictors) with their own mechanisms, and FlexProf does not by itself cover those.
Opportunistic flexibility is bounded by the security model. The relaxation that lets a turn do the other kind of request must be constrained so it never makes timing depend on another VM; this keeps the flexibility limited to what can be proven safe, not a free-for-all reordering.

The evaluation

Scheduling a shared memory controller across co-scheduled VMs

Property	Insecure shared scheduling	Turn-based secure scheduling	FlexProf
Memory-controller side channel
Each turn read-or-write handling
Profiling used to schedule
Slot utilization
Reported performance

A comparison of memory-controller scheduling options for co-scheduled VMs. By keeping the leak-free turn structure but specializing each turn into a read-optimized or write-optimized role, choosing the turn mix with coarse non-leaky profiling, and allowing opportunistic issue of the other request type, FlexProf reports up to 33 percent performance improvement (geometric-mean 8 percent on mixed workloads) over state-of-the-art secure schedulers, with over half of memory-intensive programs gaining more than 10 percent, while preserving the side-channel-free guarantee. This explainer is written from the paper's abstract; exact figures and mechanisms should be read from the paper.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

This explainer is written from the paper’s abstract (the full text was not accessible at the time of writing — the ASPLOS 2025 paper is open access under CC BY, but the copy was reachable only through a publisher page that could not be retrieved). The described system is the paper’s: FlexProf is a memory controller that defends against memory-controller side channels between co-scheduled VMs by keeping the established turn-based secure schedule (fixed turns per VM with gaps between them) while making each turn specialized rather than worst-case. It introduces a read-optimized turn and a write-optimized turn; coarse-grain application profiling determines how often each type is invoked without leaking sensitive information; and a read-optimized turn can opportunistically also issue writes and vice versa, balancing restriction against flexibility and throughput against utilization. The paper reports up to 33 percent performance improvement, a geometric-mean gain of 8 percent on mixed workloads relative to state-of-the-art methods, and that over half the memory-intensive programs evaluated gain more than 10 percent. The explanation of DRAM read/write asymmetry and bus turnaround given above is standard memory-systems background offered to make the “prepared for either reads or writes” worst case intuitive; the paper’s own account of why the worst-case margin arises, the exact turn structure, the profiling mechanism and its leakage argument, the opportunistic-issue rules, and the full evaluation (workloads, baselines, and security analysis) should be read from the paper. The step-by-step walkthrough above is illustrative, not a claim about the paper’s exact implementation.

Background

Why secure processors keep trading performance to close timing channels

It helps to see FlexProf within a broad pattern: microarchitectural side channels arise because the features that make hardware fast — sharing, contention, speculation, reordering — also make timing depend on secret-influenced behavior, and closing a channel almost always means giving some of that speed back. The recurring research question is not whether a channel can be closed (partitioning or serialization can usually close it) but how much of the lost performance can be reclaimed without reopening it. The answers tend to rhyme: isolate the shared resource, identify where the safe-but-slow design is being needlessly conservative, and buy back performance in exactly those places while proving the security property still holds. FlexProf is a clean instance — it keeps the leak-free turn schedule untouched and attacks only the worst-case read-or-write margin inside each turn, using profiling coarse enough to be safe. This effort to remove microarchitectural timing channels while limiting what they cost is the same terrain the work on avoiding instruction-centric microarchitectural timing channels covered elsewhere on this site occupies, chasing security and performance together rather than accepting one at the other’s expense. FlexProf’s contribution is to show that at the memory controller, a large part of the security tax was a worst-case assumption that specialization and a little safe flexibility can shed.

If you remember only three things

1. Co-scheduled VMs share the memory controller, and because request timing depends on what co-tenants do, an attacker VM can infer a victim VM's behavior — a memory-controller side channel. The established defense assigns each VM fixed scheduling turns with gaps between them, so its timing depends only on its own turn; this closes the channel but imposes about a 2 times slowdown. A key cause is that each turn must accommodate the worst case, being prepared to serve either reads or writes, which forces conservative timing margins (because DRAM reads and writes are asymmetric and switching the bus between them costs turnaround time) that waste throughput.
2. FlexProf keeps the leak-free turn structure but specializes each turn: it introduces a read-optimized turn and a write-optimized turn, so a turn that knows its role uses tight timing instead of worst-case margins. Coarse-grain application profiling sets how often each kind of turn runs, measuring only aggregate read-versus-write behavior so it does not leak the fine-grained, secret-dependent access pattern a side channel would exploit. And a read-optimized turn can opportunistically issue a write when it has room (and vice versa), so specialization does not waste slots — balancing restriction against flexibility and throughput against utilization, all without changing the turn structure that provides safety.
3. The paper reports FlexProf improves performance by up to 33 percent, with a geometric-mean gain of 8 percent on mixed workloads relative to state-of-the-art secure schedulers, and that over half the memory-intensive programs evaluated gain more than 10 percent, while preserving the side-channel-free guarantee. It reclaims part of the security tax rather than eliminating it: the gains are measured against other secure schedulers, depend on the workload's read/write balance and memory intensity, and address the memory-controller channel specifically (a secure processor must still defend other channels separately). This explainer is based on the abstract; full details are in the paper.

Check yourself

Check your understanding

1. How can one virtual machine spy on another through a shared memory controller?
2. The established defense assigns each VM fixed "turns" with gaps between them. Why does making this leak-free cost so much performance, according to the paper?
3. What is FlexProf's central idea for reclaiming performance while staying side-channel-free?
4. Why must FlexProf's application profiling be "coarse-grain," and what does it achieve?

Sources

The paper is “FlexProf: Flexible, Side-Channel-Free Memory Access” by Jarrett Minton and Rajeev Balasubramonian (University of Utah), published at ASPLOS 2025 (the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems), DOI 10.1145/3676641.3715997. It received a Distinguished Artifact Award. The paper is open access under CC BY.

This explainer is written from the paper’s abstract; the full text was not accessible at the time of writing (the open-access copy was reachable only through a publisher page that could not be retrieved, and no author-hosted copy or preprint was found). FlexProf is a memory controller that defends against memory-controller side channels between co-scheduled VMs by preserving the established turn-based secure schedule (fixed turns per VM with gaps between them) while making each turn specialized rather than worst-case: it introduces a read-optimized turn and a write-optimized turn, uses coarse-grain application profiling to decide how often each type is invoked without leaking sensitive information, and lets a read-optimized turn opportunistically issue writes and vice versa, balancing restriction against flexibility and throughput against utilization. The paper reports up to 33 percent performance improvement, a geometric-mean gain of 8 percent on mixed workloads relative to state-of-the-art methods, and that over half the memory-intensive programs evaluated gain more than 10 percent. The background on DRAM read/write asymmetry and bus turnaround is standard memory-systems context provided to make the worst-case description intuitive, not a claim about the paper’s specific implementation. Exact mechanisms, the leakage argument for the profiling, and full quantitative results should be confirmed in the paper.