Hoofdontwikkelaar bevestigt dat Rust-ondersteuning in Linux-kernel definitief is

De Rust-code in de Linux-kernel is een blijvertje, laat de hoofdontwikkelaar van het project weten. In 2022 werd Rust al toegevoegd aan de kernel, maar tot dusver was de ondersteuning van deze veiligere programmeertaal nog experimenteel.

De hoofdontwikkelaar van het Rust for Linux-project, Miguel Ojeda, laat weten dat het experiment is voltooid en dat de programmeertaal blijvend wordt toegevoegd aan de Linux-kernel. Hij vraagt andere kernelontwikkelaars om in de documentatie te verwijderen dat de toevoeging van de programmeertaal experimenteel is.

Hij hoopt naar eigen zeggen dat bedrijven en andere partijen nu meer gaan investeren in Rust-ontwikkeling. Hoewel het experiment is voltooid, betekent dat niet dat de werkzaamheden erop zitten. Rust werkt volgens Ojeda bijvoorbeeld nog niet voor iedere kernelconfiguratie en -architectuur.

Ojeda werkt sinds 2021 fulltime aan het Rust for Linux-project. Het ontwikkelteam wilde zorgen voor betere geheugenbeveiliging in de Linux-kernel door het mogelijk te maken om Linux-kernelmodules in Rust te ontwikkelen. De oorspronkelijke programmeertaal, C, is namelijk gevoelig voor geheugenkwetsbaarheden.

In versie 6.1 van de Linux-kernel, die in december 2022 werd uitgebracht, werd er voor het eerst ondersteuning geboden voor Rust. Destijds zei Ojeda dat als het gebruik van Rust toch niet blijkt te werken, de ondersteuning zo weer weggehaald kan worden. Sindsdien is de Rust-ondersteuning geleidelijk uitgebreid. Zo wordt momenteel gewerkt aan de op Rust gebaseerde Nova-driver, waarmee Linux-besturingssystemen in de toekomst moderne Nvidia-gpu's beter kunnen ondersteunen.

Reacties (39)

[specs2021]

"Zo wordt momenteel gewerkt aan de op Rust gebaseerde Nova-driver, waarmee Linux-besturingssystemen in de toekomst moderne Nvidia-gpu's beter kunnen ondersteunen."

Zo wordt momenteel gewerkt aan de op Rust gebaseerde Nova-, AGX- en TYR-driver ... . Waaronder dus de NVidia, Apple en Arm GPU's. Bij Apple heb ik sterk de indruk dat dit een porting-project is zonder enige input van de fabrikant, bij NVidia vermoed ik dat de fabrikant niet bijdraagt aan de open source driver (want ca 40% minder performance als de 'officiele driver'). Bij Arm volgt het project de Panthor driver in C, waarbij Rust dus een vervanging is van een bestaande driver en de Panthor driver ontwikkeld is in samenwerking met Arm.

De Panthor driver ondersteund op dit moment de Mali G610 'Valhalla' in de Rockchip rk3588 en de modernere G720 'Immortalis' Mediatek en Cix. De GPU in de Qualcomm SoC's maken gebruik van Adreno drivers van Qualcomm zelf.

Noot: Nova en TYR lijken beide te worden ontwikkeld door Collabora.

[SuperDre]

De oorspronkelijke programmeertaal, C, heeft namelijk te maken met geheugenkwetsbaarheden

Dat is dus niet waar, dat suggereert namelijk dat er altijd een kwetsbaarheid aanwezig is terwijl dat dat niet het geval is. Het verhoogd hooguit kwetsbaarheden als de ontwikkelaar zich niet bewust is van hoe die deze problemen moet voorkomen, beetje vergelijkbaar met bv SQL-injection, SQL is niet het probleem, de gebruiker is.
En Rust is ook niet heilig of fullproof.

[bwerg]

