Fil-C の使用に関する djb のノート

 (cr.yp.to)
2 ポイント 投稿者 GN⁺ 2025-11-03 | 1件のコメント | WhatsAppで共有
  • メモリ安全性を備えた新しい C/C++ コンパイラ Fil-C は、既存コードとの 高い互換性 を示し、ほとんどのライブラリやアプリケーションが修正なしで動作
  • Debian 13 環境で Fil-C を ソースからビルド・インストール する手順と、glibc・binutils を Fil-C で再コンパイルする 自動インストールスクリプト を提供
  • 約 9000 件の暗号ソフトウェア・マイクロベンチマーク で、Fil-C は clang 比で 1〜4 倍のサイクル数 を使用
  • Fil-C による Debian パッケージビルド体系への統合 を試み、新しい ABI（amd64fil0）を追加して Fil-C ベースのパッケージを並行インストール できる構造を提示
  • Fil-C は メモリ安全性と既存エコシステムとの互換性 を同時に追求し、Debian ベースのシステムへの拡張可能性を示す

Fil-C の概要と初期印象

  • Fil-C は メモリ安全性を保証する C/C++ コンパイラ で、既存コードとの 高い互換性 を示す
    • ほとんどのライブラリやアプリケーションが修正なしで動作
    • 例外的に修正が必要な場合でも、解決が困難なレベルではない
  • 筆者は、管理している複数のシステムを Fil-C でコンパイルされたコードへ移行 して保護することを目標としている
  • テスト環境は Debian 13、AMD Ryzen 5 7640HS（6 コア 12 スレッド）、12GB RAM、36GB スワップメモリ

関連資料とスクリプト

  • Fil-C と上位ソース（例: clang, glibc）との違いを比較する 監査用 diff スクリプト を公開
  • Debian 13 で Fil-C、glibc、binutils をダウンロード・コンパイル・インストールする filian-install-compiler スクリプトを提供
    • 全体の実行時間: 実時間 86 分、ユーザー時間 477 分、システム時間 52 分
  • Fil-C を使って Debian ソースパッケージをビルドする filian-install-packages スクリプトを提供
    • 一部パッケージ（bzip2 など）は正常にビルドできることを確認
  • Fil-C vs. clang の性能グラフ を公開
    • 約 9000 件の暗号関連マイクロベンチマーク結果
    • Fil-C でコンパイルされたコードは clang 比で 1〜4 倍のサイクルを消費

Fil-C のインストールとビルド

  • root 権限で必要なパッケージをインストールした後、非特権ユーザー filc でビルドを実行
  • Fil-C のソースには glibc および複数の高水準ライブラリ・アプリケーションが含まれる
  • ビルドコマンド: time ./build_all_fast_glibc.sh
    • musl も選択可能だが、一部パッケージ（attr, elfutils, sed, vim など）との 非互換性 が存在
  • ビルド中にメモリ不足が発生した場合は、スワップ領域を 36GB に拡張して解決
    • 最大で約 19GB のスワップと 12GB の RAM を使用
    • 大型サーバー（128 コア、512GB RAM）では Fil-C ビルド 8 分、musl ビルド 6 分を要した

追加ライブラリおよびアプリケーションのビルド

  • Fil-C には複数のライブラリとアプリケーションをビルドする build_all_slow.sh が含まれる
  • これを並列化した build-parallel-20251023.py スクリプトを作成
    • エラー発生時も中断せず、全体のビルドを継続
    • 並列ビルドにより時間短縮が可能
  • phoenix システムでは 61 個のターゲット中 60 個に成功（実時間 101 分）
  • libcap のみビルド失敗（liblto_plugin.so のロードエラー）
  • util-linux は syscall 関連の修正が必要
  • そのほかの主要パッケージ（attr, bash, curl, openssl, vim など）は問題なくビルド完了

追加でテストされたライブラリおよびアプリケーション

  • boost 1.89.0: ほとんど正常に動作し、一部で vfork 関連の修正が必要
  • cdb-20251021: 正常に動作し、人工的な OOM テストではエラーメッセージに差異あり
  • libcpucycles, libgc（gshim 代替）, libntruprime, lpeg, luv などは正常にビルド・テスト
  • mutt, tig, w3m などの主要 CLI アプリケーションも正常動作を確認

Debian 統合（Filian）

  • Debian のマルチアーキテクチャ構造を活用し、Fil-C 専用 ABI（amd64fil0） を追加
    • 例: apt install bash:amd64fil0 で Fil-C コンパイル版をインストール可能
  • Fil-C は /usr/include の代わりに独自ディレクトリを使うため、ヘッダーファイルのパス不一致問題 が発生
    • filian-install-compiler スクリプトでこれを Debian 標準のパスに調整
  • Debian ビルドツール（dpdk-buildpackage, sbuild など）に Fil-C アーキテクチャ認識を追加
    • /usr/share/dpkg/cputable, config.sub などを修正
  • Fil-C と標準ライブラリを /usr/libexec/fil/amd64 パスに配置
    • filcc, fil++ コマンドをシステム全体で利用可能

