Die Entwickler von uutils/coreutils haben Version 0.9.0 ihrer in Rust geschriebenen Neuimplementierung der GNU Core Utilities veröffentlicht. Das Release bringt vor allem Sicherheitsverbesserungen nach einem externen Audit, weniger unsafe-Code und schnellere I/O-Pfade durch Zero-Copy-Verfahren. Zudem erweitert die neue Version die Unterstützung für WebAssembly, Windows und Cygwin.

uutils/coreutils setzt die klassischen GNU Core Utilities in Rust neu um. Das Projekt liefert zahlreiche Standardwerkzeuge von Unix- und Linux-Systemen, darunter ls, cp, mv, rm, cat und sort. Ziel ist eine möglichst hohe Kompatibilität zu den GNU-Pendants – bei gleichzeitig besserer Speichersicherheit und Wartbarkeit durch Rust.

Sicherheitsaudit deckt TOCTOU-Schwachstellen auf

Im Mittelpunkt des Releases stehen Sicherheitsverbesserungen, die auf ein Audit der Firma Zellic zurückgehen. Die Prüfer fanden vor allem TOCTOU-Schwachstellen (Time of Check, Time of Use) und Probleme bei Randfällen im Dateisystem. Bei TOCTOU-Lücken handelt es sich um Race Conditions: Der Zustand einer Datei kann sich zwischen einer Prüfung und ihrer tatsächlichen Verwendung ändern – und genau diese Lücke lässt sich ausnutzen.

Die Maintainer betonen, dass die dabei vergebenen 44 CVEs keine klassischen Speicherfehler beschreiben. Das Audit habe vielmehr Verhaltensunterschiede zu GNU Coreutils aufgedeckt, die in bestimmten Situationen sicherheitsrelevant werden können. Version 0.9.0 schließt nach Projektangaben einen Großteil dieser Befunde.

Dafür führt das Projekt ein neues Modul namens uucore::safe_copy ein, das Kopiervorgänge gegen TOCTOU-Angriffe absichert. Auch die rekursiven Operationen von cp, mv und chmod erhalten entsprechende Schutzmechanismen. rm geht robuster mit problematischen Pfadangaben wie . und .. um. nohup legt die Datei nohup.out nun mit den restriktiven Zugriffsrechten 0600 an. Und chroot löst Benutzer- und Gruppen-IDs bereits auf, bevor es in die neue Wurzelumgebung wechselt.

Weniger unsafe-Code, Umstieg auf rustix

Parallel dazu reduziert das Team weiter den Anteil an unsafe-Code. Zahlreiche Stellen in Werkzeugen, Tests und gemeinsamen Bibliotheken kommen jetzt ohne unsichere Speicher- oder Systemzugriffe aus. In vielen Bereichen ersetzt das Projekt zudem die bisher genutzten Bibliotheken nix und libc durch rustix. Diese stellt Systemaufrufe über stärker typisierte Rust-Schnittstellen bereit und vermeidet so eine Reihe typischer Fehlerquellen. Die Umstellung betrifft unter anderem id, tr, timeout, sort, wc, tail, cp und who.

Für mehr Tempo sorgen neue Zero-Copy-Datenpfade unter Linux. Mehrere Werkzeuge nutzen jetzt verstärkt die Syscalls splice(), tee() und pipe(), um Daten direkt zwischen Kernel-Puffern zu übertragen. Da die Daten dabei nicht mehr durch den Adressraum des Prozesses wandern, sinken Speicherzugriffe und CPU-Last. Profitieren sollen unter anderem cat, wc, head, tail, cp, tee, yes und unexpand. Für unexpand nennen die Entwickler einen Geschwindigkeitsgewinn von rund 7,5 Prozent. Auch cp und tee arbeiten beim Verarbeiten von Pipe-Daten spürbar schneller.

GNU-Kompatibilität: neue Referenz, mehr Tests

An der GNU-Kompatibilität arbeitet das Projekt weiter intensiv. Als Referenz dient nun GNU Coreutils 9.11 statt 9.10. Die Zahl der fehlschlagenden Tests in der GNU-Testsuite steigt dadurch von 21 auf 56 – laut Projekt jedoch ohne Regressionen. Die Ursache liegt in 25 neuen Tests, die GNU der Suite hinzugefügt hat und die uutils noch nicht vollständig besteht. Weitere Kompatibilitätskorrekturen betreffen numfmt, date, tr, cksum, factor, head, stat und sort.

Besonders umfangreich fallen die Änderungen an numfmt aus. Das Werkzeug formatiert numerische Werte jetzt präziser, weist wissenschaftliche Notation zurück und beachtet die Locale-Einstellung LC_NUMERIC für das Dezimaltrennzeichen. Hinzu kommen Anpassungen bei Rundung, Vorzeichen und der Verarbeitung mehrbytiger Suffixe.

