Skip to content

SledgeHammer

Birçok DRAM bank'ını paralel olarak hammer'layarak Rowhammer'ı güçlendirmek; bu hem activation'ları paralelleştirir hem de memory subsystem'in aynı adrese yapılan tekrarlı okumaları reorder etmesini engeller.

Mechanism

Note

DRAM bank'ları bağımsızdır ve farklı bank'lara erişimler paralel olarak servis edilir, oysa single-bank hammering erişimleri serileştirir ve bandwidth israf eder. SledgeHammer, hammering'i bir kerede birçok bank arasında interleave eder. Belirlediği daha derin kök neden şudur: okumaları bank'lar arasında interleave etmek, memory subsystem'in aynı adrese yapılan tekrarlı okumaları reorder etmesini engeller, böylece birçok row activate edilirken ACT-to-ACT latency'sini düşük tutar. Bu, serileştirmeyen clflushopt'u gerektirir (DDR4 dönemi Intel'de mevcuttur); düz clflush serileştirir ve faydayı ortadan kaldırır, DDR3'ün hiç kazanç görmemesinin nedeni de budur.

Fayda az sayıda bank'ta (genellikle 2–4 civarında) zirve yapar ve sonra daha fazla bank ile toplam ACT-to-ACT süresi yeniden yükseldikçe azalır.

Native vs. browser/JS varyantı

Yukarıdaki mekanizma native (unprivileged user-mode) clflushopt'a dayanır. Sandbox'lı bir JavaScript ortamı bu instruction'ı doğrudan emit edemez; orada explicit flush'ın yerini bir self-evicting erişim pattern'ı alır (cache set'lerini eviction ile boşaltarak aggressor'ları tekrar DRAM'den okumaya zorlar; bkz. SMASH). Bank-level parallelism içgörüsü değişmez, yalnızca aynı adrese yapılan okumaları serileştirmeden temizleme yöntemi farklıdır — raporlanan tarayıcı sonuçları bu self-evicting varyanta aittir.

Walkthrough

Hammer loop'u, birden çok bank'a yayılmış aggressor'ları okur ve flush'lar serileşmesin diye clflushopt ile flush eder:

// aggressors[b][i] : aggressor rows in bank b
for (;;) {
    for (int b = 0; b < NBANKS; b++)
        for (int i = 0; i < NAGG; i++)
            *(volatile char *)aggressors[b][i];   // read across banks
    for (int b = 0; b < NBANKS; b++)
        for (int i = 0; i < NAGG; i++)
            clflushopt(aggressors[b][i]);          // non-serializing flush
    mfence();
}
Raporlanan sonuçlar
  • ~7x'e kadar daha fazla "flippyness" (≈7.32x ortalama; i7-6700'de 13.1x'e kadar), 1 bank'tan 2 bank'a geçerken zirve yapar.
  • DDR4: bank'lar 1->6 arası taranır, 10-sided hammering ile raw flip'lerde ~5.8x artış 4 bank civarında zirve yapar; pattern'lar 3-/10-/19-sided.
  • Intel 12. nesil Alder Lake'te (i7-12700K) ilk raporlanan flip'ler; burada single-bank hammering sıfır üretmişti; en iyi pattern ~8K bit/saat.
  • Tarayıcı (Chrome & Firefox, THP yok): self-evicting multi-bank pattern artı timing-tabanlı contiguous-physical-address tespiti; ilk flip ortalama ~20 saniyede; ~169 bit/saate kadar; Firefox'ta bir 64-bit write primitive'i gösterildi.

Mitigation

Erişim paralelliğinden bağımsız olarak disturbance'ı sınırlandıran controller seviyesinde refresh management kalıcı çözümdür. Bank-paralel hammering'in yalnızca single-bank activation oranlarını profilleyen savunmaları aşabileceğini unutmayın.

References