Apa itu bug DRAM Rowhammer dan bagaimana saya harus mengobatinya?

Keripik DRAM sangat padat. Penelitian telah menunjukkan bahwa bit tetangga dapat dibalik secara acak.

• Berapa probabilitas bug yang dipicu secara acak dalam chip DRAM tingkat server dengan ECC ( kertas CMU-Intel mengutip misalnya angka 9.4x10 ^ -14 untuk chip yang tidak dikenal untuk satu kegagalan dalam satu tahun)?
• Bagaimana saya tahu apakah bug sudah diperbaiki sebelum membeli memori?
• Apa yang harus saya lakukan untuk melawan upaya jahat untuk meningkatkan hak istimewa oleh misalnya penyewa atau pengguna yang tidak berhak pada misalnya CentOS 7?

Referensi:

• Hammer Hammer DRAM Bug Dimanfaatkan, Membuka Kunci Akses ke Memori Fisik
• Membalik Bit dalam Memori Tanpa Mengaksesnya: Studi Eksperimental tentang Gangguan DRAM
• Repo PoC Google
• Penulisan proyek Zero

Kertas CMU-Intel yang Anda kutip menunjukkan (pada halaman 5) bahwa tingkat kesalahan sangat tergantung pada nomor bagian / tanggal pembuatan modul DRAM dan bervariasi dengan faktor 10-1000. Ada juga beberapa indikasi bahwa masalahnya jauh lebih sedikit diucapkan dalam chip yang diproduksi baru-baru ini (2014).

Angka '9.4x10 ^ -14' yang Anda kutip digunakan dalam konteks mekanisme mitigasi teoritis yang diusulkan yang disebut "PARA" (yang mungkin mirip dengan mekanisme mitigasi yang ada pTRR (pseudo Target Row Refresh)) dan tidak relevan dengan Anda pertanyaan, karena PARA tidak ada hubungannya dengan ECC.

Makalah CMU-Intel kedua (halaman 10) menyebutkan efek dari berbagai algoritma ECC pada pengurangan kesalahan (faktor 10 ^ 2 hingga 10 ^ 5, mungkin jauh lebih banyak dengan tes memori canggih dan "guardbanding").

ECC secara efektif mengubah Row Hammer mengeksploitasi menjadi serangan DOS. Kesalahan 1bit akan diperbaiki oleh ECC, dan segera setelah kesalahan 2bit yang tidak dapat diperbaiki terdeteksi, sistem akan berhenti (dengan asumsi ECC SECDED).

Solusinya adalah membeli perangkat keras yang mendukung pTRR atau TRR. Lihat posting blog saat ini dari Cisco tentang Row Hammer . Setidaknya beberapa produsen tampaknya memiliki salah satu dari mekanisme mitigasi ini yang tertanam dalam modul DRAM mereka, tetapi tetap tersembunyi dalam spesifikasi mereka. Untuk menjawab pertanyaan Anda: tanyakan pada vendor.

Kecepatan refresh yang lebih cepat (32ms daripada 64ms) dan interval Patrol Scrub yang agresif juga membantu, tetapi akan memiliki dampak kinerja. Tapi saya tidak tahu ada perangkat keras server yang benar-benar memungkinkan finetuning parameter ini.

Saya kira tidak banyak yang dapat Anda lakukan di sisi sistem operasi kecuali menghentikan proses yang mencurigakan dengan penggunaan cpu tinggi yang konstan dan kesalahan cache yang tinggi.

Situasinya tampaknya masih belum jelas sehingga saya tidak berpikir pertanyaan Anda dapat dijawab secara langsung, tetapi di sini ada informasi yang relatif baru sebagai jawaban parsial. Untuk berita, ikuti rowhammer-bahas mailing list.

Saya tidak yakin saat ini mungkin dengan informasi publik untuk menghindari membeli RAM yang rentan, atau untuk dengan mudah memprediksi tingkat kegagalan pada perangkat keras yang ada. Produsen belum terbuka dengan informasi tentang bagaimana produk mereka terpengaruh. Dimungkinkan untuk menguji memori yang telah dibeli menggunakan alat perangkat lunak, tetapi Anda harus menyadari bahwa menjalankan alat-alat itu untuk periode (jam) yang signifikan dapat secara permanen menurunkan RAM dan menyebabkan kesalahan dalam menjalankan perangkat lunak.

"Perusahaan memori yang tidak disebutkan namanya" dilaporkan telah berupaya membayar suap sebagai imbalan untuk Perangkat Lunak Passmark yang tidak merilis tes rowhammer dalam alat Memtest86 mereka.

Perangkat keras Intel Skylake telah dilaporkan lebih rentan, tidak kalah , untuk rowhammer karena penambahan penambahan clflushoptinstruksi baru . Ini sudah dieksploitasi di rowhammer.js

Daniel Gruss menjawab beberapa pertanyaan di sini tentang mitigasi per Desember 2015 (rekan penulis makalah rowhammer.js ) dalam ceramah ini :

1. Sementara beberapa RAM ECC kurang rentan dibandingkan dengan RAM non-ECC terhadap rowhammer, RAM ECC lainnya lebih rentan daripada RAM non-ECC ( tautan ke pertanyaan dalam video )
2. Beralih ke kecepatan refresh yang lebih cepat sudah cukup untuk mencegah rowhammer dengan sebagian besar tetapi tidak semua perangkat keras - tetapi tidak semua BIOS memungkinkan perubahan kecepatan refresh ( tautan ke pertanyaan dalam video ).

Sebagai tindakan balasan, dimungkinkan untuk mendeteksi serangan rowhammer yang sedang berlangsung, tetapi saya tidak tahu bahwa itu telah dilakukan.