Los van dat de verhouding tussen SQL en SQL injecties anders ligt, zoals @Olaf van der Spek al aangaf, is "[taal] is niet het probleem, de gebruiker is" een dooddoener, en gewoon onjuist.

Een schilder zet ook een fatsoenlijke stellage of geschikte ladder op in plaats van een gammel keukentrapje. Als hij goed zijn best doet valt hij feitelijk misschien niet van dat keukentrapje, maar dat betekent niet dat potentiële ongelukken dus niet aan dat trapje liggen. Met een taal als Rust (of elke andere memory-safe taal) sluit je gewoon een klasse van beveiliginsproblemen uit, en in die zin zijn die problemen dus (minstens) deels te wijten aan de keuze voor memory-unsafety.

Nou is die keuze soms te verantwoorden (want er zijn meet factoren dan memory-safety), maar het verband bestaat hoe dan ook.

[Reactie gewijzigd door bwerg op 13 december 2025 20:34]

[SuperDre]

Tja, het is maar hoe je het bekijkt, C KAN gewoon 'memorysafe' gebruikt worden, maar het is aan de gebruiker om het goed te doen. Een gammele trap is niet een correcte vergelijking, want een gammele trap is echt kapot, C is dat niet. C is in dir geval de meer geavanceerde tool waar veel meer mee kan, maar waar je zelf dus meer ervaring nodig hebt om het goed te gebruiken. Rust is in dit geval meer een fiets met trainingwheels...

[dmantione]

Wat kan je niet in Rust? Serieuze vraag, het is een taal voor systeemprogrammering net als C.

[rvt1]

Ik denk dat je alles prima in Rust kunt doen. Alleen de performance halen die je zou verachten in C of C++ kan in sommige gevallen wel wat tegenvallen en kan meer moeite kosten.

Zo zijn er voorbeelden van de Rust langzamer is dan java, er zijn er natuurlijk ook zat waarbij rust sneller is.
Idiomatic Rust can heel snel langzamer worden dan verwacht, en het kan de ontwikkelaar meer tijd kosten, zeker met een C of C++ achtergrond om hetzelfde te maken in rust wat ongeveer net zo snel is...

[dmantione]

Is dat een implemetatieprobleem of een probleem van de taal? Ik val weer even terug op Pascal, omdat ik daar het meeste van weet. In Pascal is het zo de typeinformatie die je hebt heel vaak een voordeel is bij optimalisaties. Even een doodsimpel voorbeeld:

var a:1..10;

begin
[...]
if a>10 then

... in dit geval kan de compiler zien dat het om dode code gaat, terwijl dit in C niet mogelijk zou zijn. Nu lijkt dit een geknutseld en in de praktijk irrelevant voorbeeld, maar dat is het juist niet: Zodra je als compiler functies inline gaat invoegen en parameters constantes kunnen worden, stijgt de kans dat de compiler kan bewijzen dat een blok code van de ingevoegde functie niet uitgevoerd kan worden en dus kan worden weggelaten. In het voorbeeld zou bijvoorbeeld oorspronkelijk a>b hebben kunnen staan variabele b wordt door het inlinen een constante 10.

De extra type-informatie helpt de compiler in praktijk op velerlei punten om dingen te bewijzen die anders veel moeilijker bewezen kunnen worden,

[bwerg]

het is maar hoe je het bekijkt, C KAN gewoon 'memorysafe' gebruikt worden

Nu wijk je echt de gangbare definitie van "memory-safe" af.

Het hele idee van "safety" is dat het safe is, dat het niet misgaat als je even iets over het hoofd ziet. Een gammele trap kan ook prima veilig gebruikt worden, als je maar ervaring met en kennis over die trap hebt - maar is toch echt gewoon onveilig voor structureel professioneel gebruik. Waarmee ik niet zeg dat C(++) ook niet geschikt of onprofessioneel is - maar niet memory-safe.

