Canonical финансира AI превод от C към безопасен Rust

Canonical финансира тригодишен докторантски проект в University of Bristol, чиято цел е да построи система за автоматичен превод на големи хранилища със C код в безопасен Rust. Обявата е на Джон Сийгър, вицепрезидент по инженеринг в Canonical, публикувана на 19 август в Ubuntu Discourse, а темата стигна до по-широката аудитория след материала на The Register от 24 август. Финансирането е споделено с британската държавна агенция UK Research and Innovation (UKRI), а работата стартира по-късно през 2026 г.

Кой прави проекта

Проектът се води от групата Programming Languages Research Group в University of Bristol. Докторантът е Алекс Уд, научен ръководител е проф. Менг Уанг, а съръководители са д-р Кристина Дейвид и самият Сийгър от страна на Canonical. Конкретната сума не е обявена нито от компанията, нито от UKRI — известно е само, че двете страни покриват поравно тригодишния период.

Заявената цел звучи амбициозно: платформа „от край до край“, която взема хранилище със стотици хиляди редове C и връща „безопасен, поведенчески коректен и поддържаем Rust“. Последните три прилагателни са ключът — точно там се провалят днешните инструменти.

Защо досегашните конвертори не вършат работа

Автоматични преводачи от C към Rust съществуват от години, но резултатът им рядко е използваем. Сийгър го формулира директно: съществуващите инструменти „запазват структурата на C твърде буквално. Резултатът може и да се компилира като Rust, но продължава да разчита силно на unsafe операции, запазва тромави C идиоми и изисква значителна ръчна работа.“

С други думи, получавате Rust синтаксис върху C логика — без реалните гаранции за памет, заради които изобщо се минава към Rust. Алтернативата — ръчно пренаписване — е още по-скъпа и носи собствен риск: изхвърляте десетилетия натрупани поправки на бъгове и оптимизации, които никой вече не помни защо са там.

Четирите компонента

Подходът е описан като „невросимволен“ — комбинация от машинно обучение и класически методи за анализ на програми. Системата се разделя на четири части:

• Планиране (scheduling) — разбиване на хранилището на достатъчно малки парчета за превод, без да се губи контекстът, зависимостите и типовата информация.
• Превод (translation) — езикови модели, донастроени върху съществуващи примери, в които C код вече е пренаписан на Rust.
• Валидация (validation) — fuzz тестове и формална проверка за поведенческа еквивалентност между оригинала и превода.
• Отстраняване на грешки (debugging/repair) — символни техники за автоматична поправка, когато валидацията не мине.

Най-важното тук е философията: генерираният код се третира като ненадежден, докато не бъде доказана еквивалентността му. Езиковият модел върши само една част от работата — останалите три компонента съществуват именно защото на изхода му не може да се вярва. Това е разумна предпазливост в момент, в който AI ускорява научната работа, но често прави резултатите по-плитки.

AppArmor и snap-confine като полигон

За индустриални тестови случаи са избрани два реални компонента на Ubuntu: AppArmor — системата за задължителен контрол на достъпа, която ограничава какво може да прави едно приложение, и snap-confine — програмата, която създава изолираната среда за изпълнение на snap пакетите.

И двете са критични за сигурността на Ubuntu и са несравнимо по-тежък тест от изолирани учебни примери. Canonical обаче изрично уточнява, че това не е ангажимент AppArmor и snap-confine да бъдат пренаписани на Rust. Те са казуси — компанията просто има пряк интерес към този софтуер и иска да види докъде стига методът.

Контекстът

Ubuntu вече върви в тази посока и без AI. От версия 25.10 дистрибуцията използва по подразбиране uutils — реализация на coreutils на Rust — и sudo-rs вместо класическия sudo. Rust влезе в ядрото на Linux още от 6.1 през 2022 г. и оттогава делът му расте, а Microsoft също пренаписва части от собствения си код.

Мотивът е добре документиран: значителна част от сериозните уязвимости в системния софтуер идват от грешки при работа с паметта — препълване на буфер, използване след освобождаване, двойно освобождаване. Rust ги прави невъзможни по конструкция за кода извън unsafe блоковете. Проблемът е чисто икономически — C доминира от 1972 г. насам и никой няма ресурс да пренапише всичко на ръка.

Дали езиковите модели ще решат този проблем, е отворен въпрос. Оптимистичният сценарий според авторите е система, която превежда сериозни C хранилища с убедително доказателство за поведенческа еквивалентност и минимална ръчна намеса. Дори частичен успех обаче би бил полезен — в AI изследванията напоследък се вижда, че комбинирането на модели с добре подбрана класическа математика дава изненадващо добри резултати.

Заключение

Тук няма продукт, няма дата на пускане и няма обещание за резултат — има изследователски проект с тригодишен хоризонт и напълно реален шанс да не стигне доникъде. Интересното е подходът: вместо да се разчита на модел, който „изглежда, че е разбрал“ кода, целият дизайн е построен около допускането, че моделът греши, и около инструментите, които го хващат. Ако този принцип проработи върху нещо толкова заплетено като snap-confine, ползата ще е далеч по-широка от Ubuntu.