Het Amerikaanse militaire agentschap dat verantwoordelijk is voor de ontwikkeling van nieuwe technologieën, is van plan om een ​​poging te doen om grote hoeveelheden C-code te herschrijven door een nieuwe onderzoeksuitdaging te financieren. Het doel is om een ​​geautomatiseerde vertaler te creëren die oude C-code kan omzetten met functies die zijn geschreven in de op beveiliging gerichte Rust-taal.

De Defense Advanced Research Projects Agency (DARPA) zal op 26 augustus een workshop houden, bekend als Proposers Day, om haar visie voor het Translating All C to Rust (TRACTOR)-project. De inspanning vraagt ​​om academische en industriële onderzoeksgroepen om te concurreren om een ​​systeem te creëren dat C-code kan omzetten in idiomatische — dat wil zeggen, met behulp van native features — Rust-code. Het uiteindelijke doel van het project is om tools te bieden zodat elke organisatie met grote volumes software geschreven in C die code kan omzetten naar Rust en de geheugenveiligheidsfouten kan elimineren die verantwoordelijk zijn voor een grote bron van softwarekwetsbaarheden.

Zonder een geautomatiseerd systeem is het onwaarschijnlijk dat ontwikkelaars deze taak op zich nemen, zegt Dan Wallach, programmamanager bij het Information Innovation Office (I2O) van DARPA.

“Tegenwoordig is het herschrijven van code duur en arbeidsintensief, en (organisaties) met grote legacy codebases kunnen zich dat in veel gevallen gewoon niet veroorloven,” zegt hij. “Het beste advies vandaag is: ‘Nou, begin toch maar en doe het stapsgewijs.’ Maar als we een hoge mate van automatisering kunnen creëren, dan verandert dat de economie van het probleem en wordt het mogelijk om code sneller te verbeteren.”

Technologiebedrijven en de Amerikaanse overheid hebben geheugenveiligheidslekken geïdentificeerd als een veelvoorkomend, maar volledig te voorkomenklasse van softwarekwetsbaarheden. In december 2022 maakte Google bekend dat in de software voor de nieuwste versie van Android de meerderheid van de nieuwe code was geschreven in de geheugenveilige talen Java, Kotlin en Rust, wat leidde tot veel minder geheugenveilige kwetsbaarheden — 85 in 2022 vergeleken met 223 in 2019.

Roest komt te hulp

Omdat er problemen zijn met de veiligheid van het geheugen — zoals buffer overflows en double-free fouten — komen doorgaans voor in C- en C++-code, hebben technische experts aanbevolen om over te stappen op Rust, een geheugenveilige taal die aan veel van dezelfde vereisten voldoet als die talen. Google ontdekte bijvoorbeeld dat het herschrijven van de QR-codegenerator voor Chrome in Rust de ontwikkelaars in staat stelde om deze te verplaatsen van de sandbox van de applicatie, wat de prestaties versnelde. Microsoft heeft enkele functies van het besturingssysteem herschreven in Rust en vond een prestatieverbetering van 5% tot 15%.

Rust blijft in feite de taal waarmee de meeste ontwikkelaars willen werken, waarbij 82% van de ontwikkelaars de programmeertaal “bewondert”, vergeleken met de 29% die de taal momenteel uitgebreid gebruikt. volgens de “2024 Developer Survey” van StackOverflow.

Veel organisaties gebruiken Rust al, of zijn ermee begonnen, zegt Beth Linker, senior director productmanagement voor de Software Integrity Group van Synopsys.

“We hebben de afgelopen 12 tot 18 maanden veel momentum gezien rondom Rust vanwege het standpunt van de Amerikaanse overheid over geheugenveilige programmeertalen”, zegt ze.

LLM’s noodzakelijk maar niet voldoende

Om Rust breed te kunnen gebruiken, moeten bedrijven ervoor zorgen dat de Rust-code functies van de programmeertaal gebruikt en interoperabel is met andere componenten die mogelijk nog in C of C++ zijn geschreven. Om die reden zullen grote taalmodellen (LLM’s) waarschijnlijk nodig zijn, zelfs als ze C-naar-Rust-code nog niet helemaal nauwkeurig kunnen vertalen, zegt Linker.

“In onze ervaring met het gebruik van LLM’s om Rust-code te genereren, hebben we gezien dat dit nog steeds een groeigebied is voor veel LLM’s, omdat er minder trainingsgegevens beschikbaar zijn voor Rust dan voor meer gevestigde talen,” zegt ze. “TRACTOR is een ambitieus project en zal zeer impactvol zijn als het slaagt.”

Hoewel kunstmatige intelligentie (AI) geen vereiste is voor het project, denkt Wallach van DARPA dat LLM’s vrijwel zeker deel zullen uitmaken van de oplossingen. Ze kunnen op veel verschillende gebieden bijdragen, van vertaling tot code-evaluatie tot procescontrole — er is geen juiste manier om het te doen, zegt hij.

En omdat het tempo van AI-innovatie zo hoog ligt, mag een specifieke oplossing niet afhankelijk zijn van een specifieke implementatie, voegt Wallach toe.

“Wat de stand van zaken voor LLM’s vandaag de dag ook is, ik beloof je dat er over vier jaar iets beters zal zijn. Ik weet niet wat het is, ik weet niet wie het gaat redden, maar ik weet dat die wereld vanzelf verbetert,” zegt hij. “Dus ons doel is om te kunnen profiteren van de investeringen die andere mensen doen in AI.”

Belangrijke uitdagingen om te overwinnen

De behoefte aan de oplossing om oudere LLM’s eenvoudig te kunnen verwisselen voor nieuwere, efficiëntere modellen zal waarschijnlijk problemen opleveren. De uitdagingen op het gebied van intellectueel eigendom die AI-modellen met zich meebrengen, zijn nu al aanzienlijk, zegt Chris Clark, automotive systems architect voor Synopsys’s Software Integrity Group.

“Dit roept veel vragen op over IP, gebruik, analyse en modelontwikkeling. De uitdaging zal niet zijn of er een AI-engine kan worden ontwikkeld; de uitdaging zal liggen in het juridische domein en de licenties,” zegt Clark. “De vraag over hoe mijn code wordt gebruikt en wat ervan wordt afgeleid, zal beantwoord moeten worden. Voor embedded is dit vooral belangrijk.”

DARPA realiseert zich dat de ontwikkeling van TRACTOR afhankelijk zal zijn van belangrijke innovaties in de technologie van LLM’s en broncodevertaling. Ook zal de hele oefening waarschijnlijk een aantal lastige kwesties aan het licht brengen, zoals bijvoorbeeld de vraag of het creëren van Rust-code die overeenkomt met de C-code het criterium is, of dat het systeem moet proberen de intenties van de programmeur te peilen.

“Het lijdt geen twijfel dat dit een moeilijk probleem is, en DARPA doet geen makkelijke problemen. DARPA doet moeilijke problemen,” zegt Wallach. “Het is niet genoeg om Rust-code te leveren die veilig is, maar onleesbaar en onbruikbaar. Het hele punt hiervan is dat we ontwikkelaars van C naar Rust willen laten overstappen … dus we willen dat het, voor zover mogelijk, de hoogste kwaliteit Rust is die geproduceerd kan worden.”