In C(++) moet je bijvoorbeeld zelf aan bounds checking en memory-deallocatie doen. Als ik jou de code van een groot en complex project geeft en ik vraag je of die bounds checking en memory-allocatie goed gebeurt, dan is het antwoord "geen idee", tenzij je even vijf jaar de tijd neemt om in detail een volledig correctheidsbewijs te bouwen. Dat is de reden dat grote projecten dit soort bugs na jaren nog steeds hebben. Doe je datzelfde bij Rust, dan grep je naar waar expliciet het "unsafe" keyword gebruikt wordt (libraries daargelaten, maar dat zou fundamenteel ook prima moeten kunnen). en dat is het enige wat je moet bekijken. Idem voor memory-safe memory-managed talen als Java (met weer expliciete uitzondering voor expliciete zaken als JNI, waar grep doorgaans zal zeggen dat het niet gebruikt wordt).

In C(++) kun je memory-safety bugs voorkomen met vaardigheid en best practices, dat maakt C(++) niet memory-safe, net zo min als dat je python niet statisch getypeerd kan noemen als je de Hungarian notation voor types in namen gebruikt.

[Reactie gewijzigd door bwerg op 14 december 2025 08:47]

[Olaf van der Spek]

SQL is niet het probleem, de gebruiker is.

SQL injection is vooral een probleem door slechte (client/query) interfaces.

SQL is niet het probleem, de gebruiker is.

Dat wordt al decennia geroepen maar dat lost het probleem niet op.. hetzelfde geldt eigenlijk voor C (en mogelijk C++).

[baseoa]

SQL kun je met geparameteriseerde queries gebruiken

C... als je dat veilig maakt krijg je iets dat lijkt op Rust denk ik?

Als PHP-programmeur moet ik natuurlijk uitkijken wat ik zeg over "het ligt niet aan de taal maar aan de noobs die je er tegen komt" . Je hebt natuurlijk technisch gezien gelijk dat de kwetsbaarheid niet in de taal zelf zit. Daarentegen lukt het C-programmeurs nu al 30 jaar niet om bounds te checken (ook de programmeurs met 30 jaar ervaring). Dat soort fundamentele problemen ken ik bij andere talen niet in die mate, al helemaal niet met die impact. Bij XSS (wat moderne libraries ook oplossen, maar stel dat dat inherent was aan Javascript) is de ergst mogelijke uitwerking toegang tot de gegevens binnen die tab c.q. origin, en moet je de gebruiker ook eerst verleiden om op de kwetsbare pagina te geraken. Je kan dan niet zomaar alle bestanden van de computer uitlezen of een backdoor achterlaten om later weer toegang te krijgen. Met zo'n memory corruption-bug in de kernel is het in de meeste gevallen game over en is de enige veilige oplossing om alles dat op het systeem stond als gecompromitteerd te zien en opnieuw te installeren. Om al die redenen is het naar mijn idee (ik werk ook in de beveiligingsbranche dus zie er nogal wat voorbij komen) niet onredelijk om te stellen dat C "te maken heeft" met geheugenkwetsbaarheden op een manier die Rust en andere talen gewoon fundamenteel niet kennen — en als er zo'n bug gevonden wordt in de taal, dan lossen ze die centraal op. Het ligt niet aan je Python-code als daar een memory corruption plaatsvindt!

[Reactie gewijzigd door baseoa op 13 december 2025 22:31]

[lvdgraaff]

De oorspronkelijke programmeertaal, C, heeft namelijk te maken met geheugenkwetsbaarheden.

Niet de taal, maar de programmeur heeft te maken met geheugenkwetsbaarheden .

[rbr320]

De waarheid ligt zoals wel vaker het geval is in het midden. Het is de taal die de programmeur toestaat slordig met geheugenbeheer om te gaan. Rust staat het simpelweg niet toe, dus de taal is daarin wel degelijk een grote factor.

[Reactie gewijzigd door rbr320 op 13 december 2025 13:16]

[dmantione]

