Rowhammer defenses face an awkward choice. Precise tracking requires large associative tables in the memory controller, while probabilistic row sampling consumes DRAM bandwidth even when the server is not under attack. Microsoft’s Sigries, implemented in Azure Cobalt 200, combines both and changes mode at sub-bank granularity[1].
The operational question is whether the defense can preserve worst-case protection without charging every memory access for that worst case. This review follows how Sigries detects local pressure, changes tracking modes, and bounds its overhead, while keeping the reported Azure implementation separate from protection guarantees that depend on DRAM-specific thresholds.
A small table acts as gatekeeper
In light mode, each sub-bank uses a Misra-Gries counter table with no more than a few dozen entries. Benign access streams and some attacks fit within that undersized table. When its spill behavior indicates that tracking is overwhelmed, only the affected sub-bank enters heavy mode and uses row sampling. Other sub-banks continue counting, so attack overhead remains spatially limited.
Trace-driven evaluation reports that every tested commodity workload stayed in light mode and added no DRAM bandwidth traffic. Area and power are described as minimal because the tables are small and use low-power state. Under attacks that overflow the table, sampling introduces a bounded cost rather than silently losing protection.
Rowhammer turns access history into a security boundary
Repeated activations of DRAM rows can disturb neighboring cells and cause bit flips without a conventional write to the victim. The activation threshold depends on device generation, temperature, refresh, and access pattern. A memory controller defense must therefore track enough recent activity to refresh potential victims before a dangerous count accumulates.[1]
The difficult word is “enough.” Tracking every row exactly needs large fast state near each controller. Sampling a small fraction of activations saves SRAM but creates memory traffic and probabilistic coverage. A cloud SoC must protect many DIMMs continuously, including periods with no attack, while preserving the memory bandwidth promised to tenants.
Security also needs a declared threshold contract. The controller threshold must remain below the vulnerable device’s tested Rowhammer limit with margin for uncertainty and implementation delay. DIMM qualification, temperature policy, refresh settings, and field updates belong to the same defense even though Sigries focuses on controller tracking.
Sub-bank scope limits both state and escalation
Sigries partitions tracking by DRAM sub-bank rather than using one global table. Ordinary traffic in one region cannot fill the counters of an unrelated region, and an attack concentrated in one sub-bank triggers heavier protection only there. This spatial boundary keeps the benign cost local and makes provisioned state scale with memory organization.
The mapping must match the physical address-to-DRAM function. Channels, ranks, banks, sub-banks, rows, and address interleaving determine which activations can affect a victim. If firmware or memory configuration changes that mapping, the defense parameters must change with it. A logical table attached to the wrong physical scope can report precise counts for the wrong neighbors.
Per-sub-bank escalation also affects fairness. An attacker can force sampling traffic in its region, but the memory controller still shares command and data resources across tenants. The bounded heavy-mode overhead needs to include interference outside the attacked sub-bank, not only additional refreshes within it.
Misra-Gries is a gate, not an exact ledger
The Misra-Gries heavy-hitter algorithm keeps a small set of candidate rows and approximate counts. When a tracked row appears, its counter increases. When the table cannot admit a new row, the update rule reduces counters or records spill behavior, preserving a guarantee that sufficiently frequent items cannot remain invisible. Sigries uses this property to decide whether light mode remains safe.
An undersized table is intentional. Benign locality and simpler attacks can be represented with a few dozen entries. A pattern that spreads activations across many rows stresses the table and provides evidence that exact-enough light tracking is no longer appropriate. The defense then switches the affected sub-bank to sampling rather than continuing with counters whose guarantee would be insufficient.
Approximate tracking does not mean approximate security without a bound. The counter size, number of entries, refresh window, and transition rule must be selected so a row cannot reach the device threshold before either being identified or causing escalation. Formal reasoning about the worst sequence matters more than average hit rate.
Heavy mode spends bandwidth where the adversary is active
Sampling accesses or rows in heavy mode avoids maintaining a full exact table under a diffuse attack. It adds DRAM activity and can require preventive refreshes, but only the sub-bank whose light-mode evidence crossed the trigger pays that cost. Other regions continue with counter-only tracking.
The overhead is adversary controlled within a bound. This is preferable to a defense whose storage silently overflows, but the bound must be part of system capacity planning. An attacker may sustain heavy mode or alternate among sub-banks to increase memory-controller work. Rate limits and admission policy may be needed when one tenant intentionally consumes the defense budget.
Performance reports should include worst-case attack bandwidth, latency impact on unrelated traffic, and recovery time after the attack stops. Benign traces showing zero added DRAM traffic establish the common case; they do not establish the adversarial ceiling.
Zero benign bandwidth is a specific achievement
Many probabilistic defenses sample memory traffic continuously. Even a small fraction becomes material across a server fleet and can reduce useful bandwidth for applications that never encounter an attack. Sigries’ light mode updates controller-local counters and, in the evaluated commodity traces, did not generate added DRAM commands.
That result depends on the trace set and table sizing. A legitimate workload with unusually broad, high-rate row activity could enter heavy mode even without malicious intent. In-memory analytics, stress tests, accelerators sharing memory, or future access patterns should be included in deployment qualification. A false escalation affects performance but should not weaken security.
Area and power also require configuration context. A few dozen entries per sub-bank multiplied across channels and controllers can still create significant state. Low-leakage implementation and access frequency determine power. The comparison should use total controller overhead for the supported memory capacity, not one table in isolation.
The mode-transition erratum closes a temporal gap
Leaving heavy mode is as security-critical as entering it. The original design could reset or hand off tracking in a way that overlooked activations accumulated across the boundary. A row that was below the response point in each mode separately could remain dangerous when the two intervals were combined.
The correction overlaps heavy and light tracking for another refresh interval before heavy mode is retired. This preserves history while the counter path becomes authoritative. The extra interval costs some bandwidth, but it prevents the controller from treating a transition as if the DRAM disturbance state had reset.
This error class is common in stateful security hardware. Each mode can be safe in isolation while the transfer of responsibility is unsafe. Verification must cover entry, exit, reset, refresh, power management, error recovery, and concurrent events. Publishing the erratum makes the deployable contract clearer and should trigger a review of RTL and firmware versions.
Formal verification should target adversarial sequences
Random testing is unlikely to find the exact sequence that straddles a mode transition or distributes activations to maximize counter error. Properties should state that no physical row can exceed the protected activation bound without a preventive action, across all table states and transition timings.
The model needs realistic DRAM timing and refresh behavior, including postponed commands and controller queues. Address remapping and repair rows can change physical adjacency. Parameters supplied by firmware should be included in the proof range so an invalid configuration cannot satisfy the RTL property under different assumptions.
Runtime telemetry can complement proof. Controllers can count light-to-heavy transitions, time spent in heavy mode, preventive refreshes, and threshold-margin events without exposing raw tenant addresses. Unexpected patterns can identify benign false positives, attacks, or a mismatch between deployed DIMMs and configured limits.
Fleet deployment needs versioned memory knowledge
Rowhammer susceptibility varies across DIMM models and revisions. Qualification should determine conservative thresholds over temperature, aging, and access patterns. The controller configuration must follow the installed memory, and inventory systems need to prevent an unsupported module from receiving a weaker profile.
Firmware updates should be atomic and recoverable. Changing a threshold or mode rule while counters are active can create another transition gap. A safe update can drain traffic, retain state, or conservatively force heavy mode until the new configuration is established. Rollback must not restore parameters incompatible with the current DIMM population.
Operators also need incident semantics. A heavy-mode event may be a benign workload, an attempted attack, or a marginal device. Correlating events by tenant and module while protecting privacy allows rate limiting, hardware replacement, or security investigation to follow the correct cause.
What the evaluation establishes
Implementation in Azure Cobalt 200 moves the work beyond a simulator-only proposal. Commodity traces remaining in light mode support the claim that normal traffic does not pay DRAM bandwidth for sampling. The small state and selective escalation make fleet deployment plausible.
The result does not prove that every future workload remains light or that every DRAM device is protected by one threshold. Attack overhead and hardware area should be read with the evaluated controller and memory configuration. The published erratum also means readers must distinguish the corrected algorithm from any earlier description or implementation.
The broader evidence is architectural: approximate heavy-hitter tracking can serve as a cheap detector that activates a more expensive probabilistic mechanism only where necessary, provided the handoff itself is formally protected.
What operators should ask
Procurement and security review should request the DIMM qualification method, protected activation threshold and margin, address mapping, state per supported capacity, benign and adversarial bandwidth, transition proof, and firmware update path. They should confirm that error-correction and Rowhammer refresh actions do not conflict.
Monitoring should expose escalation rates and controller overhead without giving tenants a side channel into other memory activity. Service-level tests should run benign high-bandwidth applications beside an attacking tenant to measure isolation. Finally, the deployed revision must include the overlap correction described by the erratum.
Defense parameters should fail closed
If the controller cannot identify the installed memory profile, loses counter state, detects corrupted configuration, or receives an unsupported firmware update, it needs a conservative behavior. Entering heavy mode, lowering thresholds, or taking the affected memory offline can cost performance but preserves the security contract. Continuing with an unknown light-mode guarantee would fail open.
Reset and low-power states deserve special attention. DRAM disturbance history and controller counters may not share the same lifetime. A suspend, controller reset, or hot-replacement sequence must either preserve the relevant state or force enough refresh and conservative tracking to reestablish the invariant. The published transition bug shows why administrative state changes belong in the threat model.
Configuration should be authenticated and rollback protected where weaker historical settings would expose newer DIMMs. Fleet inventory can tie each controller revision, DIMM profile, threshold, and erratum status to attestation or compliance records. This turns an algorithmic defense into an auditable operational control.
Availability attacks remain in scope
A defense can prevent bit flips while allowing an attacker to consume refresh and memory bandwidth. Selective heavy mode bounds the spatial impact, but sustained escalation may still lower service quality. The platform should meter defense-induced work by tenant or protection domain when attribution is reliable, then apply rate limits or isolation without revealing physical address details.
The policy must not weaken protection for availability. If a tenant exhausts a budget, the safe response is throttling or removal, not ignoring suspicious activations. Measurements should include the worst sustainable attack, recovery after throttling, and latency of innocent workloads sharing controller resources.
This distinction completes the security claim: Sigries aims to maintain integrity under Rowhammer and to keep the cost manageable. It does not make adversarial memory activity free.
Evaluation should therefore report two service levels. The integrity service level states the protected activation threshold and response guarantee; the availability service level states the maximum additional latency and bandwidth consumption under a bounded attacker. Keeping them separate prevents a low average overhead from being mistaken for resistance to denial of service.
Fleet learning should feed back into qualification. If telemetry finds benign patterns that escalate often, engineers can adjust table sizing or mapping only after proving the security invariant remains intact. If one DIMM population approaches margin more frequently, its threshold should become more conservative rather than averaged with stronger devices. This preserves per-device safety margins. It also prevents fleet averages from concealing the weakest deployed memory population.
The erratum matters
The public paper includes an erratum. The original transition from heavy back to light mode could miss a row whose count remained dangerous across the boundary. The correction overlaps the two modes through another refresh interval before leaving heavy mode. This is not a footnote to hide: it illustrates why production security hardware needs formal verification, conservative recovery, and a patchable configuration contract.
What we take from it
Sigries moves the design target from the lowest average overhead to predictable behavior in both benign and adversarial regimes. Its most transferable idea is selective escalation: use cheap tracking as a gate, then spend bandwidth only where evidence demands it. The erratum also improves the paper’s operational value by showing the boundary condition that verification and deployment must preserve.
A defense policy needs observable costs
Selective Rowhammer defense is useful because it avoids paying the strongest mitigation cost everywhere. That selectivity also creates an operating obligation: the system must expose which sub-banks entered the protected state, how long they remained there, what evidence triggered the transition, and how much refresh or access delay the transition added. Without this telemetry, operators cannot distinguish a successful defense from a threshold that quietly degrades a subset of workloads.
Validation should combine attack-oriented testing with ordinary memory stress. Controlled aggressor patterns test coverage near the intended threshold, while long production traces reveal false activation under hot rows, skewed allocation, temperature changes, and aging. Firmware updates and new DRAM lots should repeat the qualification because the safe threshold belongs to the implemented memory system, not to the policy name alone. A cloud buyer should require both the protected operating range and the measured performance and energy cost within that range.
Source and attribution
This independent digest uses original wording and an original conceptual plate. It reproduces no paper figure, table, or prose. Microsoft Research publicly provides the paper with its erratum; the proceedings version is © IEEE 2026.