Rust sẽ cứu Linux khỏi AI, theo Greg Kroah-Hartman

Công nghệ Trang chủ Công nghệ Bảo mật Rust sẽ cứu Linux khỏi AI, theo Greg Kroah-Hartman Điều đó không có nghĩa là người duy trì nhân Linux ổn định Greg Kroah-Hartman nghĩ rằng Rust là phép màu. Viết bởi Steven Vaughan-Nichols, Biên tập viên đóng góp cấp cao Ngày 27/5/2026 lúc 6:34 sáng theo giờ PT Ảnh chụp màn hình của ZDNET / Rust Week 2026 - Main Track của RustNL qua YouTube. Theo dõi ZDNET: Thêm chúng tôi làm nguồn ưu tiên trên Google. Những điểm chính của ZDNET Rust sẽ cứu Linux khỏi những điểm yếu bảo mật cố hữu của C. Linux, đối mặt với hàng loạt vấn đề bảo mật do AI phát hiện, có thể cần sự trợ giúp. Trong tương lai, ngày càng nhiều mã Linux sẽ được viết bằng Rust. Tại hội nghị Rust Week, hội nghị ngôn ngữ Rust lớn nhất thế giới, ở Utrecht, Hà Lan, người duy trì nhân Linux ổn định Greg Kroah-Hartman đã mở đầu bằng cách nói: "Tôi ở đây để nói về dữ liệu không đáng tin cậy và Linux, và cách Rust sẽ cứu chúng ta." Sau "một hoặc hai tháng dài trên danh sách bảo mật nhân," ông đã đẩy quan điểm đó đi xa hơn: "Tôi sẽ đưa ra một tuyên bố táo bạo hơn và nói, 'Bạn sẽ cứu Linux.' Xin lỗi, tất cả là do bạn." Cứu? Linux cần được cứu? Điều ông đang nói đến là sự bùng nổ đột ngột của các lỗ hổng bảo mật nghiêm trọng trong Linux được phát hiện, như Dirty Frag, Copy Fail và Fragnesia, đã được đưa ra ánh sáng nhờ các chương trình phát hiện lỗi AI mới nhất. Kết quả là, Kroah-Hartman, người đã "thấy mọi lỗi bảo mật nhân từ năm 2005," cho biết nhóm nhân hiện đang phát hành "13 CVE [Common Vulnerabilities and Exposures] mỗi ngày, hoặc một con số điên rồ nào đó." Ông nghĩ rằng Rust là một trong số ít cách thực tế để giảm thiểu loại lỗi phát sinh từ các cạm bẫy xử lý lỗi và quản lý tài nguyên truyền thống của C. Ngoài ra: Một trong những bản phân phối Linux thân thiện với người dùng nhất mà tôi từng sử dụng cũng là một trong những bản bảo mật nhất. Kroah-Hartman đã minh họa những cạm bẫy đó bằng các lỗi C thực tế trong nhân, bao gồm một lỗi Bluetooth 15 năm tuổi đã giải tham chiếu một con trỏ mà không kiểm tra nó và một lỗi Xen trong đó "chúng tôi quên mở khóa" trong một đường dẫn lỗi. "Phần lớn các lỗi trong nhân là những thứ nhỏ nhặt này," ông giải thích. "Các điều kiện lỗi không được kiểm tra, các khóa bị quên, bộ nhớ không được giải phóng bị rò rỉ, và các lỗ hổng tích tụ theo thời gian. Chúng làm sập nhân. Đây là điều chúng ta phải sống chung với C. Đây là lý do tại sao chúng ta không thích nó." Kroah-Hartman lập luận rằng "vẻ đẹp lớn nhất của Rust" là việc phát hiện những lỗi đó tại thời điểm xây dựng thay vì trong quá trình xem xét. Ví dụ, khi nói đến việc khóa, ông nhấn mạnh các trừu tượng khóa của Rust trong nhân: "Cách duy nhất bạn có thể truy cập vào các con trỏ bên trong của các cấu trúc là bằng cách lấy khóa đó, và tự động giải phóng khóa. Trình biên dịch thực hiện điều đó, nó được bảo vệ, khóa xảy ra, mọi thứ đều ổn. Bạn không thể viết mã để truy cập các giá trị này... mà không lấy khóa. Trình biên dịch sẽ không cho phép bạn." Ông lập luận rằng những đặc tính này trực tiếp loại bỏ một phần lớn các lỗi mà ông thường thấy: "Điều này sẽ giúp chúng ta tránh được hai vấn đề đó. Thứ nhất, 60% lỗi trong nhân (kernel) sẽ biến mất ngay lập tức. Cảm ơn." Lợi ích là việc thực thi sớm hơn, tự động hơn: "Nếu điều này xảy ra ở thời điểm biên dịch (build time), không phải thời điểm xem xét (review time), đừng bắt tôi làm một người bảo trì (maintainer) phải đọc mã của bạn [và] nói, 'Ồ, bạn đã kiểm tra giá trị lỗi đó đúng cách chưa. Ồ, bạn đã khóa đúng chỗ chưa?' Rust cung cấp cho chúng ta điều đó miễn phí. Đây là điều tuyệt vời nhất từ trước đến nay." Ngay cả khi Rust biến mất vào ngày mai, Kroah-Hartman lập luận, nó đã buộc nhân phải dọn dẹp mã C và các giao diện. Ông thẳng thắn ghi nhận ảnh hưởng của Rust: "Chúng tôi đã lấy ý tưởng này từ Rust. Cảm ơn. Đó là một ý tưởng hay, vì vậy nếu Rust biến mất vào ngày mai, chúng tôi đã dọn dẹp mã C trong nhân rất nhiều và tiếp thu các ý tưởng. Chúng tôi cảm ơn bạn, bạn đã làm cho Linux tốt hơn chỉ bằng sự tồn tại của mình." Ngoài ra: Linux đang nhận được một lời cảnh tỉnh về bảo mật - tại sao điều đó là không thể tránh khỏi và tôi không lo lắng. Ông mô tả các "bộ bảo vệ" (guards) C mới và các khóa có phạm vi (scoped locks) được lấy cảm hứng từ Rust: "Bây giờ chúng ta có điều đó, chúng ta có các khóa và bộ cấp phát (allocators) có phạm vi C, và chúng ta đã thêm mã mới này, điều này khiến chúng ta khó mắc lỗi hơn, nhưng quan trọng nhất, nó làm cho việc viết mã đơn giản hơn." Với hơn 5.000 nhà phát triển và chỉ khoảng 700 người bảo trì, ông nói, thời gian xem xét là nguồn tài nguyên khan hiếm nhất – vì vậy các mẫu mã giúp việc kiểm tra tính đúng đắn trở nên rõ ràng là rất quan trọng: "Chúng tôi tối ưu hóa để làm cho mã dễ xem xét... Nếu tôi có thể xem xét mã của bạn dễ dàng hơn, tôi có thể lướt qua nó và nói, 'Này, bạn rõ ràng đã làm đúng vì bạn sử dụng mẫu đó. Mọi thứ đều tốt và ít lỗi hơn.'" Các ràng buộc (bindings) Rust cũng đang buộc các thay đổi sâu hơn ở phía C. Nhớ lại một hội nghị Rust-for-Linux ban đầu, ông nói rằng khi ông thấy "hàng trăm dòng mã Rust để xử lý hai dòng mã C," ông nhận ra, "Tôi có thể thay đổi mã C. Chúng ta có thể thay đổi mã C để làm cho mã Rust đơn giản hơn. Chúng ta không gặp vấn đề gì khi thay đổi cả hai phía của rào cản này. Hãy làm điều đó." Ông hiện ghi nhận nhóm Rust-for-Linux đã định hình lại các giao diện trình điều khiển: "Các quy tắc liên quan, và cách các đặc tính (traits) và giao diện đang hoạt động cho nhân trình điều khiển (driver core), và sự tương tác với mã C trong nhân sẽ làm cho các trình điều khiển dễ viết hơn và khó viết [sai] hơn... Họ đã làm một công việc tuyệt vời." Ngoài các tính năng ngôn ngữ, Kroah-Hartman liên hệ Rust trực tiếp với một nỗ lực rộng lớn hơn xung quanh dữ liệu không đáng tin cậy và ý tưởng rằng "tất cả đầu vào đều là xấu." Mượn một câu nói từ bộ phận bảo mật của Microsoft, ông nói với những người tham dự: "Nếu bạn không bao giờ nhớ bất cứ điều gì khác trong bài nói chuyện của tôi, chỉ cần nhớ bốn từ này. Nó đến từ Microsoft Security nhiều năm trước. Họ nhận ra tất cả đầu vào đều là xấu. Bạn phải xác thực tất cả đầu vào." Ông mô tả công việc đang tiến hành trên một trình bao bọc kiểu "không đáng tin cậy" (untrusted type wrapper) và một phương thức xác thực (validate method) trong Rust buộc phải xác thực rõ ràng tại điểm dữ liệu chuyển từ không đáng tin cậy sang đáng tin cậy.