Het is de taal in combinatie met de runtimelibrary: strcat() strcpy() sprintf zijn bijvoorbeeld functies die buffer-overflows aanmoedigen. Je kunt in C veel oplossen door veilige functies te gebruiken, maar... ieder boek over C beschrijft bovenstaande standaardfuncties, waardoor ze gebruikt blijven worden.

[RoestVrijStaal]

Ieder boek over C beschrijft bovenstaande standaardfuncties, waardoor ze gebruikt blijven worden.

Als er één boekverbranding mag plaatsvinden. Dan is het wel een waar die boeken in het vuur gaan. En boeken waar C-code en C++-code zonder duidelijke scheiding beschreven worden.

Sowieso is het vandaag de dag niet slim om programmeerboeken te kopen.

Per halve decennia komt er weer iets nieuws in C en C++ bij waardoor oude manieren die boeken beschrijven achterhaald kunnen zijn en/of de nieuwe concepten die de aanvulling van die programmeertalen introduceren, onderbelicht blijven.

[Immutable]

Het is heel makkelijk en gevaarlijk om slechte C en C++ aan te leren ja. Omdat er letterlijk zoveel foute lessen online zijn, en foute boeken. Dat is ook het grote probleem. Je kan prima goede C++ schrijven waarvan de output vergelijkbaar of beter is dan Rust. Maar, je moet verdomde goed C++ kunnen en snappen dat de juiste pad in C++ dus een pad is met weerstand. En je heel gemakkelijk short cuts kunt nemen. En dat gebeurt dan ook...

[Wolfos]

Die namen ansich zijn ook wel een artifact uit een andere tijd. Onleesbare afkortingen, en sprintf wat niet in de verste verte beschrijft wat de functie doet. Niet verwarren met printf_s

[kdekker]

Aanmoedigen? Kom nu, dat is nooit de bedoeling geweest. Niet actief beschermen, dat is nog met enige fantasie te zeggen. Het is de ontwikkelaar die niet de moeite neemt om buffer groottes te controleren. Daarnaast was er (bijna) altijd een strncat en strncpy variant. Ik kan niet achterhalen sinds wanneer, maar iig in de ISO 1999 standaard was het er al. Dit is wel een heel oude koe.

[dmantione]

Pak er eens een moderne introductiecursus bij:

https://www.cprogramming.com/tutorial/c/lesson9.html

Strcat, strcpy... En tot de verdediging van deze cursus wordt aan het eind weliswaar een kopje "safe programming" de problematiek even kort aangestipt en strncpy even genoemd, of dat beginnende programmeurs nu zal weerhouden strcat en strcpy te vermijden? Nee, de cursus leert het ze op de verkeerde manier, dus die zullen die functies volop gaan gebruiken.

[kdekker]

Dit ziet er niet echt modern uit. Het boek van Bjarne Stroustrup ziet er soortgelijk uit en dateert uit de vorige eeuw (net als het lettertype van deze cursus). Geen echt overtuigend voorbeeld.

Het is nu eenmaal een feit dat strncpy in de taal zit. En uit C is bij mijn weten niet veel verwijderd. Microsoft heeft wel eigen grappen en grollen uitgehaald door (lang) niet aan ISO te conformeren, maar voor C++ doen ze goed mee. C staat eigenlijk stil (er zijn ook weinig nieuwe versies van de taal), maar C++ is best (na 2011) fors bijgewerkt. Eigenlijk doet zo'n beetje iedere actuele taal aan soortgelijke concepten, bijv lambda's, etc.

In die zin het wel grappig dat na 50+ jaar C nog steeds (beperkt) relevant is. Nu maar afwachten of andere talen dat halen (Java en javascript hebben ook al wat jubilea achter de rug).

[rubenvb]

