Notes de djb sur l’utilisation de Fil-C

• Fil-C, un nouveau compilateur C/C++ doté de sécurité mémoire, montre une forte compatibilité avec le code existant, et la plupart des bibliothèques et applications fonctionnent sans modification
• Fournit la procédure pour compiler depuis les sources et installer Fil-C sur Debian 13, ainsi qu’un script d’installation automatisé pour recompiler glibc et binutils avec Fil-C
• Sur environ 9 000 microbenchmarks de logiciels cryptographiques, Fil-C utilise 1 à 4 fois plus de cycles que clang
• Tente une intégration au système de build des paquets Debian avec Fil-C, en ajoutant un nouvel ABI (amd64fil0) pour permettre une installation en parallèle de paquets basés sur Fil-C
• Fil-C vise à concilier sécurité mémoire et compatibilité avec l’écosystème existant, tout en montrant son potentiel d’extension aux systèmes basés sur Debian

---

Vue d’ensemble de Fil-C et premières impressions

• Fil-C est un compilateur C/C++ garantissant la sécurité mémoire, avec une forte compatibilité avec le code existant
  • La plupart des bibliothèques et applications fonctionnent sans modification
  • Même dans les cas exceptionnels où des changements sont nécessaires, ils ne semblent pas particulièrement difficiles à résoudre
• L’auteur vise à protéger plusieurs systèmes qu’il administre en les faisant passer à du code compilé avec Fil-C
• Environnement de test : Debian 13, AMD Ryzen 5 7640HS (6 cœurs, 12 threads), 12 Go de RAM, 36 Go de swap

Ressources et scripts associés

• Publication d’un script de diff d’audit comparant Fil-C à ses sources amont (par ex. clang, glibc)
• Fournit le script filian-install-compiler pour télécharger, compiler et installer Fil-C, glibc et binutils sur Debian 13
  • Temps d’exécution total : 86 minutes réelles, 477 minutes CPU utilisateur, 52 minutes CPU système
• Fournit le script filian-install-packages pour compiler des paquets source Debian avec Fil-C
  • Certains paquets (comme bzip2) sont confirmés comme compilant correctement
• Publication d’un graphique de performance Fil-C vs. clang
  • Résultats d’environ 9 000 microbenchmarks liés à la cryptographie
  • Le code compilé avec Fil-C consomme 1 à 4 fois plus de cycles que clang

Installation et compilation de Fil-C

• Après installation des paquets nécessaires avec les privilèges root, la compilation est effectuée avec l’utilisateur non privilégié filc
• Les sources de Fil-C incluent glibc ainsi que plusieurs bibliothèques et applications de haut niveau
• Commande de build : time ./build_all_fast_glibc.sh
  • musl peut aussi être choisi, mais présente des incompatibilités avec certains paquets (attr, elfutils, sed, vim, etc.)
• En cas de manque de mémoire pendant le build, le problème a été résolu en étendant le swap à 36 Go
  • Utilisation maximale d’environ 19 Go de swap et 12 Go de RAM
  • Sur un gros serveur (128 cœurs, 512 Go de RAM), le build de Fil-C prend 8 minutes et celui avec musl 6 minutes

Build de bibliothèques et applications supplémentaires

• Fil-C inclut build_all_slow.sh pour compiler plusieurs bibliothèques et applications
• Un script build-parallel-20251023.py a été écrit pour le paralléliser
  • Le build complet continue sans s’arrêter en cas d’erreur
  • La compilation parallèle permet de réduire le temps total
• Sur le système phoenix, 60 cibles réussissent sur 61 (101 minutes réelles)
• Seule libcap échoue à la compilation (erreur de chargement de liblto_plugin.so)
• util-linux nécessite des modifications liées aux syscalls
• Les autres paquets majeurs (attr, bash, curl, openssl, vim, etc.) se compilent sans problème

Bibliothèques et applications supplémentaires testées

• boost 1.89.0 : fonctionne globalement bien, avec quelques correctifs nécessaires autour de vfork
• cdb-20251021 : fonctionne correctement, avec une différence de message d’erreur dans un test OOM artificiel
• libcpucycles, libgc (en remplacement de gshim), libntruprime, lpeg, luv se compilent et passent les tests correctement
• Des applications CLI importantes comme mutt, tig, w3m fonctionnent également correctement

Intégration à Debian (Filian)

• Exploite la structure multi-architecture de Debian pour ajouter un ABI dédié à Fil-C (amd64fil0)
  • Exemple : apt install bash:amd64fil0 permet d’installer une version compilée avec Fil-C
• Fil-C utilise son propre répertoire au lieu de /usr/include, ce qui crée un problème de décalage des chemins de fichiers d’en-tête
  • Le script filian-install-compiler l’ajuste vers les chemins standard Debian
• Ajout de la reconnaissance de l’architecture Fil-C dans les outils de build Debian (dpdk-buildpackage, sbuild, etc.)
  • Modifications de /usr/share/dpkg/cputable, config.sub, etc.
• Fil-C et les bibliothèques standard sont placés dans /usr/libexec/fil/amd64
  • Les commandes filcc et fil++ peuvent être utilisées à l’échelle du système

Exemple de build de paquet Debian

• Le script auxiliaire fillet ajuste les symboles et les chemins d’installation des paquets source Debian
• Le résultat du build du paquet tinycdb avec Fil-C est la génération de 3 paquets .deb dédiés à amd64fil0
  • Après installation, les commandes nm et ldd permettent de vérifier les symboles Fil-C (pizlonated_) et les chemins des bibliothèques
  • À l’exécution, le fonctionnement des protections runtime de Fil-C est confirmé (affichage d’un message bloquant une violation de « memory safety »)

