Код компиляци болно гэдэг аюулгүй гэсэн үг биш: Canonical legacy С кодыг Rust руу найдвартай хөрвүүлэх 4 шатлалт AI төслийг эхлүүллээ

Санах ойн аюулгүй байдал ба Legacy кодын гацаа

Программ хангамжийн салбарт сүүлийн жилүүдэд санах ойн аюулгүй байдал (Memory Safety) хамгийн эмзэг сэдэв болоод байна. Линукс үйлдлийн системийн цөмөөс эхлээд сүлжээ, системийн хамгаалалтын чухал хэрэгслүүдийн дийлэнх нь C болон C++ дээр бичигдсэн хэвээр байгаа билээ. Гэвч buffer overflow, use-after-free, double free зэрэг санах ойн алдаанаас үүдэлтэй аюулгүй байдлын цоорхойнууд гарсаар байна.

Үүнийг шийдэх хамгийн зөв гарц нь системийн түвшинд аюулгүй ажилладаг Rust хэл рүү шилжих явдал гэдэгтэй ихэнх инженерүүд санал нийлдэг. Гэвч бодит байдал дээр олон арван жилийн турш туршигдсан, нарийн edge-case тохиолдлуудыг шийдсэн хэдэн зуун мянган мөр C кодыг гараар дахин бичнэ (rewrite) гэдэг асар өндөр зардалтай бөгөөд шинэ алдаа гаргах өндөр эрсдэлтэй.

Үүнийг шийдвэрлэхийн тулд Ubuntu-г хөгжүүлэгч Canonical компани Их Британийн Bristol-ийн их сургуулийн Программчлалын хэлний судалгааны багтай (PLRG) хамтран том хэмжээний C кодын санг найдвартай Rust руу автоматаар хөрвүүлэх 3 жилийн суурь судалгааны төслийг эхлүүлж, санхүүжилт олгосноо зарлалаа.

Яагаад C2Rust болон одоогийн LLM-үүд хангалтгүй байна вэ?

Өнөөг хүртэл C-ээс Rust руу хөрвүүлэхэд хоёр үндсэн аргыг ашиглаж ирсэн:

Уламжлалт хөрвүүлэгчид (жишээ нь C2Rust): Эдгээр хэрэгслүүд C-ийн заагч (pointers), бүтэц, логикийг Rust руу шууд хуулдаг. Үр дүнд нь үүссэн код Rust дээр компиляци болдог хэдий ч код нь бүхэлдээ unsafe {} блокоор дүүрч, C хэлний хуучин аюултай зуршлуудыг хэвээр хадгалдаг. Өөрөөр хэлбэл Rust-ийн жинхэнэ давуу тал болох Ownership болон Borrow Checker-ийн боломжуудыг ашиглаж чаддаггүй.
Том хэлний загварууд (LLM): LLM-үүд цөөн мөртэй функц, жижиг хэсгүүдийг идиоматик (жинхэнэ Rust хөгжүүлэгчийн бичсэн мэт) цэвэр Rust код болгон сайн хувиргадаг. Гэвч бүхэл бүтэн репозиторийн хэмжээнд хүрэх үед файлуудын хамаарал, global state, санах ойн менежментийг алддаг.

Хамгийн том аюул нь: Код компиляци болж алдаагүй ажиллаж байгаа мэт харагдах нь анхны логик зан төлөвөө бүрэн хадгалсан гэсэн баталгаа биш юм. Canonical-ийн эш татсан судалгаагаар, LLM-ийн хөрвүүлсэн бөгөөд амжилттай компиляци болсон кодуудын дөнгөж 69.9% нь л анхны C програмын зан төлөвийг яг таг хадгалж байжээ.

Canonical-ийн 4 шатлалт "Neurosymbolic" шийдэл

