Rust trong nhân Linux: hết thử nghiệm, Rust ở lại lâu dài

Nhân Linux có hơn ba thập kỷ code C, chạy trên hàng tỷ thiết bị, và phần lớn lỗ hổng nghiêm trọng của nó vẫn thuộc loại quen thuộc: tràn bộ đệm, use-after-free, data race. Năm 2022, Rust được đưa vào nhân dưới dạng "thử nghiệm". Tháng 12/2025, tại Kernel Maintainers Summit ở Tokyo, thử nghiệm đó được tuyên bố kết thúc. Người dẫn dắt dự án Rust for Linux, Miguel Ojeda, viết: "the experiment is done, i.e. Rust is here to stay". Bài này giải thích Rust được ghép vào nhân thế nào, đã chạy ở đâu, và lỗ hổng Rust đầu tiên của nhân dạy ta điều gì.

Kiến trúc: bindings, abstractions và driver

Rust trong nhân không viết lại phần lõi C. Nó được xếp thành ba tầng, theo tài liệu chính thức của nhân:

Quy tắc cuối là mấu chốt. Nếu abstractions đúng đắn và mọi khối unsafe tuân thủ hợp đồng an toàn của nó, thì code driver dùng abstractions không thể gây ra undefined behavior. Phần nguy hiểm được dồn vào một chỗ nhỏ, được review kỹ, thay vì rải khắp hàng nghìn driver.

Rust đã chạy ở đâu trong thực tế?

• Android 16: thiết bị dùng nhân 6.12 có bộ cấp phát bộ nhớ chia sẻ ashmem viết bằng Rust. Nghĩa là hàng triệu máy đã chạy code Rust trong nhân.
• Binder viết lại bằng Rust: vào nhân từ bản 6.18, chạy song song với bản C cũ để nhà sản xuất tự chọn.
• Driver đồ hoạ: theo DevClass, người bảo trì DRM Dave Airlie cho rằng DRM còn khoảng một năm nữa là yêu cầu Rust cho driver mới.
• Greg Kroah-Hartman nhận xét driver Rust đang tỏ ra an toàn hơn driver C, và chuyện Rust tương tác với lõi C ít rắc rối hơn dự kiến.

Lỗ hổng Rust đầu tiên của nhân: CVE-2025-68260

Không lâu sau khi Binder Rust vào nhân, một CVE được gán cho chính driver này. Đây là lỗi race condition trong cách quản lý danh sách death_list: trong Node::release, code lấy khoá, chuyển các phần tử sang một danh sách cục bộ, rồi nhả khoá. Một khối unsafe giả định rằng phần tử không bao giờ nằm trong danh sách của node khác, và giả định đó sai khi có tiến trình chạy song song. Hậu quả là hỏng bộ nhớ, nhân bị crash. Lỗi chỉ khai thác cục bộ, xuất hiện từ 6.18 và đã được vá ở 6.18.1 và 6.19-rc1.

Bài học không phải "Rust cũng không an toàn". Bài học là lỗi nằm đúng ở nơi thiết kế dự đoán: trong khối unsafe, nơi lập trình viên tự chịu trách nhiệm chứng minh an toàn. Khi điều tra, người ta biết chính xác phải nhìn vào đâu.

Rủi ro và giới hạn còn lại

• Không phải cấu hình nào cũng hỗ trợ: Ojeda nói rõ việc kết thúc thử nghiệm không có nghĩa mọi kiến trúc, cấu hình hay toolchain đều chạy được. Code Rust chưa được build mặc định.
• Toolchain: gccrs (Rust trên GCC) chưa hoàn thiện. Kiến trúc ít phổ biến như s390 có thể bị ảnh hưởng nếu Rust trở thành bắt buộc.
• unsafe vẫn là điểm nóng: như CVE trên cho thấy, race condition và giả định sai trong unsafe vẫn gây hỏng bộ nhớ.
• Chi phí con người: người bảo trì phải đọc được cả C lẫn Rust; abstractions phải theo kịp thay đổi API C.

Áp dụng thế nào?

• Dev: Nếu viết driver hay code hệ thống, học mẫu "bindings → abstractions → code an toàn". Bạn có thể áp dụng y hệt cho dự án C/C++ của mình: một lớp mỏng chứa toàn bộ unsafe, phần còn lại thuần an toàn.
• Tech Lead: Đặt quy tắc như nhân Linux: module nghiệp vụ không được gọi FFI trực tiếp; mọi khối unsafe có comment SAFETY: giải thích bất biến, và được review riêng, đặc biệt các đoạn có khoá và đa luồng.
• PM: Dự án hạ tầng lớn nhất thế giới đã coi Rust là lâu dài. Đây là tín hiệu tuyển dụng và đào tạo: nhân sự biết Rust hệ thống sẽ ngày càng cần, không còn là lựa chọn thử nghiệm.