OpenELA startet das Projekt Kernel-lts als eine Plattform für die Zusammenarbeit von Entwicklern bei der Wartung des Linux-Kernels 4.14, nachdem die Unterstützung durch die Gemeinschaft im Januar…
Kernel-Maintainer Greg Kroah-Hartman hat bekannt gegeben, dass das Linux-Kernel-Projekt als CNA (CVE Numbering Authority) für in Linux gefundene Schwachstellen akzeptiert worden ist.
Linus Torvalds ist ohne Strom und die Linux-Kernel-Entwicklung muss ruhen. Die Ansage ist gewohnt sarkastisch.
Linus Torvalds hat die Veröffentlichung des nächsten Linux-Kernels 6.7 in das neue Jahr verlegt.
Statt wie geplant mit der Version Debian 12.3 „Bookworm“ online zu gehen, hat das Debian-Release-Team am Wochenende an einer Version 12.4 gearbeitet.
Der Linux-Kernel 6.6 wird die nächste Ausgabe mit Lo
Das Team von OpenBSD will den Syscall-Aufruf komplett aus seinem System entfernen. Das soll Exploits deutlich erschweren.
Das auf Sicherheit fokussierte Open-Source-Betriebssystem OpenBSD möchte den Systemaufruf Syscall komplett aus dem eigenen Kernel und der Standard-C-Bibliothek entfernen. Das kündigt der Begründer und Leiter von OpenBSD, Theo de Raadt, auf der Mailingliste des Projekts an und verschickt dazu auch passende Änderungsdateien. Ziel dieser tiefgreifenden Änderung ist, wie es bei dem Projekt zu erwarten ist, die Sicherheit zu erhöhen.
Mit Hilfe des Syscall-Aufrufs können die anderen Systemaufrufe des Betriebssystems indirekt über eine Zahl aufgerufen werden, die die entsprechende Assembler-Sprache der genutzten Plattform unterstützen muss. Dafür gibt es Tabellen, welche etwa im Fall von OpenBSD bis zur Gründung des Projekts zurückreichen. Die Idee des Syscall-Aufrufs ist dabei noch deutlich älter und stammt dabei aus dem originalen BSD von Anfang der 80er Jahre, ist seitdem aber auch von anderen unixartigen Systemen implementiert worden. In der Linux-Dokumentation etwa heißt es, der Aufruf sei sinnvoll für den Fall, falls der gewünschte Systemaufruf über keine eigene Wrapper-Funktion in der C-Bibliothek verfüge.
De Raadt begründet den Schritt mit dem Ziel, möglichst viele Aktionen unterbinden zu wollen, die bei der Ausnutzung einer Sicherheitslücke zum Ausführen von Code führen können. Er schreibt weiter: “Mir ist klar, dass wir niemals alle [von den Angreifern] verwendeten Mechanismen vollständig beseitigen können. Ich hoffe jedoch, dass ich die Programmierer von Angriffen dazu zwinge, immer kompliziertere Methoden zu verwenden. Gleichzeitig bedeutet dies, dass weniger Methoden verfügbar sind. Andere Methoden machen die Ausnutzung anfälliger. Dies drückt die Erfolgsquoten in den ‘statistischen Niedrigprozentbereich’.”
Weiter heißt es, der Entwickler versuche dabei zuerst, die einfachen Methoden zu entfernen und Angreifer eben zu immer komplexeren Aufgaben zu zwingen. In Zukunft sollen auch die komplexeren Aufgaben zum Ausnutzen von Sicherheitslücken unterbunden werden. Sollte die Änderung für den Syscall-Aufruf wie geplant umgesetzt werden, muss sich das Team zunächst aber um die damit verbundenen Auswirkungen auf andere Software kümmern. So müssen viele Programme angepasst werden, die den Aufruf bisher benutzt haben. Das gelte insbesondere für das Go-Ökosystem, schreibt de Raadt.
Der Beitrag OpenBSD will indirekte Systemaufrufe unterbinden erschien zuerst auf Linux-Magazin.
Die Linux-Community startet einen zweiten Versuch, das alte Microsoft-Protokoll RNDIS zu entfernen. Beim ersten Mal gab es zahlreiche Diskussionen.
Neuer Versuch, neues Glück ist offenbar die Devise von Linux-Kernel-Entwickler Greg Kroah-Hartman, der nun erneut anstrebt, das veraltete und von Sicherheitsrisiken geplagte RNDIS-Protokoll aus dem Linux-Kernel zu entfernen.
Bereits im vergangenen Jahr startete der Entwickler eine Diskussion um diesen Schritt und setzte die Änderung zunächst vorläufig auch im Code um. Kroah-Hartman musste diese aber zurücknehmen, da es zahlreiche Einsprüche gegen die Änderung gab. Das wohl größte Problem ist, dass RNDIS für viele Nutzer die wichtigste Komponente ist, um ihren Rechner per Tethering über ein Android-Smartphone mit dem Internet zu verbinden. Darüber hinaus nutzen auch Geräte wie Router weiterhin RNDIS für ihre Netzwerkverbindungen.
Die von Microsoft initiierte Remote Network Driver Interface Specification stammt aus den Zeiten von Windows XP und dient als proprietäres Protokoll, das fast ausschließlich zusammen mit USB genutzt wird. Dazu wird eine Art virtuelle Netzwerkverbindung erzeugt, die wiederum nah an die Windows-Schnittstelle für Netzwerktreiber (NDIS) angelehnt ist.
Das grundlegende Konzept von RNDIS ist darüber hinaus laut Kroah-Hartman, der unter anderem den USB-Zweig in Linux verantwortet, nicht nur unsicher und angreifbar, sondern vor allem auch nicht absicherbar. Außerdem gibt es im USB-Protokoll selbst mehrere offene und standardkonforme Alternativen zu RNDIS.
Ob sich allerdings an der Problematik in Bezug auf das Tethering seit der ersten Diskussion etwas änderte und warum Kroah-Hartman diesen neuen Versuch zum Entfernen von RNDIS unternimmt, ist derzeit noch nicht klar. So bleibt abzuwarten, ob der Patch tatsächlich in den Hauptzweig des Linux-Kernels wandern wird.
Der Beitrag Linux-Entwickler wollen RNDIS erneut rauswerfen erschien zuerst auf Linux-Magazin.
Linus Torvalds hat die Intel Shadow Stack-Unterstützung für den Linux-Kernel 6.6 angenommen. Zuvor war der von Intel als Teil ihrer Control-flow Enforcement Technology (CET) entwickelte Shadow Stack von Torvalds noch abgelehnt worden.
Torvalds hatte in der Einreichung für Kernel 6.4 Probleme bemängelt und daraufhin das Merge-Fenster für die Intel-Technologie verschlossen. Mit der CET / Shadow Stack-Unterstützung für Linux sollen ROP-Angriffe (Return-Oriented Programming) mit Tiger Lake-Prozessoren und neueren Versionen verhindert werden.
Im Pull-Request schreibt Intel-Entwickler Dave Hansen: “Dies ist die lang erwartete x86 Shadow Stack Unterstützung. Wir haben sie Ihnen zuerst für 6.4 in einer Form geschickt, die schwieriger zu überprüfen war. Seitdem haben sich die wichtigsten Deltas um pte_mkwrite() und die Dirty-Bit-Shifting-Logik gekümmert. Diese sind größtenteils unverändert gegenüber der v9-Version des Patchsets vom Juni. Es gibt noch eine letzte Korrektur, um eine spärliche Warnung zu bereinigen, aber das sollte die Codegenerierung nicht einmal beeinflussen.
Linus Torvalds hat den Shadow Stack (shstk) Code für dieses Merge-Fenster angenommen. Damit ist kommt Sicherheitsfeature für neuere Intel-CPUs und neueren AMD-CPUs mit Kernel 6.6.
Der Beitrag Torvalds akzeptiert Intels Shadow Stack-Unterstützung erschien zuerst auf Linux-Magazin.
An dem Linux-Dateisystem Bcachefs wird seit acht Jahren gearbeitet. Die Fronten sind so angespannt, dass selbst Linus Torvalds zur Ruhe aufruft.
Linux-Chefentwickler Linus Torvalds hat den ersten Release Candidate für die kommende Version 6.5 des Kernels veröffentlicht. Darin allerdings nicht enthalten ist der Code für das moderne Dateisystem Bcachefs, wie Torvalds selbst in der Ankündigung hervorhebt. Als Grund dafür gibt er eine sehr lange Diskussion der Kernel-Entwickler an, an der sich Torvalds überraschenderweise nicht selbst beteiligte. In der Release-Ankündigung ruft er allerdings explizit zur Beruhigung auf.
Tatsächlich ist die Diskussion auf der Mailingliste sehr hitzig und teils persönlich, was angesichts der positiven Veränderungen im Umgang der Community untereinander im Laufe der vergangenen Jahre durchaus ungewöhnlich ist. Hinzu kommt, dass an Bcachefs seit inzwischen etwa acht Jahren entwickelt wird, das Dateisystem selbst auch ohne offizielle Integration in den Linux-Kernel inzwischen zahlreiche Nutzer hat und die verschiedenen Funktionen laut dem Hauptentwickler Kent Overstreet als stabil angesehen werden.
Auslöser der wiederkehrenden Diskussionen rund um die Aufnahme und Umsetzung von Bcachefs ist dabei nicht der Code für das Dateisystem selbst, sondern die von Overstreet dafür angedachten Änderungen an anderen Teilen des Kernels oder Interaktionen mit anderen Subsystemen. Für derartige Änderungen braucht es üblicherweise die Zustimmung der dafür zuständigen Betreuer. Diese fühlen sich aber von Overstreet zum Teil komplett übergangen oder ignoriert.
Die Geduld zahlreicher Beteiligter, weiter mit Overstreet zu diskutieren und ihn von technischen Lösungen zu überzeugen oder schlicht auf mögliche Probleme hinzuweisen, scheint dabei inzwischen größtenteils erschöpft. Der Entwickler Christian Brauner schreibt dazu etwa: “Und es scheint so, als gäbe es keine Möglichkeit, dies in Ruhe zu regeln, sondern als sei stattdessen massives defensives Zurückdrängen erforderlich”. Der für seine zahlreichen Änderungen am Linux-Kernel bekannte Christoph Hellwig lehnt die Aufnahme außerdem direkt ab, weil die Patches weder von den betroffenen Maintainern akzeptiert worden seien und sich wohl auch niemand außer Overstreet selbst finde, der sich für den Code verbürgen könne.
Auch wenn Torvalds sich nicht direkt an der öffentlichen Diskussion beteiligt, zeigt die Nichtaufnahme des Codes, dass er diese aufmerksam verfolgt. Wie und ob sich der Aufruf zur Beruhigung von Torvalds künftig auswirkt, bleibt abzuwarten. Eine zügige Aufnahme von Bcachefs in den Linux-Kernel erscheint derweil ungewiss.
Der Beitrag Kernel-Community zerlegt sich bei Diskussion um Dateisystem erschien zuerst auf Linux-Magazin.
Im Linux-Kernel 6.1 bis 6.4 steckt ein Fehler in der Handhabung der Stack-Erweiterung, auch bekannt als “Stack Rot”. Ein unprivilegierter lokaler Benutzer könnte diesen Fehler nutzen, um den Kernel zu kompromittieren und seine Privilegien zu erweitern, schreibt der Entdecker der Lücke, Ruihan Li.
Der Maple-Tree, der für die Verwaltung virtueller Speicherbereiche zuständig sei, könne Knoten ersetzen, ohne die MM-Schreibsperre ordnungsgemäß zu erwerben, was zu Use-after-free-Problemen führe.
Da es sich bei StackRot um eine Sicherheitslücke im Linux-Kernel handle, die im Subsystem für die Speicherverwaltung stecke, betreffe sie fast alle Kernel-Konfigurationen und erfordere nur minimale Fähigkeiten, um ausgelöst zu werden, berichtet Ruihan Li. Es sei jedoch zu beachten, dass Maple Nodes mit Hilfe von RCU-Callbacks freigegeben würden, wodurch sich die eigentliche Speicherfreigabe bis nach der RCU-Gnadenfrist verzögere. Daher gelte die Ausnutzung dieser Schwachstelle als schwierig.
Seines Wissens gebe es derzeit keine öffentlich zugänglichen Exploits, die auf Use-after-free-by-RCU (UAFBR)-Fehler abzielen, schreibt Ruihan Li. Dies sei der erste Fall, in dem UAFBR-Fehler nachweislich ausnutzbar sind, auch ohne das Vorhandensein der Einstellungen CONFIG_PREEMPT oder CONFIG_SLAB_MERGE_DEFAULT.
Der Beitrag Bug in den Linux-Kerneln 6.1 bis 6.4 ermöglicht Rechteausweitung erschien zuerst auf Linux-Magazin.
Der Linux-Kernel bietet über 1500 Einstellungen, die sich während des Betriebs verändern lassen. Anstatt selbst etwa über das Tool Sysctl mühsam die Parameter auf die eigenen Bedürfnisse maßzuschneidern, übernimmt das Bpftune vollautomatisch.
Das neue Tool der Oracle-Linux-Macher läuft im Hintergrund als Deamon und überwacht die Auslastung und den Netzwerkstack des Systems. Auf Basis der dabei gesammelten Informationen passt Bpftune automatisch und kontinuierlich die Kernel-Einstellungen an. Die Überwachung des Systems erfolgt mit entsprechenden Funktionen des Berkeley Packet Filters (BPF).
Bpftune selbst ist modular aufgebaut: Der Daemon führt im Wesentlichen nur Plugins aus, die dann jeweils einen Aspekt optimieren. Dies hat gleichzeitig den Vorteil, dass man die Plugins und somit einzelne Optimierungen je nach Bedarf ein- und ausschalten kann.
Die derzeit verfügbaren Plugins manipulieren unter anderem die Sysctl-Einstellungen, die Congestion Control, die Network Namespaces, die TCP- und Net-Buffer, sowie die Neighbour- und Route-Tabellen.
Weitere Informationen zu Bpftune nebst einer kurzen Einführung liefert ein Blog-Post bei Oracle.
Der Beitrag Bpftune: Werkzeug von Oracle optimiert automatisch Kernel-Einstellungen erschien zuerst auf Linux-Magazin.
Die aktuelle Version des Linux Kernels 6.3 scheint nach Benutzerberichten die Metadaten von XFS-Dateisystemen zu zerstören. Der Linux 6.4 weist diese Probleme offenbar nicht auf.
Ausgehend von einem Bug-Report in Red Hats Bugtracker meldeten sich noch weitere betroffene Anwender und Administratoren: Nach dem Update auf den Linux Kernel ab Version 6.3.3 zerstörte dieser die Metadaten auf einem XFS-Dateisystem. Mit “xfs_repair” ließ sich das Dateisystem immerhin in einen konsistenten Zustand zurückversetzen.
Gemäß den Nutzerberichten im entsprechenden Bug-Report tritt der Fehler nicht unter Linux 6.2 und dem kommenden Linux 6.4 auf. Mittlerweile scheinen die Entwickler das Problem eingekreist und einen Patch bereitgestellt zu haben. Bis zur endgültigen Behebung sollten Nutzer eines XFS-Dateisystems die Kernel 6.3.3 und 6.3.4 meiden.
Der Beitrag Linux 6.3: Bug zerstört XFS-Dateisystem erschien zuerst auf Linux-Magazin.
Raspberry Pi OS , die offizielle Distribution für den Mini-Computer Raspberry Pi, setzt jetzt den Kernel 6.1.21 ein, darüber hinaus gibt es eine frische Firmware. Aktualisiert haben die Entwickler unter anderem Mathematica, Matlab und Chromium.
Im Einzelnen gibt es Chromium 113.0.5672.59, Matlab 23.1.0 und Mathematica 13.2.1. Letztgenannte Software gehört in der 64-Bit-Fassung jetzt auch zu den empfohlenen Anwendungen, die „rp-prefapps“ offeriert. Auf ihren Einsatz im neuen Raspberry Pi OS warten zudem der Raspberry Pi Imager 1.7.4 und RealVNC. Dessen Server kommt in Version 7.0.1.49073, der Viewer in Version 7.0.1.48981.
Geschraubt haben die Entwickler an den Kamera-Schnittstellen. So verbessert „libcamera“ unter anderem das IMX296 Sensor-Tuning. „libcamera-apps“ arbeitet beim Resampling und Enconding von Audio-Material besser mit „libav“ zusammen. Des Weiteren unterstützt der DNG-Writer 16-Bit Bayer. „picamera2“ verbessert vor allem den H.264 Encoder, dem man über einen Parameter auch zu einer vorgegebenen konstanten Qualität zwingen kann. „picamera2“ ergänzt zudem die Tags „DateTime“ und „DateTimeOriginal“ in den Exif-Daten. Sämtliche Neuerungen listen ausführlich die Release Notes auf.
Der Beitrag Raspberry Pi OS 2023-05-03 aktualisiert Kernel und Softwarepakete erschien zuerst auf Linux-Magazin.
Kernel-Maintainer Greg Kroah-Hartman hat den im Dezember veröffentlichten Kernel 6.1 zur LTS-Version gemacht. Diese Kernel-Version erhält damit Support bis Dezember 2026.
Bis zum End-of-life (EOL) erhält der Kernel 6.1 dann Patches, allerdings in der Regel nur wichtige Fehlerkorrekturen. Insbesondere bei älteren Zweigen der LTS-Versionen passiert das auch nicht sehr oft, heißt es in den Informationen zu den Kernel-Releases. Derzeit steuert Kernel 4.14 LTS auf sein Support-Ende im Januar 2024 zu. Insgesamt pflegen die Kernel-Maintainer sechs LTS-Kernel.
Übersicht der LTS-Kernel.
Kroah-Hartman und sein Mitstreiter Sasha Levin machen die Kür zum LTS-Kernel auch davon abhängig, ob sich genügend Interessenten finden, die eine jeweilige Kernel-Version länger nutzen wollen. Greg Kroah-Hartman erwartet dann auch, dass sich diese Interessenten an der Pflege beteiligen. Schon vor einiger Zeit hatte er angemahnt, dass die LTS-Arbeit durch Mithilfe von Nutzern einfacher wäre. Es würde schon genügen, so der Maintainer damals, sich an den Test der Release Candidates zu beteiligen.
Der Beitrag Kroah-Hartman kürt Kernel 6.1 zur LTS-Version erschien zuerst auf Linux-Magazin.
Der Linux-Kernel verfügt seit vergangenem Jahr über eine eigene SMB-Implementierung. Diese enthält eine sehr gefährliche Lücke – Updates stehen bereit.
Die Sicherheitsforscher des Thalium-Teams des Rüstungskonzerns Thales haben eine Sicherheitslücke in der Umsetzung des SMB-Protokolls im Linux-Kernel (Ksmbd) gefunden, die als besonders kritisch eingestuft wird. Das Team der Zero Day Initiative (ZDI) von Trend Micro vergibt für die Lücke gar den CVSS-Höchstwert 10.0. Immerhin ermögliche die Lücke das Ausführen von Code mit Kernel-Rechten (Remote Code Execution, RCE), ohne dass eine Authentifizierung notwendig sei.
Das von Samsung initiierte Kernel-Modul Ksmbd soll eine Alternative zu Samba sein, das bisher unter Linux als Standardimplementierung des SMB-Protokolls dient, welches ursprünglich aus Windows stammt. Samba läuft allerdings im Userspace, so dass Ksmbd im Gegensatz dazu die Vorteile des Kernels nutzen können soll, wie etwa eine höhere Geschwindigkeit.
Erstmals in Linux integriert wurde das Ksmbd mit Linux 5.15. Auf die Sicherheit des Linux-Kernels fokussierte Entwickler kritisierten aber schon früh die schlechte Qualität des Codes und offenbar auch fehlende Vorkehrungen, wie LWN.net berichtete. Auf Grund der vergleichsweise geringen Entwicklungszeit von Ksmbd bisher ist davon auszugehen, dass das Modul bisher wenig Verbreitung gefunden hat und die meisten Nutzer weiterhin auf Samba setzen.
Bei der nun veröffentlichten Lücke handelt es sich um einen Use-After-Free-Fehler, der offenbar automatisiert gefunden wurde. Dazu heißt es bei der ZDI: “Das Problem ergibt sich aus dem Fehlen der Validierung der Existenz eines Objekts vor der Durchführung von Operationen an dem Objekt.” Ein Patch für die Lücke wurde bereits im Juli dieses Jahres in die stabilen Zweige des Linux-Kernels integriert, die beteiligten Forscher entschieden sich aber erst jetzt zu einer koordinierten Veröffentlichung.
Der Beitrag Ksmbd: Kritische Lücke im SMB-Dienst des Linux-Kernels erschien zuerst auf Linux-Magazin.
Der Sicherheitsforscher Soenke Huster von der TU Darmstadt hat eine Pufferüberschreibung im Linux-Kernel entdeckt, die sich durch WLAN-Frames auslösen lässt. Im Zuge der Evaluierung haben Soenke Huster und Kernel-Entwickler noch weitere Lücken im WLAN-Stack des Kernels entdeckt, die Over-the-air ausnutzen lassen.
Suse-Mitarbeiter Marcus Meissner berichtet von Soenke Husters Entdeckung und den weiteren Problemen, die daraufhin durch die Arbeiten von Huster und Johannes Berg von Intel entdeckt worden seien. Insgesamt sind es nun fünf Probleme, die jeweils mit einer CVE geführt werden.
Für die Probleme habe man bereits ein Patchset eingereicht, heißt es in der Mitteilung weiter. Das sollte in den nächsten Tagen gemerged werden. Soenke Huster hat in einer weiteren Mail Details zu den Lücken aufgeführt.
Der Beitrag Sicherheitslücken im Linux-Kernel erschien zuerst auf Linux-Magazin.
Mit dem für September erwarteten Release 1.64.0 steigen die Anforderungen der Programmiersprache Rust an die Glibc und den Linux-Kernel.
Die Glibc für Rust-Toolchains, die auf Linux ausgerichtet sind, muss dann mindestens in Version 2.17 vorliegen, bislang genügte eine Version ab 2.11. Der Kernel ist ab Version 3.2 einsatzfähig, bislang war Version 2.6.32 und höher ausreichend.
Wie das Rust-Team mitteilt, gelten diese Anforderungen dann für das Ausführen des Rust-Compilers selbst, nebst anderer Rust-Werkzeuge wie Cargo oder Rustup und auch für das Ausführen von Binärdateien, die von Rust erzeugt wurden, wenn sie die libstd verwenden.
Betroffen von diesen veränderten Voraussetzungen sollten nach Meinung der Entwickler nur Anwender mit einer sehr betagten LTS-Version von Linux sein oder auch Anwender von Embedded-Hardware, die eine alte Linux-Version an Bord hat. Immerhin seien die Glibc- und Kernel-Versionen, die für die neuen Basisanforderungen verwendet werden, schon fast ein Jahrzehnt alt.
Der Beitrag Rust mit (etwas) höheren Anforderungen an Glibc und Linux-Kernel erschien zuerst auf Linux-Magazin.
Mit den aktuellen Rust-Patches für den Linux-Kernel bekommt das Projekt ein neues Programmiermodell, das es mit C so nicht gibt.
Der Betreuer des Projekts, Rust im Linux-Kernel zu etablieren, Miguel Ojeda, hat seine Patch-Serie aktualisiert und dabei erstmals Unterstützung für Netzwerk-Code umgesetzt sowie erste Arbeiten am Async-Support vorgenommen. Beides zusammen könnte ein grundlegend neues Programmiermodell im Linux-Kernel etablieren, sofern die Rust-Patches irgendwann im stabilen Hauptzweig landen.
Für die Netzwerkunterstützung sind vor allem einige sehr wichtige und grundlegende Datentypen hinzugekommen. Dazu zählen etwa Typen für IPv4- und IPv6-Adressen sowie Socket-Adressen für IPv4 und IPv6, ein Buffer für Sockets, Namensräume sowie mit TcpListener und TcpStream ein prinzipieller Ersatz für die klassischen Netzwerk-Sockets.
Darüber hinaus ist das Async-Modul von Rust auf den Linux-Kernel adaptiert worden. Damit könnte das Projekt erstmals eine in die Sprache eingebaute Möglichkeit zur asynchronen Programmierung erhalten. Das ist mit C so bisher nicht möglich. Umsetzen lassen soll sich so etwa asynchroner TCP-Socket-Code, was Ojeda auch direkt mit einem Code-Beispiel in Rust illustriert und dieses erklärt. Dazu heißt es, dass der Code sehr ähnlich zu seiner synchronen Variante sei, der sogenannte Executor aber noch fehle.
Neu zum Rust-Code hinzugekommen sind außerdem Paketfilter, einige Locking-Mechanismen, eine einfache Mutex-Variante, die weniger Funktionen als das vorhandene C-Pendant bietet, sowie ein neuer Datentyp zu Referenzzählung, der das Definieren von Wrapper für den C-Code erleichtern soll. Möglich ist mit dem Rust-Code nun auch, Dokumentationstests auszuführen. Durch Umbauarbeiten am Code lassen sich so auch Kernel-APIs testen.
Der Beitrag Programmierung: Rust im Linux-Kernel bekommt Async und Netzwerk-Code erschien zuerst auf Linux-Magazin.
Anmelden