TRACTOR, công nghệ chuyển đổi mọi mã C sang Rust
(darpa.mil)- TRACTOR của DARPA là một chương trình nghiên cứu nhằm tự động chuyển đổi mã C cũ sang Rust để loại bỏ toàn bộ nhóm lỗ hổng an toàn bộ nhớ trong các chương trình C
- Vấn đề an toàn bộ nhớ của C và C++ đã được bàn tới hơn 20 năm, nhưng ngày càng có nhận thức rằng chỉ các công cụ phát hiện lỗi là không đủ
- Phương án thay thế là chuyển mã hiện có sang ngôn ngữ lập trình an toàn có thể từ chối các chương trình không an toàn ngay tại thời điểm biên dịch
- Kết quả chuyển đổi hướng tới chất lượng và phong cách tương đương mã do các nhà phát triển Rust giàu kinh nghiệm viết ra, bằng cách kết hợp phân tích tĩnh, phân tích động và học máy dựa trên mô hình ngôn ngữ lớn
- MIT Lincoln Laboratory phụ trách kiểm thử và đánh giá, còn benchmark, các dự án cột mốc và công cụ được đăng trên trang công khai
Mục tiêu của TRACTOR
- TRACTOR là chương trình “Translating All C to Rust”, với mục tiêu tự động chuyển đổi mã C cũ sang Rust
- Về mặt bảo mật, chương trình hướng tới việc loại bỏ toàn bộ nhóm lỗ hổng bảo mật về an toàn bộ nhớ tồn tại trong các chương trình C
- Mã sau khi chuyển đổi không chỉ dừng ở mức chạy được, mà còn hướng tới chất lượng và phong cách tương đương mã do các nhà phát triển Rust lành nghề tạo ra
Vì sao cần chuyển sang Rust
- Vấn đề an toàn bộ nhớ của C và C++ là bài toán mà cộng đồng kỹ thuật phần mềm đã xử lý hơn 20 năm qua
- Đã hình thành sự đồng thuận rằng cách tiếp cận chỉ dựa vào các công cụ phát hiện lỗi khó có thể giải quyết vấn đề một cách đầy đủ
- Cách tiếp cận được ưa chuộng hơn là sử dụng ngôn ngữ lập trình an toàn có thể từ chối các chương trình không an toàn ngay tại thời điểm biên dịch
- TRACTOR sử dụng Rust làm ngôn ngữ đích
Công nghệ dùng cho chuyển đổi tự động
- TRACTOR kết hợp nhiều kỹ thuật phân tích phần mềm và kỹ thuật học máy để chuyển mã C cũ sang Rust
-
Kỹ thuật phân tích
- Kết hợp phân tích tĩnh và phân tích động
- Các kỹ thuật học máy, bao gồm mô hình ngôn ngữ lớn, cũng là một phần của tổ hợp này
- Tổ hợp này là trụ cột công nghệ cốt lõi cần thiết để nắm bắt cấu trúc và hành vi của mã C, rồi tự động chuyển đổi sang mã Rust
Kiểm thử, đánh giá và tài liệu công khai
- Nhóm của MIT Lincoln Laboratory thực hiện kiểm thử và đánh giá cho chương trình nghiên cứu
- Benchmark, các dự án cột mốc và công cụ được đăng trên trang TRACTOR của MIT Lincoln Laboratory
- Nội dung liên quan có liên kết tới Eliminating Memory Safety Vulnerabilities Once and For All
1 bình luận
Ý kiến trên Hacker News
Nhân tiện, https://sam.gov/opp/1e45d648886b4e9ca91890285af77eb7/view cũng đáng xem
Trong đó nêu rõ mục đích của sự kiện này là giải thích các mục tiêu kỹ thuật và thách thức của TRACTOR, trả lời câu hỏi của các bên đề xuất tiềm năng, và tạo cơ hội để xem xét nghiên cứu của mỗi bên phù hợp với mục tiêu chương trình TRACTOR như thế nào
Việc này trông thực sự rất khó. Đặc biệt là Rust thành ngữ do người có kinh nghiệm viết thì hoàn toàn không giống C, còn phần mã thú vị phần lớn lại được viết bằng C++
Rốt cuộc chẳng phải đây gần như là việc xác định tĩnh toàn bộ vòng đời cấp phát của một chương trình C sao, kể cả các cấp phát đi qua allocator tự định nghĩa hay thư viện độc quyền? Nghiên cứu trong lĩnh vực này đã có từ lâu nhưng không có nhiều thành công lớn, và các chương trình C/C++ có thể gắn vòng đời cấp phát với việc người dùng bấm nút nào đó mà không cần cơ chế an toàn như đếm tham chiếu. Đây không phải ý hay, nhưng hoàn toàn có thể làm vậy
Một vấn đề hiển nhiên khác là chương trình cần phân tích, theo định nghĩa, là mã có lỗi. Nếu vòng đời đã hợp lý thì đã không có lỗ hổng an toàn bộ nhớ và cũng chẳng cần thay thế. Các nghiên cứu nhằm phát hiện tĩnh “vòng đời đáng ra phải như thế nào” thường giả định mã được phân tích vốn đã đúng từ đầu. Có lẽ có thể nhắm tới một chương trình tìm ra các điểm không thể xác định vòng đời rồi yêu cầu lập trình viên hỗ trợ
Tuy vậy, đây không phải lần đầu DARPA thử dịch chương trình tự động hay dịch tự động sang Rust[2]
[1]: https://www.urbandictionary.com/define.php?term=DARPA%20hard
[2]: https://c2rust.com/
Dự án này có một cây cú pháp trừu tượng hợp nhất hỗ trợ các ngôn ngữ đó về cơ bản như cùng một tập kiểu nút, nên khá ấn tượng. Tôi từng có dịp làm việc với nó khi thực tập mùa hè năm 2014 ở Livermore
Nó cũng là mã nguồn mở: http://rosecompiler.org/ROSE_HTML_Reference/index.html
Nếu chỉ vật lộn với borrow checker thôi đã thấy khó, thì việc tự động dịch sao cho borrow checker chấp nhận, trong khi phải tính đến toàn bộ không gian chương trình khả dĩ của C và cả hành vi không xác định nổi tiếng của nó, còn khó hơn nhiều. Một trong những bài toán kinh điển của việc viết compiler là không gian các chương trình hợp lệ lớn hơn rất nhiều so với không gian các chương trình có thể biên dịch được
Tìm kiếm nhanh thì thấy cũng đã có những nỗ lực như c2rust[1]. Tôi tò mò TRACTOR khác ở điểm nào
[1] https://github.com/immunant/c2rust
Nếu thay vì đưa chương trình gốc vào mà đưa tài liệu hướng dẫn của chương trình vào thì có lẽ còn thú vị hơn. Nhưng tài liệu hiếm khi chứa toàn bộ các hành vi tinh vi của chương trình, nên ít nhất để có được chuẩn tham chiếu thực tế thì rất có thể vẫn phải nhìn vào mã nguồn
Tôi đã biết về sáng kiến được đề xuất này từ khá lâu, và thật thú vị khi giờ nó được công khai. Đây là một đề xuất rất tham vọng, và mức độ tham vọng này có vẻ phù hợp với sứ mệnh của DARPA; hy vọng nó sẽ thành công
Với tư cách là người ủng hộ Rust trong lĩnh vực này, tôi vẫn luôn cố hạ thấp kỳ vọng của những người thúc đẩy đề xuất này về khả năng tự động dịch từ C sang Rust. Trở ngại căn bản theo tôi thấy là mã nguồn C chứa ít thông tin hơn mã nguồn Rust. Để dịch mã C sang mã Rust, ai đó hoặc thứ gì đó phải tạo ra phần thông tin bị thiếu đó. Cũng như việc phóng to một bức ảnh thật lớn không thể tạo ra chính xác những bit thông tin vốn không được ghi lại trong ảnh gốc, có thể dễ dàng chứng minh rằng không thể tạo ra hoàn hảo phần thông tin bị thiếu này. Rốt cuộc, phải ngoại suy, tức là phát minh ra, thông tin còn thiếu từ mã nguồn hiện có. Muốn ngoại suy đúng thì cần có phán đoán, và đây là một quá trình chắc chắn sẽ có lỗi, đặc biệt khi các mô hình ngôn ngữ không được giám sát thực hiện ở quy mô lớn. Tôi từng đề xuất một giải pháp mà tôi nghĩ có thể phần nào giảm nhẹ vấn đề này, nhưng sẽ không đi sâu ở đây
Cuối cùng, tôi nghĩ dự án này có thể đạt được một mức độ thành công nào đó, nhưng cần được tiến hành với kỳ vọng thận trọng và tiết chế. Đồng thời cũng có khả năng sẽ không có bất kỳ kết quả công khai nào, nên tôi muốn nói rằng đừng diễn giải quá mức ở giai đoạn này. Đặc biệt, chính phủ không phải là một thực thể đơn nhất, nên không nên hiểu dự án này như một sự phủ định toàn diện đối với C hay một sự ban phước toàn diện cho Rust. Mỗi cơ quan sẽ tự quyết định hướng đi và lộ trình áp dụng công nghệ an toàn bộ nhớ của riêng mình. Ví dụ, NIST khuyến nghị không chỉ Rust mà còn cả Ada SPARK, cũng như nhiều phương ngữ C/C++ được tăng cường khác
https://cpp-rust-assisted-migration.gitlab.io/blog/
Các dự án Rust hóa trong thực tế thường vận hành theo cách này. Fuzzer cũng có thể giúp tạo thêm dữ liệu kiểm thử để tăng độ bao phủ nhánh
Cá nhân tôi không thích tư duy “viết lại toàn bộ thế giới bằng Rust”. Dù vậy, nếu định chuyển một dự án sang ngôn ngữ hoặc nền tảng mới, thì dịch cơ học là một cách làm tệ
Cần dành thời gian để lên kế hoạch cho một kiến trúc tốt hơn và thiết kế một hệ thống phần mềm tốt hơn, rồi tìm cách thay thế từng phần. Xây lâu đài trên mây thì sẽ không bao giờ chạm đất. Nếu đã quyết định dùng Rust cho hệ thống này thì không sao, nhưng phải viết theo đúng tinh thần Rust. Đừng cố chuyển nguyên kiểu C sang Rust
Tôi cho rằng một quy trình tốt hơn và trưởng thành hơn nhiều là cập nhật C thành C hiện đại, rồi dùng các model checker như CBMC để xác minh tính an toàn của bộ nhớ, tài nguyên và phép toán số nguyên. Bạn có thể đạt được mức độ an toàn tương đương với việc viết lại dần sang Rust, mà vẫn giữ được codebase, nền tảng tri thức và đội ngũ phát triển
Tôi đồng ý rằng thay thế nó bằng một phiên bản Rust được thiết kế kiến trúc thủ công rõ ràng là giải pháp tốt hơn, nhưng chi phí cũng cao hơn. Ở đây có vẻ mục tiêu là một sản phẩm kiểu RLBox, tức là “cải thiện bảo mật rất nhiều mà gần như không tốn công”. Không phải là nếu có nguồn lực thì đừng làm một cuộc viết lại hoàn toàn thủ công, nhưng ý là như thế vẫn còn tốt hơn là không làm gì
Nếu thay vào đó hỏi ChatGPT về bài toán ban đầu mà bạn đang cố giải, nó sẽ trả lời đúng thường xuyên hơn, nhưng nhìn chung vẫn không tốt lắm. Muốn ngay cả những thứ cơ bản mà nó sinh ra có thể chạy được thì vẫn cần rất nhiều chỉnh sửa và suy nghĩ
Không phải sức hút kiểu rõ ràng là ý tưởng hay. “Rust dở” được tạo ra từ quá trình dịch có thể còn khó làm việc hơn nhiều so với C với phần nền nhiễu là bug. Nhờ bản dịch trung thành, những bug đó cũng sẽ được giữ nguyên trong “Rust dở”. Với C, mọi người phần nào biết cách xử lý các vấn đề đó, còn “Rust dở” thì đúng nghĩa là dở vì dân Rust không quen với kiểu đó
Dù vậy, khả năng ai đó phát triển được kỹ thuật dọn dẹp lặp đi lặp lại để đưa nó về trạng thái chấp nhận được không phải là 0. Ngoài ra, một đầu ra không phải mục tiêu của dự án có thể là phản hồi từ linter kiểu “không thể dịch sang Rust tử tế vì x, y, z”. Các lập trình viên C có thể xem xét điều đó, và nếu mã đã trở nên có thể dịch sang Rust tốt, thì lý do phải dịch lại cũng giảm đi
Nếu ra được kết quả như vậy, có thể với một số người sẽ dễ hơn khi mô tả lời giải bằng C có thể thực thi, rồi để “trình dịch/linter” dẫn họ tới một cách tiếp cận không bị hỏng. Tôi cho rằng những kết quả tích cực kiểu này có xác suất khá thấp, nhưng thỉnh thoảng đặt một cược dark horse chẳng phải cũng gần với mô tả công việc của DARPA sao
Vấn đề cốt lõi là hãy bắt đầu giảm các CVE về an toàn bộ nhớ đã được chứng minh là thực sự gây ra vấn đề hết lần này đến lần khác
Tôi đồng ý với ý rằng nếu việc dịch tự động và đáng tin cậy từ C/C++ sang Rust là khả thi thì nó đã được làm từ lâu rồi. Nhưng ở đâu đó trong quá trình lên kế hoạch cho kiến trúc và hệ thống tốt hơn để thay thế từng phần, mọi người có thể bắt đầu tự tin rằng “giờ mình đã dùng C tốt hơn nhiều rồi, chắc sẽ không tạo thêm bug an toàn bộ nhớ nữa đâu, hay dừng ở đây thôi nhỉ?”, và thực tế họ sẽ làm vậy. Rồi 6 tháng sau lại xuất hiện thêm một CVE tràn bộ đệm vừa buồn cười vừa đáng buồn
Việc cập nhật C thành C hiện đại rồi xác minh bằng CBMC cũng là một khoản đầu tư khổng lồ. Nếu đã làm đến mức đó thì thà chuyển sang Rust còn hơn. Còn chuyện đạt được mức độ an toàn tương đương với việc viết lại dần sang Rust thì có thể đúng, nhưng nghe khá bất định hoặc chưa đủ rõ ràng để rút ra kết luận chắc chắn
Nhiều người đang đọc điều này như một yêu cầu hay mệnh lệnh phải dịch toàn bộ mã C và C++ sang Rust, nhưng trái với tên dự án khá bắt mắt, phần tóm tắt không thể hiểu như vậy. Có hai đoạn riêng biệt, có liên quan với nhau nhưng không phải là một
Thứ nhất, C và C++ không đủ an toàn ở quy mô lớn. Dù lập trình cẩn thận và dùng công cụ tốt, vẫn xuất hiện quá nhiều lỗ hổng vì thiết kế vốn dĩ không an toàn. Vì vậy cần dịch hoặc viết mới càng nhiều mã càng tốt sang các ngôn ngữ “an toàn”, đặc biệt là các ngôn ngữ bảo đảm an toàn bộ nhớ
Thứ hai, họ đang cấp vốn và mời gọi đề xuất cho phần mềm dịch mã C hiện có sang Rust
Đây không phải là sự đồng thuận rằng phải viết lại thế giới bằng Rust. Đây là sự đồng thuận rằng cần di cư sang ngôn ngữ an toàn, và Rust chỉ là một ví dụ trong số đó, đồng thời có một chương trình nhắm Rust cho quá trình di cư này
unsafethì quy tắc dùng nó là gì? Nếu không có một bộ quy tắc được xác định để áp dụng ở đây thì rốt cuộc cũng chỉ quay lại điểm xuất phát mà thôiRust có một chế độ an toàn. Nhưng Rust không phải là một ngôn ngữ an toàn. Muốn làm những việc thú vị thì cần có các khối
unsafe. Như vậy cũng không đạt được bao nhiêuMặt khác, có nhiều ngôn ngữ có thu gom rác, nơi lập trình viên thậm chí không được đụng vào con trỏ. Tại sao những ngôn ngữ đó không được cân nhắc? Lý do là hiệu năng. Vì các lập trình viên Rust “coi trọng” hiệu năng đến mức đó nên họ sẽ không bao giờ giải quyết được vấn đề gốc rễ
Bạn muốn hiệu năng hay muốn an toàn? Không thể có cả hai
Thật đáng ngạc nhiên khi chuyện này có thể hoạt động theo bất kỳ kiểu tự động hóa nào. Không thể chép nguyên một chương trình C thông thường sang Rust theo từng dòng
Trong các chương trình C, con trỏ và aliasing ở khắp mọi nơi, còn Rust thì ngăn cấm rõ ràng các khái niệm đó. Trừ khi bọc toàn bộ trong
unsafe, để viết lại một chương trình C bằng Rust, cần phải suy nghĩ lại nhiều cấu trúc điển hình ở cấp độ cao hơn nhiềuCũng không cần dịch mọi thứ trong một lần. Một trong những giá trị của trình biên dịch Rust là nó cung cấp rất nhiều thông tin cụ thể có thể đưa lại vào LLM để lặp tiếp
Ở startup grit.io của tôi, chúng tôi đã xử lý các vấn đề tương tự, và tôi nghĩ C -> Rust sẽ là thứ có thể xử lý khá tốt trong tương lai gần. Chắc chắn không dễ, nhưng là một bài toán có thể giải được
Khi đó có thể coi đó là một bài toán con, còn việc phát hiện dữ liệu được chia sẻ giữa các luồng như thế nào là một bài toán khác. Với trường hợp sau, nhiều chương trình có lẽ có những quy tắc sở hữu ngầm như “luồng T1 đưa vào hàng đợi Q, luồng T2 lấy ra”. Điều này có thể được dịch thành “đưa vào hàng đợi là chuyển giao quyền sở hữu”
Việc phát hiện những quy tắc như vậy chắc chắn không dễ, nhưng cũng không có vẻ hoàn toàn ngoài tầm với, và là một dự án nghiên cứu khá có ý nghĩa
unsafe, biên dịch ra cùng một binary, rồi liên tục kiểm chứng tính tương đương và từ từ gỡunsafera sao?Làm như vậy thì ít nhất có thể đưa được càng nhiều phần càng tốt sang Rust, còn chỉ tách riêng những khái niệm mà kỹ sư phải suy nghĩ lại
unsafeTôi cho rằng để AI tạo ra một chương trình thực sự hữu ích và hợp lệ thì nó phải hiểu được vòng đời các tham chiếu các thứ. Nếu thật sự làm được thế thì sẽ rất ấn tượng
Nếu tuân thủ các thực hành viết mã cực kỳ nghiêm ngặt và tích hợp các công cụ kiểm chứng tĩnh của bên thứ ba đòi hỏi phải chèn rất nhiều chú thích độc quyền vào mã, thì vẫn có thể đạt kết quả tương tự với C/C++
Hoặc cứ dùng Rust là xong
Có một lựa chọn thay thế thực sự ở đó, vậy mà ai còn tỉnh táo lại đi bảo vệ những ngôn ngữ có lỗi thiết kế vừa lớn vừa hiển nhiên đến thế chứ
Tôi không nghĩ việc này sẽ thành công. C có những kiểu trừu tượng không thể sao chép sang Rust mà không thay đổi lớn
Trong C, việc hai cấu trúc dữ liệu khác nhau cùng chứa một con trỏ giống nhau và cùng ghi vào con trỏ đó là chuyện thường thấy. Điều này không thể tái hiện một cách tầm thường trong Rust, mà cần đến sự can thiệp khá khéo léo
Nhưng sẽ không thu được đầu ra ít lỗi hơn, cũng không có được quá trình tự động sinh ra cấu trúc chương trình vốn tạo nên độ tin cậy của Rust
Chuyện này có nhất thiết phải là tự động không? Nếu vậy thì một chương trình có thể tự động port C sang Rust chẳng phải tất yếu phải bao gồm toàn bộ chức năng để tự làm cho chính mã C trở nên an toàn sao?
Một số mã C đơn giản là không chỉ “không thể xác minh là đúng” mà còn “thực sự sai về mặt an toàn bộ nhớ”. Những mã như vậy sẽ không thể được dịch tự động nếu không có con người can thiệp. Không hề tồn tại mã tương đương đúng đắn, thì làm sao làm được. Công cụ cần có một lối thoát để nói rằng: “Tôi không biết đoạn mã này định làm gì, và tôi cũng biết thứ nó thực sự đang làm là vi phạm cam kết với trình biên dịch, nên đó không thể là điều được chủ ý. Con người ơi, hãy giúp tôi”
Về mặt lý thuyết, không thể khiến lối thoát đó chỉ được dùng khi hành vi không xác định thực sự xảy ra. Đó là vì định lý Rice. Về mặt thực tiễn, cũng không nên mù quáng dịch những đoạn mã quá rối rắm, nên nỗ lực làm như vậy có lẽ ngay từ đầu đã không đáng mong muốn
Cuối cùng, tôi hình dung công cụ này sẽ giống một công cụ tương tác làm phần lớn công việc nhưng có con người hướng dẫn. Và kết quả của sự hướng dẫn đó không phải là mã tương đương chính xác, mà là mã thực hiện cùng mục đích
Nếu 1) Rust không có lỗi bộ nhớ và 2) có thể tự động dịch C sang Rust, thì điều đó có nghĩa là có thể tự động sửa mọi lỗi bộ nhớ
Điều này gần như chắc chắn là không đúng. Công việc này rất có thể là hoàn toàn bất khả thi trong trường hợp tổng quát
Ví dụ, có thể thay mọi cấp phát bộ nhớ động bằng các bộ đệm cố định được xác định tại thời điểm dịch, rồi từ chối mọi đầu vào không vừa với các bộ đệm đó