2 Punkte von GN⁺ 2025-11-03 | 1 Kommentare | Auf WhatsApp teilen
  • Der neue C/C++-Compiler Fil-C mit Speichersicherheit zeigt eine hohe Kompatibilität mit bestehendem Code; die meisten Bibliotheken und Anwendungen funktionieren ohne Änderungen
  • Bereitgestellt werden Verfahren zum Bauen aus dem Quellcode und Installieren von Fil-C unter Debian 13 sowie ein automatisches Installationsskript, das glibc und binutils mit Fil-C neu kompiliert
  • In rund 9000 Kryptografie-Software-Mikrobenchmarks benötigt Fil-C im Vergleich zu clang das 1- bis 4-Fache an Zyklen
  • Es wird versucht, Fil-C in das Debian-Paket-Build-System zu integrieren; dazu wird eine neue ABI (amd64fil0) hinzugefügt, um Fil-C-basierte Pakete parallel installierbar zu machen
  • Fil-C verfolgt zugleich Speichersicherheit und Kompatibilität mit dem bestehenden Ökosystem und zeigt Erweiterungspotenzial für Debian-basierte Systeme

Überblick über Fil-C und erster Eindruck

  • Fil-C ist ein C/C++-Compiler mit garantierter Speichersicherheit und zeigt hohe Kompatibilität mit bestehendem Code
    • Die meisten Bibliotheken und Anwendungen funktionieren ohne Änderungen
    • In Ausnahmefällen sind Anpassungen nötig, diese sind jedoch nicht unlösbar
  • Der Autor verfolgt das Ziel, mehrere von ihm verwaltete Systeme durch einen Umstieg auf mit Fil-C kompilierten Code zu schützen
  • Testumgebung: Debian 13, AMD Ryzen 5 7640HS (6 Kerne, 12 Threads), 12 GB RAM, 36 GB Swap

Verwandte Materialien und Skripte

  • Veröffentlicht wurde ein Diff-Skript zur Prüfung, das die Unterschiede zwischen Fil-C und den übergeordneten Quellcodes (z. B. clang, glibc) vergleicht
  • Bereitgestellt wird das Skript filian-install-compiler, das Fil-C, glibc und binutils unter Debian 13 herunterlädt, kompiliert und installiert
    • Gesamtlaufzeit: 86 Minuten Echtzeit, 477 Minuten User-Zeit, 52 Minuten System-Zeit
  • Bereitgestellt wird außerdem das Skript filian-install-packages, das Debian-Quellpakete mit Fil-C baut
    • Für einige Pakete (z. B. bzip2) wurde ein erfolgreicher Build bestätigt
  • Veröffentlicht wurde ein Leistungsdiagramm Fil-C vs. clang
    • Ergebnisse aus etwa 9000 kryptografiebezogenen Mikrobenchmarks
    • Mit Fil-C kompilierter Code verbraucht im Vergleich zu clang 1- bis 4-mal so viele Zyklen

Installation und Build von Fil-C

  • Nach der Installation der benötigten Pakete mit Root-Rechten wird der Build als unprivilegierter Benutzer filc durchgeführt
  • Der Fil-C-Quellcode umfasst glibc sowie mehrere High-Level-Bibliotheken und Anwendungen
  • Build-Befehl: time ./build_all_fast_glibc.sh
    • musl ist ebenfalls wählbar, weist aber Inkompatibilitäten mit einigen Paketen auf (attr, elfutils, sed, vim usw.)
  • Tritt während des Builds ein Speichermangel auf, kann dies durch eine Erweiterung des Swap-Bereichs auf 36 GB gelöst werden
    • Verwendet wurden maximal etwa 19 GB Swap und 12 GB RAM
    • Auf einem großen Server (128 Kerne, 512 GB RAM) dauerte der Fil-C-Build 8 Minuten, der musl-Build 6 Minuten

Build zusätzlicher Bibliotheken und Anwendungen

  • Fil-C enthält build_all_slow.sh zum Bauen mehrerer Bibliotheken und Anwendungen
  • Dafür wurde das parallelisierte Skript build-parallel-20251023.py erstellt
    • Es stoppt bei Fehlern nicht, sondern führt den gesamten Build weiter aus
    • Durch paralleles Bauen lässt sich Zeit sparen
  • Auf dem System phoenix waren 60 von 61 Zielen erfolgreich (101 Minuten Echtzeit)
  • Nur libcap schlug beim Build fehl (Fehler beim Laden von liblto_plugin.so)
  • util-linux erforderte Anpassungen im Zusammenhang mit Syscalls
  • Die übrigen wichtigen Pakete (attr, bash, curl, openssl, vim usw.) wurden ohne Probleme gebaut