Canonical болон Бристолын их сургууль зөвхөн "AI-д C код өгөөд Rust болгож авах" хандлагаас татгалзаж, Neurosymbolic AI (Хиймэл оюун + Формал математик арга барил, статик шинжилгээ)-ийг хослуулсан 4 шатлалт системийг хөгжүүлж байна:

+-------------------+      +-------------------------+
| 1. Scheduling     | ---> | 2. Context-Aware LLM   |
| (Хамаарал салгах) |      | (Идиоматик Rust үүсгэх) |
+-------------------+      +-------------------------+
                                        |
+-------------------+      +-------------------------+
| 4. Auto-Repair    | <--- | 3. Formal Verification  |
| & Debug Loop      |      | & Testing (Баталгаажуулалт)|
+-------------------+      +-------------------------+

1. Scheduling & Dependency Partitioning (Кодын бүтцийг ухаалгаар хуваах)

Хэдэн зуун мянган мөр кодыг шууд промптод хийх боломжгүй тул систем репозиторийн бүх хамаарлын модыг (Call graph, Data dependencies) задлан шинжилж, тусдаа хөрвүүлж болохуйц жижиг модулиудад хуваана.

2. Context-Aware Neural Translation (Утга зүйн дагуу хөрвүүлэх)

Сэргээгдсэн контекст дээр үндэслэн тусгайлан нарийн тааруулсан LLM нь C кодын заагч ба санах ойн үйлдлүүдийг Rust-ийн аюулгүй Option, Result, Smart Pointer болон Lifetime дүрэмд нийцүүлэн хөрвүүлнэ.

3. Rigorous Verification & Differential Testing (Зан төлөвийг шалгах)

Хөрвүүлсэн кодыг шууд хүлээн авахгүй. Программын статик шинжилгээ, Symbolic Execution болон Differential Testing (С ба Rust хувилбарт яг адилхан оролт өгч гаралт, төлөвийг харьцуулах) ашиглан 100% тэнцүү зан төлөвтэй байгаа эсэхийг математик нарийвчлалтайгаар баталгаажуулна.

4. Automated Repair Loop (Алдааг өөрөө засах цикл)

Хэрэв баталгаажуулалтын шатанд ямар нэг логик эсвэл санах ойн зөрүү илэрвэл шалгалтын үр дүнг буцаан AI системд өгч, алдааг засварлах эргэх холбоо (feedback loop) ажиллана.

Бодит туршилт: AppArmor болон Snap-confine

Энэхүү төсөл зөвхөн онолын түвшинд үлдэхгүй. Canonical уг платформоо Ubuntu-ийн аюулгүй байдлын гол цөм болсон AppArmor (хэрэглээний програмын хандалтыг хязгаарлагч систем) болон snap-confine (Snap багцуудын тусгаарлалтыг хариуцдаг C код) зэрэг чухал эх кодууд дээр туршиж баталгаажуулахаар сонгон авчээ.

Хэрэв системийн түвшний ийм чухал хамгаалалтын код дээр энэ арга амжилттай хэрэгжвэл Линукс экосистем дахь олон арван жилийн настай С-ийн сангуудыг аюулгүй Rust руу өвдөлтгүйгээр шилжүүлэх шинэ үүд нээгдэнэ.

Хөгжүүлэгчдэд өгөх гол дүгнэлт

Энэхүү судалгааны ажил орчин үеийн программ хангамжийн инженерчлэлд маш чухал дохио өгч байна:

Compile Rate != Correctness: AI кодын хувьд компиляци болж, syntax алдаагүй байх нь логик зөв ажиллаж байна гэсэн үг биш.
Шинэчлэлийн ирээдүй — Neurosymbolic: Зөвхөн текст үүсгэгч LLM дангаараа legacy системийг шинэчилж чадахгүй. Формал баталгаажуулалт, статик анализтай хослуулсан "Verification Pipeline" нь агент төвтэй кодингийн ирээдүйн гол цөм байх болно.

Эх сурвалж: Ubuntu Community Hub - Investing in automated C to Rust translation, Developer Tech News