Greg K-H: „Neuen Code in Rust zu schreiben, ist für alle von Vorteil“
(lore.kernel.org)Warum Rust in den Linux-Kernel aufgenommen werden sollte
- Auf Grundlage meiner Erfahrung aus den letzten 15 Jahren, in denen ich mir fast alle Linux-Kernel-Bugfixes und Sicherheitsprobleme angesehen habe, möchte ich erläutern, warum die Einführung von Rust notwendig ist
- Nicht jeder Bugfix wird in den Stable-Tree übernommen, aber im Allgemeinen die wichtigen, und ich bin in der Position, alle Kernel-CVEs zu prüfen
Die Grenzen von C und die Vorteile von Rust
- Die meisten Bugs, die im Linux-Kernel auftreten, gehen auf strukturelle Grenzen der Programmiersprache C zurück
- Besonders häufig sind Bugs, die durch einfache Fehler entstehen, und solche Probleme treten in Rust kaum auf
- Speicherüberschreibungen (Rust fängt nicht jeden Fall ab, kann aber einen großen Teil davon verhindern)
- Probleme beim Aufräumen von Error-Pfaden
- Nicht geprüfte Error-Werte
- Use-after-free-Bugs
- Wenn Rust in den Kernel eingeführt wird, können sich Entwickler und Maintainer von solchen grundlegenden Fehlern lösen und auf die wirklich schwierigen Probleme konzentrieren (Logikfehler, Race Conditions usw.)
Die bestehende C-Codebasis muss weiterhin gepflegt werden
- Der Linux-Kernel besteht derzeit aus mehr als 30 Millionen Zeilen C-Code, und es ist unmöglich, ihn kurzfristig durch Rust zu ersetzen
- Deshalb sind die Arbeiten zur Härtung der Sicherheit von C-Code, die von Entwicklern wie Kees und Gustavo vorangetrieben werden, unverzichtbar und müssen fortgesetzt werden
- Ideal ist nicht, dass Rust bestehenden Code ersetzt, sondern dass neuer Code (insbesondere Treiber) in Rust geschrieben wird, um Probleme zu verringern
Die API-Sicherheit, die Rust bietet
- Rust ermöglicht es, interne Kernel-APIs sicherer und einfacher nutzbar zu gestalten
- Die heutigen C-basierten Kernel-APIs sind komplex und fehleranfällig, sodass Maintainer sie oft sehr genau prüfen müssen
- Zum Beispiel gibt es mehrere Möglichkeiten, Strukturen wie
struct cdevsicher zu verwenden, und es erfordert viel Erfahrung, sie korrekt einzusetzen - Mit Rust lassen sich APIs klarer definieren, wodurch die Wahrscheinlichkeit von Entwicklerfehlern deutlich sinkt
- Das ist nicht nur für Rust-Nutzer von Vorteil, sondern auch eine hilfreiche Veränderung für Nutzer bestehender C-Codebasen
Entgegnungen auf die Sorge, dass die Einführung von Rust schwierig sein wird
- Rust ist keine Universallösung → kann aber einen erheblichen Teil der bestehenden Probleme beheben
- Mehr Belastung für Maintainer → aber die Entwickler, die Rust einführen wollen, erledigen diese Arbeit selbst
- Die Wartung einer gemischtsprachigen Codebasis ist schwierig → aber der Linux-Kernel hat bisher noch deutlich schwierigere Probleme gelöst
Fazit
- Linux ist ein Werkzeug, das unzählige Entwickler weltweit nutzen, um Probleme zu lösen,
- und wenn es nun eine Nachfrage von Entwicklern gibt, sicheren Code für Hardware schreiben zu können, darf diese nicht ignoriert werden
- Das Linux-Entwicklungsmodell ist auf eine Größe gewachsen, die niemand vorhergesehen hatte, und hat herausragende Engineering-Fähigkeiten bewiesen
- Jetzt ist es an der Zeit, mit der Einführung von Rust den Weg für mehr als 20 weitere Jahre Entwicklung zu ebnen
Wir müssen neue Technologien und Ideen annehmen und daran arbeiten, gemeinsam mit der Community erfolgreich zu sein.
24 Kommentare
Die Einführung von Rust ist wohl eine Veränderung, die sich kaum vermeiden lässt, wenn man Memory Safety berücksichtigt. Vermutlich wird man mit einem angemessenen Kompromiss versuchen, alles wieder zusammenzuführen.
Allerdings fallen mir persönlich die Schlüsselwörter von Rust nicht besonders leicht ins Auge, und wenn ich sie nach längerer Zeit wiedersehe, kann ich mich oft nicht mehr gut daran erinnern, weshalb ich einfach nicht richtig warm damit werde ;;;; Natürlich weiß ich, dass sie alle nötig sind, aber manchmal fühlt es sich an, als würde man unregelmäßige Verben im Englischen mit Gewalt auswendig lernen. Gleichzeitig ist es aber auch eine Tatsache, dass mit Rust geschriebene Ergebnisse in der Praxis weniger Probleme verursachen.....
Ich frage mich, ob es wirklich so verwerflich ist, eine noch nicht ausreichend ausgereifte Sprache nicht in den Kernel aufzunehmen. Wenn man sofort in seinem Umfeld nach Leuten sucht, die Rust wirklich sicher beherrschen, gibt es davon doch fast keine, oder? Ich denke, es ist nicht zu spät, sie erst dann aufzunehmen, wenn die Sprache etwas reifer geworden ist und sich genügend Nutzer gefunden haben, auch wenn es nicht so viele wie bei Legacy-Sprachen sein müssen.
Ich bin überzeugt, dass sich die Nützlichkeit der Sprache Rust auch dann ausreichend beweisen lässt, wenn sie nicht im Linux-Kernel eingesetzt wird.
Es ist schon erstaunlich, dass Rust in seinem heutigen Zustand überhaupt noch als „unausgereifte Sprache“ bezeichnet wird. Unabhängig davon frage ich mich aber, ob es wirklich so verwerflich ist, den Anteil unsicherer Sprachen im Kernel endlich zu verringern. Gibt es in eurem direkten Umfeld denn wirklich viele Menschen, die in C so versiert sind, dass sie sicher genug Code schreiben können, um zum Kernel beizutragen? Anstatt von C noch mehr Reife zu erwarten, scheint mir gerade jetzt nicht zu spät zu sein, wo die Anforderungen des neuen Zeitalters ausreichend klar geworden sind.
Rust ist bereits nützlich, und der Versuch, in den Kernel aufgenommen zu werden, dürfte wohl kaum dazu dienen, seine Nützlichkeit erst noch zu beweisen.
Als man sich anfangs entschied, Rust einzuführen, wird es dazu wohl Diskussionen gegeben haben.
Wenn man darüber nachdenkt, auf welcher Seite der Pool größer ist, bei C-Erfahrenen oder bei Rust-Erfahrenen, dann ist C wohl überwältigend im Vorteil.
Man könnte auch denken, dass es keine große Sache ist, wenn ein Programmierer, der das Domänenwissen bereits vollständig mitbringt, noch eine weitere Sprache lernt,
aber das Kompetenzniveau, das Leute fordern, die am Kernel arbeiten, ist dann wohl wieder eine andere Geschichte ...
Diese Meinung gefällt mir auch.
Ich kann die Behauptung überhaupt nicht nachvollziehen, er solle doch einfach einen Fork machen und gehen. Warum um alles in der Welt sollte Linus denn Linux forken und verlassen?
Gibt es Leute, die Linus sagen, er solle doch einen Fork machen und gehen? Ich glaube, ich habe in dieser Debatte niemanden so etwas sagen sehen..
Ich bin auch Rust-Nutzer, aber wenn Rust- und C-Code gemischt werden, scheint das ohne strenge Regeln dafür, bis zu welchem Umfang Rust-Code in Open Source zugelassen ist, entweder unkontrollierbar zu werden oder zumindest die Kosten für Review und Wartung enorm zu erhöhen. Deshalb halte ich es für die klügste Entscheidung, nichts zusätzlich einzubauen und stattdessen einen Fork zu erstellen.
Ich kenne mich mit dem Kernel nicht besonders gut aus, aber es wäre schön, wenn man C-Code automatisch nach Rust übersetzen könnte. Natürlich gibt es dabei nicht nur Probleme bei der Code-Übersetzung, sondern auch menschliche Faktoren.
Wenn es so viele Menschen gibt, die Rust im Kernel einführen wollen, könnten sie ihn dann nicht forken und ein neues Projekt starten? Wenn das dann ausreichend ausgereift ist, würden die wichtigsten Distributionen wohl auf einen Rust-basierten Kernel umsteigen.
Ich verstehe nicht so recht, warum sie sich gegenseitig bekämpfen.
Ich weiß nicht genau, ob Sie Erfahrung mit der Kernel-Entwicklung haben, daher bin ich mir nicht sicher, was ich dazu sagen soll.
Zunächst einmal bedeutet der Einsatz der Sprache Rust nicht, den Kernel auf Rust umzustellen. Man könnte zwar fragen, ob man nicht einfach getrennt einen weiteren Kernel bauen sollte,
aber es geht nicht darum, einen Kernel in Rust zu schreiben, sondern lediglich darum, im Kernel nur für Device-Treiber eine Rust-Wrapper-Schnittstelle zu schaffen, damit nur die Device-Treiber in Rust
entwickelt werden können. Deshalb ergibt es keinen Sinn, dafür auf ein neues Projekt zu gehen.
Ich habe keine Erfahrung mit Entwicklung im Linux-Bereich.
Anscheinend ist der Rust-Wrapper für Gerätetreiber so aufgebaut, dass er nicht vom Kernel getrennt werden kann ...
Es ist schon ziemlich ironisch, dass die Linux-Community, die toxische Ausdrucksweisen lange mit der Kernel-Stabilität gerechtfertigt hat, jetzt ausgerechnet mit „Wenn es dir nicht gefällt, dann forke es doch“ reagiert und das für eine vernünftige Antwort hält.
Ich gehöre nicht zur Linux-Community, aber ...
Ich denke nicht, dass man diese Personen und den Verfasser dieses Kommentars als dieselbe Community betrachten sollte.
Es scheint schwer vorherzusagen zu sein, ob das Ergebnis eines Forks zu einer Migration wird oder zu einer Zeit der Zersplitterung.
Auch nach dem Fork dürfte es keine besonders erfreuliche Situation sein, weiterhin Änderungen aus dem Upstream zu übernehmen.
https://de.news.hada.io/topic?id=16860
Wenn man bedenkt, dass der Realtime-Linux-Fork erst nach 20 Jahren zusammengeführt wurde, sollte man die Entscheidung für einen Fork wohl nicht mit Bedacht treffen?
Ich meinte das, als ich das gesehen habe.
Man konnte die Echtzeitfunktionalität lange als vom Kernel getrenntes Projekt pflegen, und wer sie brauchte, konnte sie übernehmen, auf den Kernel anwenden und nutzen.
Ich bin zwar Rust-Nutzer, aber der Kommentar von hgwxx7_ auf r/rust hat mich beeindruckt1.
Ich erinnere mich, dass er, wenn wegen eines Backports in die Stable-Version oder aus ähnlichen Gründen Kontakt aufgenommen wurde, trotz seines vollen Terminkalenders immer zuverlässig geantwortet hat.
„Rust ist nicht die richtige Antwort, aber näher an der richtigen Antwort als Java und Python.“ -codemaster kimc-
Hacker-News-Kommentare
Kann man solche Hasskommentare nicht melden?
Ich stimme zu.