To the English version

RustIEC nieuwsbrief (Juni 2023)

Welkom bij de eerste nieuwsbrief van het RustIEC project. Allereerst willen we de deelnemers van de eerste Rust Hands-On workshop bedanken, waarvoor we zeer goede en inzichtelijke feedback hebben ontvangen. In september zal de vervolgcursus van deze Rust Hands-On workshop plaatsvinden. Op basis van de resultaten van de vragenlijst hebben we besloten dat een gespecialiseerde cursus op een later tijdstip gericht zal zijn op embedded programmeren met Rust.

In deze nieuwsbrief geven we u updates over de voortgang van de RustIEC teams.

RPL implementatie door de Vrije Universiteit Brussel

Het VUB-team legt momenteel de laatste hand aan de implementatie en evaluatie van het Routing Protocol for Low-power and lossy networks (RPL). De implementatie is geschreven in Rust en toegevoegd aan de smoltcp TCP/IP bibliotheek, een lichtgewicht TCP/IP protocol stack. Als ingebed besturingssysteem hebben we het Embassy framework gebruikt. Beide zijn geschreven in de programmeertaal Rust.

Figuur 1: Protocol- en applicatiestack van Embassy met smoltcp en Contiki-NG.

Als eerste stap gebruikten we een simulator om de correctheid van de RPL-implementatie te evalueren. Daarna werden echte apparaten gebruikt, met name de nRF52840 ontwikkelingskit. Het te evalueren netwerk bestond uit apparaten die de smoltcp RPL implementatie met het Embassy framework draaiden en apparaten die de bekende Contiki-NG RPL implementatie draaiden, geschreven in C, die deel uitmaakt van het Contiki-NG besturingssysteem. Figuur 1 illustreert de protocolstacks voor zowel smoltcp als Contiki-NG.

De testopstelling bestond uit drie nodes, zoals weergegeven in Figuur 2. Een van de knooppunten diende als node, een ander als router en het derde als leaf node. Meerdere opstellingen werden geëvalueerd, waarbij de Contiki-NG implementatie werd gecombineerd met de smoltcp implementatie. Deze aanpak had als doel om de compatibiliteit van de Rust RPL implementatie te testen met een bestaande RPL implementatie geschreven in C.

Figuur 2: Testopstelling van nRF52840-DK's met smoltcp en Contiki-NG.

De op Rust gebaseerde RPL met smoltcp is robuust, maar vereist 145,5 KB flashgeheugen, terwijl RPL met Contiki-NG in C 47,7 KB vereist. De firmware zonder RPL heeft 117,3 KB nodig voor smoltcp en 38,1 KB voor Contiki-NG. Het is echter belangrijk om op te merken dat deze Rust-implementatie een eerste iteratie is, waardoor er voldoende ruimte is voor optimalisatie en verdere verfijning.

Het VUB-team werkte, in samenwerking met een masterstudent, aan de implementatie van het Generic Header Compression (GHC) protocol. Dit protocol dient als uitbreiding van de 6LoWPAN adaptatielaag voor IPv6. De implementatie werd ook toegevoegd aan de Rust smoltcp bibliotheek. Na de evaluatie concludeerden ze dat GHC vooral in specifieke scenario's zijn nut bewijst. IPv6-adressen maken deel uit van het woordenboek dat gebruikt wordt in het compressiealgoritme, waardoor het alleen efficiënt is wanneer de te comprimeren payload IPv6-adressen bevat.

Het VUB-team onderzoekt nu hoe de datalinklaag in Rust kan worden geïmplementeerd voor ingebedde apparaten, meer bepaald Medium Access Protocols (MAC) zoals Carrier Sense Multiple Access (CSMA) en Time Slotted Channel Hopping (TSCH). Wanneer deze protocollen in Rust worden geïmplementeerd, is er een volledige stack in een veilige programmeertaal beschikbaar voor apparaten die de IEEE 802.15.4 standaard gebruiken.

Vooruitgang op C naar Rust transpilers door KU Leuven