C heeft ongeveer even veel "updates" gehad als C++. Dat er daar minder grote veranderingen in zitten, is voor een groot deel perspectief.
Naast de hopelijk bekende uitgaves C89, C11, (C17) en C23, zijn er tal van TR's en corrigendums: https://en.cppreference.com/w/c/language/history.html
Als je dan vergelijkt met C++, die van C++98, over (03,) 11, (14,) 17, 20, (23,) en binnenkort 26 gaat, is dat niet zo heel verschillend vind ik... Vooral als je de scope van beiden in gedachten houdt (C is als taal en library vele malen kleiner dan wat C++ ambieert te verwezenlijken).

[kdekker]

Ik was me niet van bewust dat er voor C ook zoveel veranderd was. Dank voor de aanvulling.

Iig ben ik voor C nooit (na C89) tegen incompatibiliteiten aangelopen en voor C++ wel. C is inderdaad veel kleiner. Het C++ boek is inmiddels al zo dik, dat waarschijnlijk maar weinig mensen zijn die de hele (recente) standaarden 100% kennen. Voor C is dat beter te behappen. Op werk speelt C nog maar een rol in de marge (waar uiteraard onder de motorkap in de C++ runtime nog een heel stuk C zit, waar je verder weinig van merkt).

[Sandor_Clegane]

unsafe.

[Foske76]

Eens. ik vind het ook moeilijk om te zeggen of Rust de oplossing is. Het feit dat Rust het 'unsafe' keyword keihard nodig heeft om low level gebruikt te kunnen worden zegt eigenlijk al genoeg. Op kernel level (device driver level) loop je regelmatig te knoeien met pointers, en met data waarvan je geen idee hebt hoe lang hij is. Je gaat gaten in je beveiliging nodig hebben...

Daarnaast, als ik lees dat men een nieuwe SSH cliënt in Rust gaat schrijven is mijn eerste gedachte: de oude mag dan wel in C(++)geschreven zijn, maar die is wel volwassen, gerijpt. En dat is net zo belangrijk als de taal waarin iets geschreven is.

[rbr320]

Dat laatste ben ik het zeker mee eens, maar bedenk wel dat er dus over tientallen jaren allerlei bugs zijn gevonden en opgelost die eigenlijk voorkomen hadden kunnen worden. Nieuwe features en dus code levert ook weer nieuwe bugs op in de toekomst. Dus ik snap de wens wel om zo'n groot en belangrijk project in een memory safe programmeertaal te herimplementeren. Het lastige is om voor zoiets voldoende draagvlak te creëren.

[Oudecomputer]

Vers van de pers

Rust programmers re-wrote a portion of the Linux kernel in Rust. That Rust code had a crashing vulnerability in an "unsafe" chunk of code... which Linux is littered with.

More from The Lunduke Journal:
https://lunduke.com/​

Meerdere unsafe calls werden gemaakt in rust. Dus het is een broodje aap dat Rust het niet toe laat. Het ligt gewoon aan de programmeurs die in rust gewoon dingen niet netjes programmeren en dicht timmeren. Ja het kost wat extra werk.

[rbr320]

Als je wilt gaan muggenziften, prima.

Ten eerste leek het me evident dat ik bedoelde dat Rust bij normaal gebruik geen geheugenkwetsbaarheden toe laat in de code, daar ging namelijk de hele discussie over. Natuurlijk, als je de "unsafe" methode gaat gebruiken is alles mogelijk en een kernel is helaas een plek waar je regelmatig onveilige code nodig hebt. Zorg er dan echter wel voor dat je snapt welke risico's je neemt en beschrijf deze eventueel zodat anderen die naar je code kijken het ook snappen. Het is in Rust zelfs gebruikelijk om deze "safety comments" toe te voegen.

Daarnaast betreft deze bug een race condition wat niet zuiver een probleem met geheugenbeheer is, zoals een buffer overflow of een use-after-free dat wel zijn. Evengoed had de Rust compiler deze bug in "safe" code opgemerkt en je een waarschuwing gegeven.