Zusätzlich getestete Bibliotheken und Anwendungen

  • boost 1.89.0: größtenteils funktionsfähig, einige Anpassungen im Zusammenhang mit vfork nötig
  • cdb-20251021: funktioniert normal, bei künstlichen OOM-Tests Unterschiede bei den Fehlermeldungen
  • libcpucycles, libgc (als Ersatz für gshim), libntruprime, lpeg, luv usw. wurden erfolgreich gebaut und getestet
  • Wichtige CLI-Anwendungen wie mutt, tig, w3m funktionieren ebenfalls ordnungsgemäß

Debian-Integration (Filian)

  • Unter Nutzung von Debians Multiarch-Struktur wird eine Fil-C-spezifische ABI (amd64fil0) hinzugefügt
    • Beispiel: Mit apt install bash:amd64fil0 lässt sich die mit Fil-C kompilierte Version installieren
  • Fil-C verwendet statt /usr/include ein eigenes Verzeichnis, wodurch ein Problem mit abweichenden Header-Dateipfaden entsteht
    • Das Skript filian-install-compiler passt dies auf den Debian-Standardpfad an
  • Debian-Build-Werkzeuge (dpdk-buildpackage, sbuild usw.) wurden um die Erkennung der Fil-C-Architektur erweitert
    • Dazu gehören Änderungen an /usr/share/dpkg/cputable, config.sub usw.
  • Fil-C und die Standardbibliotheken werden unter /usr/libexec/fil/amd64 abgelegt
    • Die Befehle filcc und fil++ können systemweit verwendet werden

Beispiel für den Build von Debian-Paketen

  • Das Hilfsskript fillet passt Symbole und Installationspfade von Debian-Quellpaketen an
  • Beim Build des Pakets tinycdb mit Fil-C wurden drei .deb-Pakete speziell für amd64fil0 erzeugt
    • Nach der Installation wurden mit den Befehlen nm und ldd Fil-C-Symbole (pizlonated_) und Bibliothekspfade bestätigt
    • Beim Ausführen wurde die Laufzeitschutzfunktion von Fil-C bestätigt (Ausgabe einer Meldung zum Blockieren einer „memory safety“-Verletzung)

Weitere Debian-Paket-Builds

  • libc-dev: Erstellung eines Platzhalterpakets zur Auflösung von Abhängigkeiten
  • ncurses: kann nach dem Build mit Fil-C installiert werden
  • libmd: wegen Versionsabweichungen zwischen Architekturen ist eine Neukompilierung nötig
  • readline: benötigt einen symbolischen Link für den Header-Pfad
  • lua5.4: funktioniert normal, nachdem die readline-Abhängigkeit gelöst wurde

Fazit

  • Fil-C ist ein Versuch, mehr Speichersicherheit und Kompatibilität mit dem bestehenden C/C++-Ökosystem gleichzeitig zu erreichen
  • Die Möglichkeit des Paket-Builds und der Integration in einer Debian-Umgebung wurde nachgewiesen
  • Zwar sind einige Anpassungen an Build-Skripten und Header-Pfaden nötig, doch die Kompatibilität mit den meisten wichtigen Open-Source-Paketen ist gesichert