Auch ls erhält mehrere Korrekturen und Erweiterungen. Sie betreffen symbolische Links, die Versionssortierung und die rekursive Verzeichnisauflistung. Zudem haben die Entwickler den Code so umgebaut, dass andere Programme ls als Bibliothek einbinden können, ohne dessen Ausgabe zwingend auf die Standardausgabe umzuleiten. Als Beispiel nennt das Projekt die Shell Nushell.

Mehr Plattformen, mehr Locales

Beim Plattformsupport legt Version 0.9.0 ebenfalls zu. Die Werkzeuge ln, dd, mktemp und tty laufen jetzt auch unter dem WebAssembly System Interface (WASI), das WebAssembly-Anwendungen außerhalb des Browsers standardisierten Zugriff auf Betriebssystemfunktionen erlaubt. Daneben verbessern die Entwickler die Unterstützung für Windows, MSYS2 und Cygwin und arbeiten weiter an der Portierung auf OpenBSD. Schließlich berücksichtigen jetzt auch numfmt und du regionale Einstellungen für das Dezimaltrennzeichen über LC_NUMERIC.

Alle Details zum Update finden sich in den Release Notes auf der GitHub-Projektseite.

(fo)

Im heutigen Beitrag meines C++-Blogs möchte ich auf die statische Reflexion in C++26 eingehen. Einer der großen Vorteile von Reflexion ist, dass wir die neue Funktion bereits ausprobieren können, da mit Clang ein Compiler verfügbar ist, der alle Facetten implementiert. Und auch der jüngst erschienene GCC 16 implementiert das Feature bereits.

Anhand meiner typischen Anwendungsfälle habe ich untersucht, welche Aufgaben sich mit Reflexion besser lösen lassen. Eine Aufgabe, die mich den größten Teil meiner Karriere beschäftigt hat, war das Lesen und Schreiben von Daten, die über eine Netzwerkverbindung kamen. Die Definition von „Netzwerk“ war zu verschiedenen Zeiten unterschiedlich. Gemeinsam war jedoch, dass alles, was gesendet wurde, in Netzwerk-Byte-Reihenfolge (Big-Endian) verschickt wurde, und alles, was empfangen wurde, ebenfalls in Netzwerk-Byte-Reihenfolge ankam. Für manche Systeme machte das keinen Unterschied, da sie bereits Big-Endian-Maschinen waren. Aber nicht immer. Vor allem ARM setzte auf Little-Endian. Bei einem Teil der Systeme mussten die Daten beim Empfangen oder Senden daher byteweise vertauscht werden.

Wie tauscht man Daten?

Das Problem hier (war), wie tauscht man die Daten? Jeder Datentyp, der größer als ein Byte ist, muss jedes Mal getauscht werden. C++23 hat uns std::byteswap gegeben, wodurch POSIX-Funktionen wie htons überflüssig geworden sind. Das bedeutet zumindest eine Verbesserung im Hinblick auf Sicherheit.

Fangen wir mit einem Beispiel an. Der folgende Code zeigt die Datenstrukturen, die ich heute verwende.

enum class Color16 : uint16_t
{
};

struct RGB48 {
  Color16 red;
  Color16 green;
  Color16 blue;

  auto operator<=>(const RGB48&) const = default;
};

struct LEDState {
  bool  state;
  RGB48 rgbColor;

  auto operator<=>(const LEDState&) const = default;
};

struct LEDStateMessage {
  uint32_t messageId;
  LEDState state;

  auto operator<=>(const LEDStateMessage&) const = default;
};

Wie du sehen kannst, ist die letzte Struktur LEDStateMessage später die Wurzel. Diese Struktur enthält eine Struktur, die wiederum eine Struktur enthält. Wir gehen es heute also rekursiv an.

Alle structs verfügen über einen Dreiwege-Vergleichsoperator – das erleichtert die Überprüfung.

Was ich erreichen möchte, sieht in etwa so aus:

LEDStateMessage msg{.messageId = 3,
                    .state{.state = true,
                           .rgbColor{.red   = Color16{0x5u},
                                     .green = Color16{0x28u},
                                     .blue  = Color16{0x40u}}}};

Serialize(msg);

Die Daten sollten ausgetauscht oder besser noch an Ort und Stelle serialisiert werden. Ich gehe von einem System mit Speicherbeschränkungen aus, bei dem ich es mir nicht leisten kann, doppelt so viel Speicher zu verbrauchen.

Denke jetzt mal einen Moment darüber nach, wie viel Mühe du dir in der Vergangenheit gegeben hast, damit Serialize funktioniert. Ich für meinen Teil kann sagen, dass es mich viele Stunden gekostet hat.

Reflexion zur Rettung

Bist du bereit? Okay, hier kommt es:

template
requires(not std::is_pointer_v) and std::is_trivially_copyable_v
constexpr void Serialize(T& data)
{
  if constexpr(std::is_array_v) {  // #A
    for(int i{}; i < std::size(data); ++i) { Serialize(data[i]); }

  } else if constexpr(std::is_enum_v) {  // #B
    data = static_cast(std::byteswap(std::to_underlying(data)));

  } else if constexpr(not std::is_class_v) {  // #C
    data = std::byteswap(data);

  } else {  // #D
    static constexpr auto members =
      std::define_static_array(std::meta::nonstatic_data_members_of(
        ^^T, std::meta::access_context::current()));

    template for(constexpr auto& mem : members) { Serialize(data.[:mem:]); }
  }
}

Die Implementierung von Serialize besteht aus vier Teilen. In Abschnitt #A prüft Serialize, ob es sich um ein Array handelt. Wenn der Datentyp passt, ruft die Implementierung Serialize für jedes Element des Arrays auf.

Als Nächstes prüft die Implementierung in #B, ob der Datentyp ein enum ist. In diesem Fall wird C++23s std::to_underlying zusammen mit std::byteswap verwendet, um die Bytes tatsächlich zu vertauschen.

Nun wird in #C, falls dieser Datentyp kein Klassentyp ist, std::byteswap auf die Daten angewendet.

So weit, so gut. Bisher ist das alles generischer Code, den du schon vor C++26 so schreiben konntest. Der knifflige Teil sind die Datenelemente von Klassentypen. Genau das wird in #D behandelt.

Dank der Reflexion-Fähigkeiten durchläuft die Implementierung alle Datenelemente der Klasse und ruft für jedes davon Serialize auf. Et voilà, ein hervorragender erster Entwurf einer generischen Serialisierungsfunktion.

(Matthias Parbel)

Eigentlich sagte Google im April, dass das Update auf Android 17 Beta 4 die „letzte geplante Beta“ des Entwicklungszyklus sei, bevor die Version als stabile Version veröffentlicht werde. Mit der Beta 4.1 kommt der Konzern also ein wenig überraschend um die Ecke. Zudem macht Google darauf aufmerksam, dass einige Hardwarepartner auch schon Betas für einige ihrer Geräte anbieten.

Das Update Android 17 Beta 4.1 ist den Release-Notes zufolge recht klein, steht aber für das Pixel 6 bis hin zu den Geräten der neuen Pixel-10-Serie zur Installation bereit. Der Build CP21.260330.011.A1 ist für Pixel 6/Pro/a Pixel 7/Pro bestimmt, während sich CP21.260330.011 an alle anderen Pixel-Modelle richtet.

Fehlerbehebungen im Fokus

Hinsichtlich der Neuerungen enthält die Beta 4.1 lediglich fünf kleine Fehlerbehebungen, jedoch keine neuen Funktionen. Die aus Googles Sicht wichtigsten neuen Features hatte der Konzern im Zuge der Android Show: I/O Edition am 12. Mai gezeigt – inklusive der agentischen KI Gemini Intelligence, die jedoch nur für High-End-Geräte bestimmt ist.

Google erklärt, dass es mit dem nun veröffentlichten Update ein Problem behebt, bei dem die Statusleiste fälschlicherweise keinen Signalbalken anzeigte, obwohl eine Verbindung bestand. Ebenso haben die Entwickler ein Problem mit der UI-Synchronisation gefixt, bei dem das Symbol für die Schnellsteuerung der mobilen Daten im Flugmodus aktiv blieb.

Zudem soll es keine Probleme mehr beim Anschluss externer Displays geben – zumindest sollen sie nun nicht mehr schwarz werden, wenn eine hohe Auflösung ausgewählt wird. Ebenso habe Google einen Fehler bei der Bluetooth-Audioübertragung behoben, der nach Systemunterbrechungen wie Timern zu einer Unterbrechung der Wiedergabe führte. Außerdem sollen Hörgeräte nach Inaktivität oder dem Aufladen nicht mehr automatisch aus den gekoppelten Geräten entfernt werden.

Android 17 Beta für „Partnergeräte“

Während Google seine Betas nur für seine Pixel-Modelle anbietet, macht der Konzern darauf aufmerksam, dass einige Hardwarepartner Versionen der Android-17-Beta für ausgewählte Smartphones anbieten.

Zu den Partnern zählen Honor, iQOO, Lenovo/Motorola, OnePlus, Oppo, Realme, Sharp, Vivo und Xiaomi. Interessanterweise erwähnt Google seinen engen Partner Samsung nicht, obwohl der Konzern sein Betaprogramm auf One UI 9 auf Basis von Android 17 für die Galaxy-S26-Serie gestartet hat.

Für interessierte und wagemutige Besitzerinnen und Besitzer eines der kompatiblen Modelle hat Google eine Übersichtsseite gestaltet, die zu den jeweiligen Betaprogrammen führt.

Auf den Webseiten der Partner finden Nutzer jeweils Anleitungen, wie sie die Android-17-Beta installieren können. Die meisten bieten System-Images zum Herunterladen und Flashen an, einige unterstützen derweil zusätzlich Over-the-Air-Updates (OTA), wie etwa Samsung über sein eigenes Betaprogramm.

(Andreas Floemer)