Hier is een video van iemand die het waarschijnlijk beter uitlegt dan die sensatiezoekende Lunduke.

[SG]

Het probleem met C C++ is dat ervaren programmeurs de neiging hebben om wild te gaan met pointer truckjes. En er dus ook heel veel legacy code is.

Nieuw C C++ zijn er guidlines maar ivm legacy kan je altijd de oude trucjes blijven doen.

Je hebt nu ranges maar je kan nog steeds C style Array doen in C++23.


Herb Stuart ? Heeft front-end voor C++2X en noemt het C++2 wat safety meer enforced. Is niet officieel.

[Olaf van der Spek]

Herb Stuart ?

Herb Sutter?

https://herbsutter.com/

[SG]

Ja die

[Argantonis]

Mensen maken nou eenmaal fouten. Ook hele ervaren programmeurs. Het onderscheid dat je maakt heeft gewoon geen waarde in de praktijk.

[Rob vd Hoeven]

Ik vraag me af of de voordelen van Rust in de zeer nabije toekomst nog zo uniek zijn. Ik verwacht dat C en C++ code in de toekomst door AI zeer effectief op potentiële geheugenlekken en buffer overruns kan worden gecontroleerd waardoor C en C++ code net zo veilig zal zijn.

Probleem met Rust is dat alleen een programma dat volledig in Rust geschreven is de unieke voordelen heeft. Zolang een Rust programma nog gebruik moet maken van niet-Rust code zullen geheugenlekken en buffer overruns mogelijk zijn.

[Daco]

en daarom zijn ze enkel kernel components (of modules) aan het schrijven en overzetten naar rust.

een component of module kan je zien als zijn eigen programma binnen de kernel die met de echte kernel zelf communiceert over een api/messaging. info : Wikipedia: Rust for Linux

zie het als volgt. je doet een fopen (file open) van device x in je programma. die doet een syscall die de kernel opvangt (via glibc) en ziet dat je device x wilt open doen. die stuurt de open message/command door naar de component/module van device x via de component/module interface die het zelfde is voor alle linux drivers en components. dat zijn 3 verschillende lagen die alle 3 in verschillende talen kunnen zijn. je fopen kan C++ zijn, de kernel is dan C en je device x component kan volledig rust zijn en alles van rust gebruiken.

[Immutable]

Moet je wel duidelijke compiler output hebben. Zodat de LLM cycle die closed loop is dan goed werkt. Rust werkt juist veeeeel beter met LLM omdat de output van de compiler veel betere hinst geeft aan de LLM context window. Veel beter dan C en C++, welke dus de LLM op een dwaalspoor kan zetten.

[Reactie gewijzigd door Immutable op 13 december 2025 18:28]

[roel0]

Ik vind dat rust in hetzelfde bootje ziek is als andere niet-C talen: Te veel features. Elke C-code is leesbaar door elke deftige C developer. Echter rust en bv C++ hebben zoveel features dat geen enekel developer dit volledig machtig kan zijn.

[punishedbrains]

Volgens mij ontbreekt het daar juist aan in Rust, vandaar de vele crates die je nodig hebt, iets wat ik niet echt snap trouwens. Als je dan een taal opnieuw begint, waarom dan javascript e.d. nadoen als het ware wat dat betreft.

[RoestVrijStaal]

Met het drama van BcacheFS in het achterhoofd, vraag ik me af of er niet te snel gehandeld is.

Sinds de introductie van Rust in de kernel in 2021, zijn we pas ~4 jaar verder.

[Prince]

Rust en Golang zijn erg geschikte talen om code voor lambda's te schrijven.
Nodejs is ook goed voor veel doeleinden, maar toch langere cold start en trager dan de 2 hierboven....

[RoestVrijStaal]

Huh? Het gebruik van een anonieme functie als hard criterium is merkwaardig.

[mocean]

Ik begrijp niet goed waarom de kernel Rust moet ondersteunen, als er gecompileerd wordt?