Sigries: Questions & Answers

We have received several questions about Sigries, a Rowhammer defense designed at Microsoft and deployed in Azure Cobalt 200 SoC. I will answer four such questions in this article. These questions were asked during the presentation of our paper at ISCA or directly to us by email. If you want to learn more about Sigries, please refer to the original paper, which was published at ISCA 2026 (Industry Track).

Q1: The paper includes this statement "transitioning back to light mode is completely safe". This statement is not entirely correct, is it?

Sigries is not safe when transitioning from heavy mode back to light mode, despite the claim in the original paper. During this transition, Sigries is vulnerable for one refresh window.

This vulnerability exists because heavy mode does not necessarily sample every row that accumulates activations. Heavy mode is designed to sample aggressor rows whose number of activations approaches the Rowhammer threshold with very high probability. However, if a row receives fewer activations during one refresh window, it may remain unsampled. After the transition into light mode, this row may receive additional activations without being refreshed by the DRAM and still avoiding DRFM. The sum of the row activations in these two intervals could reach the Rowhammer threshold, yet no DRFM is issued.

We have identified two independent fixes for this vulnerability. The first requires a hardware logic change. When transitioning back to light mode, Sigries must run both heavy and light modes concurrently for one additional refresh window. Heavy mode is exited only after this additional window completes.

The second fix requires only a configuration change. As currently implemented, Sigries's exposure window is twice as large as claimed in the original paper: less than two hours per year. This exposure can be reduced back to less than one hour per year by doubling the minimum duration of heavy mode. The minimum heavy-mode duration is a configuration parameter.

We thank Moin Qureshi from Georgia Tech for pointing out that the original claim was incorrect. We added an Errata to our paper to correct this claim.

Q2: I am no Rowhammer attacker, but defenses are meant to be broken. Why publish a production-level defense in a research paper?

One of our goals in publishing Sigries was to inspire other hardware vendors to describe their Rowhammer defenses in detail. Why? Because security defenses work best when many eyes are looking at them. Security schemes that avoid scrutiny do not have a good track record. The DRAM industry has been very secretive about Rowhammer defenses with no good reason.

Sigries itself proves this point. In our original paper, we claimed that Sigries's transitions from heavy to light mode are completely safe. That claim was incorrect, as we explain in the answer to Q1 above. An external researcher (Moin Qureshi) was unencumbered by our assumptions and his fresh perspective allowed him to identify a vulnerability that we had overlooked. This is another example that demonstrates how security defenses benefit from external scrutiny.

Q3: Has Sigries taken into account differences between how DRAM parts actually behave and what the specification says? For example, what if the actual tREFW is not 32 ms? Could deviations like this affect Sigries' security guarantees?

Generally speaking, SoC-based defenses, such as Sigries, make many assumptions about DRAM parts, with no certainty that those assumptions are correct. One example is the assumption that each row in a DDR5 part is refreshed at least once every 32 ms. But there are many others. For example, we assume that DRFM refreshes the adjacent rows correctly according to the BRC setting. We assume that the same threshold applies to all DRAM rows. We also assume the absence of row-line coupling.

We encourage reserachers to investigate such assumptions because all host-based (SoC-based) Rowhammer defenses are vulnerable to them. Also, if DRAM vendors know about these assumptions being invalid, please reach out to us or to Microsoft.

Q4:You could build a better implementation of the light mode that does not require Misra-Gries or CAMs. Just use counters.

We never claimed that Sigries's light mode is an optimal design. However, all other designs we have seen or heard about come with different trade-offs, and we have not seen one that is strictly better. Using counters alone is often done by mapping multiple rows to the same counter. Such designs do not have a clear way to perform mitigation. One option is to issue DRFM to all rows mapped to the same counter, but this is very expensive and violates our requirement #2 (see the Sigries paper). Another option is to avoid waiting for the counter to reach the threshold and instead exit light mode early. In our experience, this is not a good trade-off because it can cause many commodity workloads to exit light mode too quickly.


Thanks to Alec Wolman for reading drafts of this document.
August 20th, 2026