Het team van de KU Leuven heeft haar casestudy van de Rust voor Linux kernel afgerond. Ze hebben met succes een prototype gemaakt van een parallellepoortdriver in Rust en hebben een aantal belangrijke lessen geleerd over de interoperabiliteit van C en Rust. Je moet bijvoorbeeld nadenken over het soort beveiligingsfuncties dat je hebt toegevoegd aan de C code en of die ook moeten worden toegevoegd aan de Rust-code. Domen Puncen Kugler heeft hier een aantal interessante voorbeelden van gevonden. Ook als u een deel van uw C code vertaalt naar Rust zult u veel onveilige functies moeten gebruiken om te kunnen communiceren met de C code vanuit de nieuwe Rust code. Het is belangrijk om zulke onveilige functies in veilige functies te wikkelen die geheugenveiligheidscontroles kunnen uitvoeren voordat je Rust code simpelweg een pointer laat gebruiken die door C code werd aangeleverd. Hoewel het team van de KU Leuven hun studie van de Rust voor Linux kernel voorlopig opzij heeft gezet, houden ze belangrijke ontwikkelingen in de gaten. Bijvoorbeeld de verdere Rust-integraties in de mainline Linux kernel met de release van kernelversie 6.2. De Rust-integraties voor deze versie zijn voornamelijk low-level ondersteuningscode. Het zal nog een hele tijd duren voordat een substantiële Rust driver zal worden ondersteund door de mainline kernel.

Het team van de KU Leuven is momenteel bezig met een evaluatie van de stand van zaken op het gebied van het automatisch vertalen van C naar veiliger Rust. De drie publicaties van bijzonder belang zijn Mehmet Emre et al.'s OOPSLA 2021 paper "Translating C to Safer Rust", Bryan Tan Yao Hong's MSc thesis getiteld "From C Towards Idiomatic & Safer Rust Through Constraints-Guided Refactoring", en Hanliang Zhang et al.'s VAC 2023 paper "Ownership guided C to Rust translation". Ze bespraken de eerste twee papers op de vorige gebruikersgroepvergadering. Alledrie de publicaties hebben zeer verschillende technieken voor het transformeren van C naar veilig Rust, maar ze gebruiken allemaal C2Rust van Immunant als opstapje omdat het niet-idiomatisch, onveilig Rust kan genereren uit C code. C2Rust helpt niet om een programma veiliger te maken of te bewijzen dat een programma veilig was. Het enige waar het voor gemaakt is, is een syntactische vertaling. Deze syntactische vertaling neemt echter al wel een eerste horde weg voor iedereen die idiomatische Rust code probeert te genereren uit C code.

Omdat alle drie de publicaties C2Rust gebruiken, lijkt het begin van hun werkproces erg op elkaar. Ze volgen allemaal de workflow in Figuur 3. Ze gebruiken eerst C2Rust om onveilig Rust te genereren, daarna voegen ze hun eigen bijdrage toe in het blok Refactoring. Hoewel de papers een vergelijkbare workflow voor het omzetten delen, hebben ze verschillende manieren om de effectiviteit van hun tools te evalueren, wat het vergelijken van hun verschillende architecturen lastig maakt.

Figuur 3: Overzicht van de werking van C2Rust.

De architectuur van Mehmet Emre et al. is de meest eenvoudige. Ze transformeren simpelweg elke pointer van een specifiek type dat ze tegenkomen naar een Rust-referentie. Als de transformaties niet compileren, kijken ze automatisch naar de compilerfouten en de voorgestelde fixes en passen die toe. Dit is een zeer agressieve techniek. De architectuur die Bryan Tan Yao Hong voorstelt, is daarentegen heel precies. Ze bereiden transformaties voor op enkele zeer specifieke gevallen, zoals het transformeren van array pointers naar Rust types. Tot slot is de voorgestelde architectuur van Hanliang Zhang et al. gebaseerd op het vinden van pointers die passen in het eigendomsmodel van Rust. De basis van het idee lijkt erg op die van Immunant's eigendomsanalyse.

Na uitgebreide experimenten stelde het team van de KU Leuven vast dat alle ontwerpen veelbelovend zijn, maar dat de implementaties van deze architecturen verschillende fundamentele ontwerpfouten en tekortkomingen hebben. Het team van de KU Leuven vat momenteel de sterke en zwakke punten van de ontwerpen samen en zal dan richtlijnen en aanbevelingen formuleren die als uitgangspunt moeten dienen voor een nieuw en verbeterd ontwerp.