Builds Debian supplémentaires

• libc-dev : création d’un faux paquet pour résoudre les dépendances
• ncurses : peut être compilé puis installé avec Fil-C
• libmd : recompilation nécessaire à cause d’un décalage de version entre architectures
• readline : nécessite un lien symbolique pour le chemin des en-têtes
• lua5.4 : fonctionne correctement après résolution de la dépendance à readline

Conclusion

• Fil-C est une tentative de concilier renforcement de la sécurité mémoire et compatibilité avec l’écosystème C/C++ existant
• La possibilité de build et d’intégration de paquets dans un environnement Debian est démontrée
• Quelques ajustements restent nécessaires dans certains scripts de build et chemins d’en-tête, mais la compatibilité avec la plupart des grands paquets open source est acquise

[GN⁺]

Commentaire Hacker News

• En regardant le benchmark lié, il arrive que Fil-C paraisse plus rapide que C
  C’est probablement dû à la variabilité des microbenchmarks, mais certains résultats semblent tellement rapides qu’on se demande s’il n’y a pas un problème de justesse
• L’auteur est suffisamment impressionné par Fil-C pour tenter de reconstruire tout le système Debian avec Fil-C
  Pour cela, il crée et partage une bibliothèque shim GC ainsi que des scripts de build
• Le serveur n’avait que 12 Go de swap, donc la compilation de Fil-C a redémarré plusieurs fois faute de mémoire
  Une fois le swap porté à 36 Go, le build s’est déroulé normalement, avec un pic à 19 Go de swap + 12 Go de RAM
  Sur un serveur de 128 cœurs et 512 Go de RAM, le build de Fil-C a pris 8 minutes, contre 6 minutes pour musl
  Fil-C semble effectuer beaucoup d’analyse statique
  • Il est possible que cela vienne surtout du processus de build de LLVM+Clang lui-même
• Il est intéressant de voir que la nouvelle version 64 bits de cdb prend en charge des bases de données à l’échelle de l’exaoctet
  On peut le vérifier sur cdb.cr.yp.to, et il est mentionné que le nouveau sous-domaine cdb utilise pqconnect
  • En réalité, cdb.cr.yp.to n’a pas d’enregistrement NS, donc le mécanisme repose sur DNSCurve
    pqconnect est utilisé à l’étape de connexion HTTP(S), et même si les deux encodent une clé publique dans le DNS, leur rôle diffère
    pqconnect inclut la clé publique dans le CNAME, à la manière de CurveCP
  • Selon la RFC1034, cdb.cr.yp.to peut être considéré comme un sous-domaine (subdomain) de cr.yp.to et de yp.to
    En revanche, la partie pq1 n’est pas une clé publique mais le hash de la clé publique long terme du serveur
  • L’usage de pqconnect existait déjà auparavant, mais le CNAME de cdb.cr.yp.to semble avoir été ajouté récemment, autour du 21 octobre
    Les notes liées à Fil-C ont été soumises il y a 3 jours
    Fil connexe
  • Pour référence, il y a aussi eu une discussion liée il y a 11 jours
    Lien vers la discussion précédente
• Je trouve que c’est un projet formidable
  L’objectif semble être de permettre à la plupart des programmes C/C++ de s’exécuter en sécurité sans devoir être réécrits en Rust
  Je me demande aussi quel est le lien avec Epic Games
  • Fil-C est un langage à garbage collection, donc il est bien plus lent que C
    Plutôt que d’écrire du nouveau code, il convient davantage à l’encapsulation sécurisée de code existant, un peu comme le sandboxing WASM
    En revanche, Fil-C détecte les crashs avec plus de précision
• Je suis heureux de voir que le travail de Phil reçoit enfin la reconnaissance qu’il mérite
  Il y a peut-être aussi des enseignements à en tirer pour le mode unsafe de Rust
  En particulier, l’idée de lier statiquement des dépendances compilées avec Fil-C est intéressante
  • Mais Fil-C ne prend actuellement pas en charge le FFI
    Comme Fil-C doit contrôler l’ensemble du programme pour assurer le suivi des pointeurs, le FFI ne s’intègre pas bien à son architecture
• Les principaux fils sur Fil-C ont été récapitulés
  Par exemple : Fil-C: A memory-safe C implementation,
  Safepoints and Fil-C,
  Fil’s Unbelievable Garbage Collector
  La discussion sur la sécurité mémoire se poursuit entre 2024 et 2025
• Un résumé est donné pour ceux qui ne savent pas ce qu’est Fil-C
  Fil-C est une implémentation à sécurité mémoire compatible avec C/C++, et la plupart des codes se compilent presque sans modification
  Toutes les erreurs mémoire sont détectées sous forme de panic, et la sécurité est assurée par un GC concurrent et InvisiCaps
  Des explications plus détaillées sont disponibles sur le site officiel
  • Pour utiliser Fil-C, il faut accepter un Garbage Collector à l’exécution
• Il est surprenant que le script build_all_fast_glibc.sh exige 31 Go de mémoire
  J’aimerais savoir pourquoi, et essayer Fil-C moi-même
  • C’est parce que le build et l’édition de liens de LLVM sont lourds
• Il est intéressant de voir un cryptographe célèbre utiliser bash et curl
  • En réalité, curl | bash peut parfois être acceptable
    Article connexe