Bài báo CMU-Intel mà bạn đã trích dẫn cho thấy (trên trang 5) rằng tỷ lệ lỗi phụ thuộc nhiều vào số phần / ngày sản xuất của mô-đun DRAM và thay đổi theo hệ số 10-1000. Cũng có một số dấu hiệu cho thấy vấn đề ít được phát hiện trong các chip sản xuất gần đây (2014).
Số '9,4x10 ^ -14' mà bạn đã trích dẫn đã được sử dụng trong bối cảnh cơ chế giảm thiểu lý thuyết được đề xuất có tên là "PARA" (có thể tương tự như cơ chế giảm thiểu hiện tại pTRR (giả danh hàng làm mới)) và không liên quan đến bạn câu hỏi, bởi vì PARA không liên quan gì đến ECC.
Một bài báo CMU-Intel thứ hai (trang 10) đề cập đến tác động của các thuật toán ECC khác nhau trong việc giảm lỗi (hệ số 10 ^ 2 đến 10 ^ 5, có thể nhiều hơn nữa với các bài kiểm tra bộ nhớ tinh vi và "bảo vệ").
ECC thực sự biến việc khai thác Row Hammer thành một cuộc tấn công DOS. Lỗi 1bit sẽ được ECC sửa chữa và ngay khi phát hiện ra lỗi 2bit không thể sửa được, hệ thống sẽ tạm dừng (giả sử ECDED SECCED).
Một giải pháp là mua phần cứng hỗ trợ pTRR hoặc TRR. Xem bài đăng blog hiện tại từ Cisco về Row Hammer . Ít nhất một số nhà sản xuất dường như có một trong những cơ chế giảm thiểu này được tích hợp trong các mô-đun DRAM của họ, nhưng giữ nó ẩn sâu trong thông số kỹ thuật của họ. Để trả lời câu hỏi của bạn: hãy hỏi nhà cung cấp.
Tốc độ làm mới nhanh hơn (32ms thay vì 64ms) và các khoảng thời gian Patrol Scrub tích cực cũng giúp ích, nhưng sẽ có tác động đến hiệu suất. Nhưng tôi không biết bất kỳ phần cứng máy chủ nào thực sự cho phép hoàn thiện các tham số này.
Tôi đoán rằng bạn không thể làm được gì nhiều ở phía hệ điều hành ngoại trừ việc chấm dứt các quá trình đáng ngờ với việc sử dụng cpu cao liên tục và lỗi bộ nhớ cache cao.