自宅/オフィスのコンピューターをロウハンマーからどのように保護できますか？
行ハンマーはECCメモリへの影響が少ないようですが、 ECCはまだ影響を受けません 。 ANVILのようなソフトウェアの緩和策について聞いたことがありますが、それも 100％行ハンマープルーフではないようです のどちらかです。
行ハンマー攻撃から私を確実に保護できるソフトウェアまたはハードウェアはどれですか？
特定の種類のDDR4メモリには、ビットフリップに対して確実に機能する組み込み保護機能があり、行ハンマーから保護する必要があるというヒントが1つ見つかりました。しかし、私はそれを完全に理解しているわけではなく、この保護がどれほど信頼できるべきかについても確信がありません。これは信頼できる形式の保護でしょうか？ A 引用 ：
高速Intel Skylakeベースのシステムの購入に加えて、4つのCrucial Ballistix Sport 2400 MHz、2つのCrucial Ballistix Elite 2666 MHZ、2つのGeil Super Luce 2400 MHz、2つのG.Skill Ripjaws 4 3200 MHz、2つのMicronブランドの2133 MHzも取得しましたテスト用のDDR4メモリモジュール…テストした12個のメモリモジュールのうち、8個は4時間の実験中にビットフリップを示しました。これらの8つの障害のうち、デフォルト設定で障害が発生したすべてのメモリモジュールは、Micronが製造したDDR4シリコン上にありました。Geilブランドのモジュールには、SK HynixとGスキルモジュールにはSamsungシリコンが含まれていました。
Edit：他の質問では、MicronがDDR4チップに特別な保護を組み込んでいると述べられています。しかし、SamsungとSK Hynixもそれを行っていると思います。明らかに（上記を参照）、Micronの保護は十分ではありませんでした。
DDR2を搭載したマザーボードへのダウングレードを含まない唯一の信頼できるハードウェアの緩和策は、TRR（ターゲット行のリフレッシュ）をサポートするメモリを使用することです。これは LPDDR4 のオプションです（DDR4とは異なります）。残念ながら、多くのDDR4モジュールはTRRをサポートしておらず、 digging deep なしでサポートされているかどうかを判別する簡単な方法がないことがよくあります。一部のIvy Bridgeプロセッサが持っているDDR3用の pTRR （Pseudo-TRR）もあります。 pTRR互換のDIMMを使用する必要があります。オンラインで利用できる実装や仕様に関する情報がほとんどないため、これがどれほど効果的で信頼できるかわかりません。それ以外にも、感受性を減らすいくつかのテクニックがあります：
MCEでECCを使用してパニックを起こす-違反でパニックを起こすようにコンピューターを構成した場合（ （マシンチェックの例外 、またはMCE）、それは長い道のりを行くことができます。最初に検出されたエラーの結果としてシステムが停止した場合、攻撃者はシステムを悪用するのにはるかに困難な時間を費やすことになります。高いスクラブレートは検出を改善します。
リフレッシュレートを上げます* -デフォルトでは、メモリは64ms間隔で更新されます。一部のBIOSでは、更新間隔を指定できます。これを32msに減らすと、パフォーマンスとエネルギー使用量を犠牲にして、ロウハンマーを悪用することがより困難になります。それを減らすとさらに効果がありますが、パフォーマンスへの影響はさらに大きくなります。 Rowhammer軽減設定（オプションまたはデフォルトで有効）があると主張する一部のBIOSベンダーは、リフレッシュ間隔を単に32msに短縮しています。
クロック速度を下げる* -すべてのコアの最大クロック速度を下げると、メモリアクセスは当然クロック速度に制限されるため、高速でメモリの行にアクセスすることが難しくなります。この緩和策は、境界線の脆弱性があり、高価格（大幅にパフォーマンスが低下）のメモリに対してのみ機能します。ハイパースレッディングまたは他の形式の [〜＃〜] smt [〜＃〜] を無効にして、シングルコアを使用するように切り替えることもでき、パフォーマンスに大きな影響を与えます。
CPUとRAMリソース制限を設定します）* -Rowhammerは、多くのCPU時間を消費するハンマーメモリを必要とします。悪意のあるプロセスが大量のメモリを割り当てることができる場合、一部の特権攻撃はさらに速く動作します。厳密な リソース制限 を設定して、CPUまたはメモリを過度に使用しているプロセスを強制終了すると、境界に脆弱なメモリモジュールを使用しているときに攻撃が遅くなる可能性があります。
WebブラウザーでJITを無効にする-JIT、つまりジャストインタイムコンパイルは、JavaScriptを実行可能コードにコンパイルするブラウザーで使用される最適化機能です。これにより、Webページ上の重いスクリプトが大幅にスピードアップします。ただし、これにより ブラウザからのロウハンマー も可能になります。 JITを無効にすると、JavaScriptのパフォーマンスが十分に低下するため、この攻撃は実行不可能になります。この緩和策のみは、他のローカルプロセスではなく、ブラウザの脆弱性を低減することに注意してください。
高MACでメモリを使用する-最大アクティブ化カウント、またはMACは、DRAMの測定値で、DRAM内の行に対して発生する可能性のあるアクセス数をカウントします不安定になる前の単一のリフレッシュ間隔。 MACは高いほど良く、無制限のMACが理想的です。無制限のMACを備えたモジュールは、理論的には、ロウハンマーに対して脆弱ではありません。特定のモデルのMACを見つけるためにデータシートを検索するか、または [〜＃〜] spd [〜＃〜] を介してデータを取得する必要があります。また、報告されたMAC値が常に正確であるとは限らないため、モジュールが安全であることを確認するためにモジュールをテストする必要もあります。
ブラックリストの脆弱なアドレス-x86 CPUの特別な機能は e82 で、これにはCPUが使用する物理メモリアドレスのリストが含まれます仮想メモリへのマップを非表示にして拒否します。これを、rowhammerが通常同じ行に繰り返し影響するという事実（つまり、特定のモジュールに影響を受けやすい行があり、影響を受けにくい行がある）と組み合わせると、これらの脆弱なアドレスを見つけてブラックリストに登録することは理にかなっています。これは B-CATT が採用するアプローチです。
メモリを物理的に分割する-異なるセキュリティレベルのプロセスが隣接する行にマップされないようにメモリを分割できる場合、行ハンマーベースの破損を分離できます。これは、仮想マシンにメモリを割り当てるとき、またはメモリをセグメント化して、ユーザーとカーネルの物理メモリ領域（「上位」のカーネルだけではない）を分割するときに役立ちます。
rowhammer-discuss には、ロウハンマーに関連する多くの質問と議論があります。
*単独では、これらの緩和策はほとんど効果がなく、多くの状況でビットフリップのレートをわずかしか低下させることができません。