1 Kommentare

 
GN⁺ 2025-11-03
Hacker-News-Kommentar
  • Im verlinkten Benchmark scheint Fil-C in manchen Fällen schneller als C zu sein
    Vermutlich liegt das an der Varianz von Mikrobbenchmarks, aber einige Ergebnisse wirken so schnell, dass man sich fragt, ob es ein Korrektheitsproblem gibt
  • Der Autor ist von Fil-C ziemlich beeindruckt und versucht, das gesamte Debian-System mit Fil-C neu zu bauen
    Dafür erstellt und teilt er eine GC-Shim-Bibliothek sowie Build-Skripte
  • Auf dem Server gab es nur 12 GB Swap, daher musste der Fil-C-Kompiliervorgang wegen Speichermangels mehrfach neu gestartet werden
    Nachdem der Swap auf 36 GB erhöht wurde, lief der Build normal; genutzt wurden maximal 19 GB Swap + 12 GB RAM
    Auf einem Server mit 128 Kernen und 512 GB RAM dauerte der Fil-C-Build 8 Minuten, musl brauchte 6 Minuten
    Fil-C scheint viel statische Analyse durchzuführen
    • Das könnte auch einfach am Build von LLVM+Clang selbst liegen
  • Interessant ist, dass die neu veröffentlichte 64-Bit-Version von cdb Datenbanken im Exabyte-Bereich unterstützt
    Das lässt sich unter cdb.cr.yp.to nachlesen; außerdem wird erwähnt, dass die neue cdb-Subdomain pqconnect verwendet
    • Tatsächlich hat cdb.cr.yp.to keinen NS-Record, sodass DNSCurve die zugrunde liegende Struktur ist
      pqconnect wird auf der HTTP(S)-Verbindungsebene verwendet, und beide kodieren öffentliche Schlüssel in DNS, haben aber unterschiedliche Rollen
      pqconnect bettet wie CurveCP den öffentlichen Schlüssel in einen CNAME ein
    • Laut RFC1034 kann cdb.cr.yp.to als Subdomain von cr.yp.to und yp.to betrachtet werden
      Allerdings ist der Teil pq1 kein öffentlicher Schlüssel, sondern der Hash des langfristigen öffentlichen Schlüssels des Servers
    • Die Verwendung von pqconnect gibt es schon länger, aber der CNAME von cdb.cr.yp.to scheint erst um den 21. Oktober hinzugefügt worden zu sein
      Die Notiz zu Fil-C wurde vor 3 Tagen eingereicht
      Zugehöriger Thread
    • Zur Einordnung: Vor 11 Tagen gab es dazu ebenfalls eine Diskussion
      Link zur vorherigen Diskussion
  • Ich halte das für ein großartiges Projekt
    Das Ziel scheint zu sein, die meisten C/C++-Programme sicher auszuführen, ohne sie in Rust neu schreiben zu müssen
    Ich frage mich auch, welche Rolle Epic Games dabei spielt
    • Fil-C ist eine garbage-collecting Sprache und daher viel langsamer als C
      Statt neue Software damit zu schreiben, eignet es sich eher dazu, bestehenden Code sicher zu umhüllen, ähnlich wie WASM-Sandboxing
      Fil-C erkennt Abstürze allerdings präziser
  • Ich freue mich, dass Phils Arbeit endlich die verdiente Anerkennung bekommt
    Vielleicht kann sogar Rusts unsafe-Modus etwas daraus lernen
    Besonders interessant ist der Ansatz, mit Fil-C kompilierte Abhängigkeiten statisch zu linken
    • Fil-C unterstützt derzeit allerdings kein FFI
      Da Fil-C zur Pointer-Verfolgung das gesamte Programm kontrollieren muss, passt FFI strukturell nicht dazu
  • Es gibt eine Zusammenstellung der wichtigsten Threads zu Fil-C
    Zum Beispiel: Fil-C: A memory-safe C implementation,
    Safepoints and Fil-C,
    Fil’s Unbelievable Garbage Collector usw.
    Die Debatte über Speichersicherheit zwischen 2024 und 2025 setzt sich fort
  • Für Leute, die nicht wissen, was Fil-C ist, gibt es eine Zusammenfassung
    Fil-C ist eine speichersichere, mit C/C++ kompatible Implementierung, bei der sich der Großteil des Codes fast ohne Änderungen kompilieren lässt
    Alle Speicherfehler werden als panic erkannt, und konkurrente GC und InvisiCaps sorgen für Sicherheit
    Auf der offiziellen Website gibt es eine ausführlichere Erklärung
    • Um Fil-C zu nutzen, muss man zur Laufzeit einen Garbage Collector akzeptieren
  • Es ist erstaunlich, dass das Skript build_all_fast_glibc.sh 31 GB Speicher benötigt
    Ich würde gern wissen, warum, und Fil-C selbst ausprobieren
    • Das liegt daran, dass LLVM-Build und Linking ressourcenintensiv sind
  • Es ist interessant zu sehen, wie ein berühmter Kryptograf bash und curl verwendet