ソフトウェア開発者のファリド・ザカリアは2026年8月24日、Linuxシステムが実行可能として指定し、実行できるファイルにSQLiteデータベースを使用する実験的な実行ファイル形式について説明した。Structured Executable & Linkable Format（構造化実行・リンク可能形式）の略でSELFと名付けられたこの試作版は、単にELFファイルを目録化するのではなく、確立されたELFバイナリ形式をデータベースのテーブルで置き換えられるかを探るものだ。
ザカリアの前提は、ELFがすでに、複数のツールで個別に解析・シリアライズしなければならない密に詰め込まれた構造を通じて、データベースに似た処理を行っているというものだ。これに対しSELFは、実行ファイルの情報に明示的なスキーマを与える。ファイルには最低でも2つのテーブルが必要だ。ELFヘッダー情報をキーと値のペアとして表す`self_meta`と、各プログラムヘッダーにつき1つのバイナリオブジェクトとしてロードイメージを格納する`segments`である。別個のシンボルテーブルとデータベースインデックスが、従来のシンボル関連セクションや検索構造の一部を置き換える。
この手法により、検査と変更をより宣言的にできる可能性がある。試作版では、ツールだけが使用するメタデータを、プログラムの実行には必須とせず、セクション、ノート、動的エントリー用のテーブルに保存できる。そうした情報の削除はデータベースの操作とトランザクションになり、`patchelf`によるものに相当する変更は更新処理として表現できる。依存関係を調べるための情報は、専用のバイナリ解析ではなく、結合やビューを通じて提示できる。
SELFファイルは、SQLiteのバイトオフセット68にある4バイトの`application_id`フィールドによって、通常のSQLiteデータベースと区別される。NixOSでは、Linuxの`binfmt_misc`機構がSQLiteヘッダーとその識別子を照合し、ファイルを登録済みのインタープリターに渡せる。プロジェクトの`elf2self`ツールは現在、既存のELF実行ファイルからヘッダーとシンボルテーブルを抽出し、新しいデータベースに書き込むことで変換している。現時点では、コンパイラーやリンカーがSELFを直接生成することには依存していない。
実行は、SQLiteにリンクされた小さなCプログラム`self-exec`が担う。これは関連するテーブルを読み込み、ロード可能なセグメントをメモリーにマッピングし、再配置を適用して、プログラムのエントリーポイントに制御を移す。インタープリター自体はELFバイナリのままでなければならない。SELFインタープリターを同じ形式で登録すれば、再帰的な読み込みループが生じるためだ。
この試作版は動的リンクについても実験している。一つの方法は標準の`ld.so`ローダーを維持し、glibcのランタイムリンカー監査インターフェースを使って、共有オブジェクトの検索をSQL経由で指示するものだ。これにより、既存のローダーは遅延バインディング、スレッドローカルストレージ、シンボルのバージョン、間接関数といった機能を引き続き処理できる。別の方法では、動的リンカーのより多くの部分を置き換え、データベースクエリーを通じて検索とバインディングを実行する。
SELFは探究的な試みであり、既存環境にそのまま導入できる標準として提案されたものではない。そのソースは変換ツールと動作するインタープリターについて説明しているが、Linuxソフトウェア・エコシステム全体にわたる本番環境での互換性、性能、セキュリティーを確立したものではない。当面の貢献は、安定してクエリー可能なスキーマを通じてバイナリ構造を表現した場合、実行ファイル用ツールをより単純にできるかどうかを具体的に検証する点にある。
