Greg Kroah-Hartman, einer der Linux-Kernel-Keeper vor kurzem erhielt einen Vorschlag in dem es heißt Es ist möglich, dass ein Rahmen für die Entwicklung von Treibern in der Sprache Rust akzeptiert wird im Kern.
Obwohl es im Moment nichts Konkretes gibt, dafür Greg Kroah-Hartman formuliert zwei Bedingungen: Eine davon ist, dass das Framework bei seiner Integration nicht standardmäßig aktiviert wird, um zu vermeiden, dass Rust nicht zum Kompilieren des Kernels benötigt wird. zweitens, dass der vorgeschlagene Ansatz echte Vorteile gegenüber denen hat, die sich aus der Verwendung der C-Sprache ergeben.
Es ist bekannt, dass der Linux-Kernel das Produkt von Entwicklungen in C-Sprachen ist und vor allem für Linus Torvalds C in erster Linie. Bei der Entwicklung der Treiber für das System wurde also die Verwendung von C.
Entwickler haben große Chancen kompromittiert die in Bezug auf die Verwaltung der Hardwareressourcen eines Computersystems die Verwendung von Rust bietet.
Und ist, dass Immer mehr Stimmen werden erhoben, um den Übergang zur Rust-Sprache zu rufen. eines davon soll C für die Materialkontrolle ersetzen.
Und genau das hat der letzte Linux-Sicherheitsgipfel getan. Sicherheitsforscher haben zusammen mit anderen auf einen der größten Sprachmängel hingewiesen C sind die Probleme im Zusammenhang mit der Speicherverwaltung - Pufferüberläufe, Zuweisungen, Zugriff auf ungültige oder freigegebene Speicherbereiche usw.
Nach Angaben des Forscherduos ist das Ergebnis von 65% der in den letzten 6 Monaten identifizierten Linux-Kernel-Schwachstellen. Die CVE-Zahlen (Common Vulnerabilities and Exposure) sind ähnlich: 15.9% der 2288 Sicherheitslücken, die den Linux-Kernel in 20 Jahren betrafen, stehen im Zusammenhang mit Pufferüberläufen.
Das Forschungsteam sprach nicht nur über die Vorteile, die Rust im Vergleich zu C bietet. Er nutzte auch die Gelegenheit, um eine Initiative zur Entwicklung eines Frameworks für die Entwicklung von Linux-Treibern vorzustellen.
Einfach ausgedrückt besteht der Aufwand darin, mit den Linux-Kernel-APIs zu arbeiten. Die Entwicklungen betreffen x86-, arm / arm64-, mips-, POWERPC-, RISC-V-, s390- und SPARC-Architekturen.
Birne Das größte Problem ist, dass nur Linus Torvalds glaubt, dass es nichts Besseres als die C-Sprache gibt zur Systemprogrammierung.
Ich muss sagen, dass ich in solchen Fragen ziemlich altmodisch bin. Der Grund, warum ich Linux und Betriebssysteme im Allgemeinen gestartet habe, ist, dass ich die Hardware wirklich mag. Ich mag es, den materiellen Aspekt zu erforschen.
Ich sage dies nicht, um zu betonen, dass ich ein Experte bin. Was ich meine ist, dass ich gerne mit der Hardware aus der Software interagiere. Unter diesem Gesichtspunkt habe ich noch keine Programmiersprache gesehen, die nur der C-Sprache nahe kommt.
Diese Aussage ist nicht nur deshalb so, weil C nützlich ist, um guten Code für den Umgang mit Hardware zu generieren. Die Verwendung von C ist auch für Menschen sinnvoll, die wie ein Computer denken. Ich denke, der Grund dafür ist, dass die Leute, die die C-Sprache entworfen haben, dies zu einer Zeit getan haben, als Compiler einfach sein mussten. zu einer Zeit, in der sich die Sprache an die erwartete Ausgabe oder das erwartete Ergebnis anpassen musste.
Wenn ich also den Code in C-Sprache lese, weiß ich, wie der Assembler-Code aussehen wird, und das interessiert mich ", sagte er vor 7 Jahren während einer seiner Reden auf der Konferenz. Intel Open Source Technologiezentrum.
Zuvor haben Sie ähnliche Vorschläge zur Einführung von C ++ verworfen im Kreis der Sprachen, die sich der Entwicklung von Treibern für Linux widmen. Insbesondere hob er die Möglichkeit hervor, die Objektorientierung mit C sauberer zu gestalten als mit C ++.
Die Initiative von Alex Gaynor und Geoffrey Thomas ist in vielerlei Hinsicht weiterhin ein großartiges Projekt. Das Forschungsteam betont beispielsweise die Notwendigkeit der Weiterentwicklung von Treibern für Dateisysteme und für bestimmte Gerätetypen.
Dann müssen wir sehen, ob Inhalt kann überzeugenra Linux-Betreuer.