Debian パッケージビルドの例

  • fillet ヘルパースクリプトで Debian ソースパッケージのシンボルおよびインストールパスを調整
  • tinycdb パッケージを Fil-C でビルドした結果、amd64fil0 専用の .deb パッケージ 3 個を生成
    • インストール後、nm, ldd コマンドで Fil-C シンボル（pizlonated_）およびライブラリパスを確認
    • 実行時に Fil-C ランタイムの保護機能が動作することを確認（“memory safety” 違反を遮断するメッセージを出力）

追加の Debian パッケージビルド

  • libc-dev: 依存関係解決用のダミーパッケージを生成
  • ncurses: Fil-C でビルド後にインストール可能
  • libmd: アーキテクチャ間のバージョン不一致により再コンパイルが必要
  • readline: ヘッダーパスのシンボリックリンクが必要
  • lua5.4: readline 依存関係を解決後、正常動作

結論

  • Fil-C は メモリ安全性の強化と既存の C/C++ エコシステムとの互換性 を同時に達成しようとする試み
  • Debian 環境での パッケージビルドおよび統合の可能性 が実証された
  • 一部のビルドスクリプトやヘッダーパスの調整は必要だが、大半の主要オープンソースパッケージとの互換性を確保

関連記事

1件のコメント

 
GN⁺ 2025-11-03
Hacker Newsのコメント
  • リンク先のベンチマークを見ると、Fil-CがCより速く見える場合がある
    おそらくマイクロベンチマークのばらつきのせいだと思うが、一部の結果は速すぎて、正確性の問題があるのではないかと気になる
  • 投稿者はFil-Cにかなり感銘を受けており、Debianシステム全体をFil-Cで再ビルドしようと試みている
    そのためにGC shimライブラリとビルドスクリプトを作って共有している
  • サーバーのswapが12GBしかなかったため、Fil-Cのコンパイル中にメモリ不足で何度も再起動した
    swapを36GBに増やすと正常にビルドでき、最大で19GB swap + 12GB RAMを使用した
    128コア、512GB RAMのサーバーでは、Fil-Cのビルドに8分、muslに6分かかった
    Fil-Cは静的解析をかなり行っているように見える
    • それはLLVM+Clang自体をビルドする過程である可能性が高い
  • 新たに公開された64ビット版のcdbがエクサバイト級データベースをサポートする点が興味深い
    cdb.cr.yp.toで確認でき、新しいcdbサブドメインがpqconnectを使っていると述べられている
    • 実際にはcdb.cr.yp.toにはNSレコードがないため、DNSCurveが動作する構成になっている
      pqconnectはHTTP(S)接続の段階で使われ、どちらもDNSに公開鍵をエンコードするが、役割は異なる
      pqconnectはCurveCPのようにCNAMEに公開鍵を含める
    • RFC1034によれば、cdb.cr.yp.toはcr.yp.toおよびyp.toのサブドメイン(subdomain) と見なせる
      ただし、pq1の部分は公開鍵ではなく、サーバーの長期公開鍵ハッシュである
    • pqconnectの使用自体は以前からあったが、cdb.cr.yp.toのCNAMEは10月21日ごろ新たに追加されたものに見える
      Fil-C関連のノートは3日前に投稿された
      関連スレッド
    • ちなみに11日前にも関連する議論があった
      以前の議論へのリンク
  • すばらしいプロジェクトだと思う
    目標は、C/C++プログラムの大半をRustで書き直す必要なく安全に実行できるようにすることのようだ
    Epic Gamesがどう関わっているのかも気になる
    • Fil-Cはガベージコレクションベースの言語なので、Cよりかなり遅い
      新しいコードを書くというより、WASMサンドボックス化のように既存コードを安全に包む用途に向いている
      ただしFil-Cはクラッシュをより正確に検出する
  • Philの仕事がついに正当な評価を受けつつあるようでうれしい
    Rustのunsafeモードにも参考になる点がありそうだ
    特にFil-Cでコンパイルされた依存関係を静的リンクする方式は興味深い
    • ただしFil-Cは現在FFIをサポートしていない
      ポインタ追跡のためにプログラム全体をFil-Cが制御する必要があるので、FFIは構造的に適合しない
  • Fil-C関連の主要スレッドが整理されている
    例: Fil-C: A memory-safe C implementation,
    Safepoints and Fil-C,
    Fil’s Unbelievable Garbage Collector など
    2024〜2025年にかけてメモリ安全性の議論が続いている
  • Fil-Cが何なのか知らない人向けの要約
    Fil-CはC/C++と互換性のあるメモリ安全な実装で、ほとんどのコードがほぼ修正なしでコンパイルできる
    すべてのメモリエラーはpanicとして検出され、並行GCとInvisiCapsによって安全性を確保している
    公式サイトで詳しい説明を見ることができる
    • Fil-Cを使うにはランタイムでGarbage Collectorを受け入れる必要がある
  • build_all_fast_glibc.shスクリプトが31GBのメモリを要求するという点に驚く
    理由を知りたいし、自分でもFil-Cを試してみたい
    • それはLLVMのビルドとリンク処理が重いからだ
  • 著名な暗号学者がbashとcurlを使っているのが興味深い