Lỗi DRAM Rowhammer là gì và tôi nên xử lý nó như thế nào?


20

Chip DRAM được đóng gói rất chặt chẽ. Nghiên cứu đã chỉ ra rằng các bit lân cận có thể được lật ngẫu nhiên.

  • Xác suất xảy ra lỗi ngẫu nhiên trong chip DRAM cấp máy chủ có ECC (giấy CMU-Intel trích dẫn, ví dụ số 9,4x10 ^ -14 cho một chip không xác định trong một lần thất bại trong một năm)?
  • Làm thế nào để tôi biết liệu lỗi đã được sửa trước khi mua bộ nhớ?
  • Tôi nên làm gì để chống lại các nỗ lực độc hại để thực hiện leo thang đặc quyền bằng ví dụ: người thuê hoặc người dùng không có đặc quyền trên ví dụ như CentOS 7?

Tài liệu tham khảo:


2
Cho rằng các chi tiết về việc khai thác vẫn chưa bị cấm vận, tôi không chắc sẽ có nhiều thông tin có sẵn ngoài những gì Google đã cung cấp cho bạn.
fukawi2

Theo tôi hiểu, tốc độ làm mới bộ nhớ làm giảm đáng kể tỷ lệ lật bit thành công và các phiên bản BIOS mới hơn đã giảm tốc độ làm mới để thử và giảm thiểu rủi ro. Vì vậy, cập nhật BIOS của bạn có thể là một bước đầu tốt?
Tái lập

1
@ fukawi2, những chi tiết nào của việc khai thác đã / bị cấm vận? Mã đầy đủ cho các khai thác bằng chứng khái niệm đã được phát hành cùng với bài đăng trên blog.
Mark Seaborn

@MarkSeaborn Bây giờ tôi thậm chí không nhớ, đây là 3 tháng trước và tôi chỉ có thể nhớ bữa sáng.
fukawi2

Câu trả lời:


19

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.


4

Tình hình có vẻ vẫn chưa rõ ràng nên tôi không nghĩ câu hỏi của bạn có thể được trả lời trực tiếp, nhưng đây là một số thông tin tương đối gần đây như một câu trả lời một phần. Đối với tin tức, theo dõi danh sách gửi thư thảo luận chèo .

Tôi không chắc chắn hiện tại có thể có thông tin công khai để tránh mua RAM dễ bị tổn thương, cũng như không dễ dàng dự đoán tỷ lệ thất bại trong phần cứng hiện có. Các nhà sản xuất đã không cởi mở với thông tin về cách sản phẩm của họ bị ảnh hưởng. Có thể kiểm tra bộ nhớ đã mua bằng các công cụ phần mềm, nhưng bạn nên lưu ý rằng việc chạy các công cụ đó trong thời gian đáng kể (giờ) có thể làm giảm vĩnh viễn RAM và gây ra lỗi khi chạy phần mềm.

"Các công ty bộ nhớ không tên" được cho là đã cố gắng trả tiền hối lộ để đổi lấy Phần mềm Passmark không phát hành bài kiểm tra búa trong công cụ Memtest86 của họ.

Phần cứng Intel Skylake đã được báo cáo là dễ bị tổn thương hơn, không ít hơn , đối với người chèo thuyền vì việc bổ sung một clflushopthướng dẫn mới . Điều này đã được khai thác trong rowhammer.js

Daniel Gruss trả lời một số câu hỏi ở đây về giảm thiểu kể từ tháng 12 năm 2015 (đồng tác giả của bài báo rowhammer.js ) trong bài nói chuyện này :

  1. Mặc dù một số RAM ECC ít bị tổn thương hơn so với RAM không phải ECC đối với máy chèo thuyền, RAM ECC khác dễ bị tổn thương hơn RAM không ECC ( liên kết đến câu hỏi trong video )
  2. Chuyển sang tốc độ làm mới nhanh hơn là đủ để ngăn chặn rowhammer với hầu hết nhưng không phải tất cả phần cứng - nhưng không phải tất cả các BIOS đều cho phép thay đổi tốc độ làm mới ( liên kết đến câu hỏi trong video ).

Như một biện pháp đối phó, có thể phát hiện ra các cuộc tấn công của Rowhammer, nhưng tôi không biết rằng điều đó đã được thực hiện.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.