Skip to content

Cache Partitioning or Flush Rule

Isolation rule — instantiates Side-Channel Leakage Containment

Partitions or scrubs shared hardware state between security domains so one tenant's access pattern can't be read off another's timing.

When two security domains share microarchitectural state — CPU cache, TLB, branch predictors, buffers — the occupancy of that state is observable through timing, so one domain's activity leaks into another's latency even when no data is shared. Cache Partitioning or Flush Rule closes that channel at the resource layer: it either partitions the shared state so each domain gets a disjoint slice (spatial isolation) or flushes it at every domain switch so no residue survives the crossing (temporal isolation). Its defining move is to act below the application, on the shared substrate itself — the leak isn't in any output, it's in the physics of a shared cache, so the fix lives there too.

Example

Two cloud customers' virtual machines are scheduled on the same physical core and share its last-level cache. Because eviction timing reveals which cache lines were recently touched, one tenant's memory-access rhythm is faintly visible to the other. The host applies both moves: it assigns each tenant a dedicated set of cache ways (partition), so neither can evict the other's lines, and it flushes shared buffers on every context switch across the tenant boundary (flush), so nothing carries over. The co-tenant now measures only its own cache state; the neighbor's access pattern — the protected fact — is no longer observable. These are established techniques such as way-partitioning and page coloring.[1]

How it works

  • Bind domains to disjoint slices. Allocate separate cache ways / sets / pages per security domain so occupancy can't cross the boundary.
  • Scrub on crossing. Flush or overwrite shared state at each domain switch, so no residue of the previous domain remains observable.
  • Enforce below the app. The isolation is implemented in hardware or the OS/hypervisor, where the shared resource actually lives, not in application code.

Tuning parameters

  • Partition granularity — ways vs. sets vs. pages; finer isolation closes more but sacrifices usable cache capacity.
  • Flush scope — full flush vs. targeted scrub of only the security-relevant lines; thorough is safer, targeted is cheaper.
  • Switch trigger — flush on every context switch vs. only on cross-domain switches; the latter cuts overhead but must correctly identify domain boundaries.
  • Static vs. dynamic partition — fixed per-tenant allocation vs. adaptive sizing; fixed is predictable, dynamic reclaims idle capacity.

When it helps, and when it misleads

Its strength is neutralizing co-tenant and microarchitectural timing channels that no application-level control can reach. Its cost is real performance and capacity loss — a partitioned cache is a smaller cache. The classic misuse is declaring victory after isolating one resource while the prefetcher, TLB, memory bus, or a shared functional unit remains a channel — the leak simply relocates. The discipline is to enumerate every shared resource before claiming isolation, which is why this rule depends on a complete channel map rather than a hunch.[1]

How it implements the components

  • shared_resource_isolation_boundary — the partition or flush boundary is precisely this component: the enforced line across which one domain's shared-resource state cannot be observed by another.

It implements only that isolation boundary. Making the request *timeline independent of the secret is Secret-Independent Resource Scheduling's job, and enumerating which resources are even shared is the Side-Channel Inventory Workshop's map — this rule isolates the state, it does not schedule or discover.*

Notes

Isolating one resource is not isolating the system: microarchitectural channels are plural, and closing the cache while leaving the branch predictor or memory bus open just moves the leak. Treat this rule as one entry in a per-resource isolation program, scoped by the channel inventory, not a standalone fix.

References

[1] Cache partitioning and flush-on-switch — isolating or scrubbing shared microarchitectural state (cache ways, TLB, buffers) at security-domain boundaries so occupancy patterns aren't observable across domains. Way-partitioning and page coloring are long-standing implementations of the idea. ↩