ブートストラップ可能なビルド：方法と理由

今年のFree and Open Source Software Yearlyカンファレンス、通称「FOSSY」は、過去3回の開催地である米国オレゴン州ポートランドから、カナダバンクーバーのブリティッシュコロンビア大学（UBC）の広大で美しいキャンパスに移転しました。FOSSYでは、カーネル関連の深い技術的トピックから、法律やコミュニティの問題、そして「日常生活におけるFOSS」といった幅広い講演が行われました。「ツールチェーンとその他の開発ツール」トラックでは、Timothy Sample氏がブートストラップ可能なビルドに関するプレゼンテーションを行いました。これは、再現可能なビルドのいとこ（cousin）ほど広く知られていませんが、LWNは2年以上前にこのトピックを取り上げています。 簡単に言うと、ブートストラップ可能なビルドとは、もう一方の少し大きなプログラムをビルドできる小さなプログラムから始まり、それがさらに別のプログラムをビルドし、最終的に現代のLinuxユーザー空間全体が小さな種から構築されるようなビルドのことです。最終的には、今日の典型的なLinuxユーザー空間とは異なり、完全に理解された起源を持つコードが得られます。 彼は、参加者にブートストラップ可能なビルドを聞いたことがあるか、そしてその考えに一般的に馴染みがあるかどうかを尋ねることから始めました。過半数がその用語を知っており、聴衆の約半数がそれ以上のことを知っていたことに彼は感銘を受けたようでした。 彼は、約10年前にGNU Guix（彼は「geeks」と発音しました。私を驚かせました）を使い始めたときに、ブートストラップ可能なビルドへの道を歩み始めたと言いました。当時、Guixを使っているなら、それに貢献していた、と彼は笑いながら言いました。Guixは、Nixに似た（そしてインスパイアされた）「関数型パッケージマネージャー」です。GuixとNixの両方で、システム内のすべてのソフトウェアは「派生グラフ（derivation graph）」として表現されており、各プログラムのビルド方法を記述しています。特定のプログラムをビルドするためには様々な入力が必要であり、それはグラフで指定されています。各入力（そしてもちろん、入力の入力、さらにその入力など）のビルド方法もグラフで表現されています。「現代のソフトウェアには何百ものノードがあり、それは恐ろしく複雑です。」 彼はPythonプログラムの例を挙げました。当然、実行するにはPythonが必要ですが、PythonはCプログラムなので、Cコンパイラが必要です。そのCコンパイラは何か別の言語で書かれているので、その言語のコンパイラが必要になります。そして、さらに続きます。Guixはそれらすべてをグラフに収集し、それは見て探求できるオブジェクトです。「それで、誰が私のコンパイラのコンパイラのコンパイラをコンパイルしているのか、そしてどこで終わるのか疑問に思い始めます。」Debianのようなシステムでは、それは誰かがリポジトリにアップロードしたCコンパイラバイナリで終わります。Guixの場合、元の終了点は、GNUユーザー空間プログラムの250MBの静的リンクされたブロブでした。そのコードがどこから来たのかという答えは、もちろん完全には明らかではなく、Guix開発者にとっては満足のいくものではありませんでした。そのブロブは再現可能にビルドできるため良いのですが、問題全体を解決するわけではありません。 ブートストラップ可能なビルドの基本的な考え方は、事前にビルドされた成果物に依存せずにビルドできるシステムを作成することです。「これらのすでにビルドされた成果物の存在を単に仮定することなく、ゼロから現代まで到達できるでしょうか？」 ヨーグルトの古典的なレシピは、プロセスを開始するために少量のヨーグルトを必要とします。これは、今日のCコンパイラをビルドする方法と似ています。既存のCコンパイラバイナリから始めます。古い国から持ち込まれたおばあちゃんのスターターを使ってサワードウブレッドを作っているのを考えているかもしれません。「私たちは基本的に、ベル研究所から持ち込まれたデニス・リッチーのスターターでCコンパイラを作っているのです。」 もちろん、これはCだけでなく、ほとんどの言語に当てはまります。言語開発者にとっては、自分の言語が最高であるため、コンパイラやその他のツールをその言語自体で書くことで「自己ホスト」することは、ある種の誇りです。しかし、それはニワトリと卵の問題を残します。ブートストラップ可能なビルドは、その先へ進み、これらのツールを「ゼロから」ビルドするための取り組みです。 再現可能なビルドは、人々が「実際にコンピューター上で実行されているバイナリがソースコードに対応していることをより確信できる」ようにします。ユーザーは、ソースコードのセットから来たと主張するバイナリを受け取ることができますが、それが本当だとどうやって確信できるでしょうか？再現可能なビルドがあれば、ユーザーは自分でバイナリを作成し、それが提供されたものとビット・フォー・ビット同じであることを確認できます。ブートストラップ可能なビルドはまったく同じことを行いますが、異なる障害モードを処理します。再現可能なビルドが検証に失敗した場合、それはバイナリをビルドした人が、それがどこから来たのかについて嘘をついているか間違っているかのどちらかです。 ブートストラップ可能なビルドは、ケン・トンプソンが有名なチューリング賞講演「Trusting Trustを信頼することについて」で説明したような問題を回避できます。トンプソンがその講演で挙げた例は、Cコンパイラのどこに「 」の定義があるかというものでした。ソースコードを見ても定義は見つからず、単に「 」は「 」であるという循環定義が提供されるだけです。「 」をASCII 10に変換することは、Cコンパイラバイナリ自体に組み込まれています。トンプソンは講演を続け、ログインプログラムのバックドアのような、より危険なものも同様の方法でコンパイラに隠すことができると述べました。 このような欠陥は、Cコンパイラやコンパイラだけでなく、自己ホスト型のプログラムなら何でもなり得ます。この種のプログラムは、ソースコードから詳細を削除し、バイナリ形式で永続させることができます。講演の準備をしているとき、同僚が最近の論文（「バイナリ操作によるLinuxディストリビューション全体に対するTrusting-Trust攻撃」）を指摘しました。これは、この種の実際の攻撃を示しています。研究者たちは、NixOSのstripプログラムにバックドアを挿入しました。これは、システム上でビルドされるほぼすべてのバイナリで実行されます。「彼らは、ソースコード分析からは完全に不可視な方法で、システム上のほぼすべてのプログラムにバックドアを仕掛けることができました。」これが、ブートストラップ可能なビルドが阻止することを意図している攻撃の種類です。 セキュリティの側面がブートストラップ可能なビルドの最大の利点ですが、Sample氏はソフトウェアの自由の側面もあると述べました。ソースコードを読むことができるのは有用ですが、ソースコードが実行中のプログラムに対応していることを知ることも重要です。多くのプログラマーが、自分のコードを明確で理解しやすいものにすることに誇りを持っています。コードが検査可能であり、そのすべての詳細が利用可能なソースコードの本体に存在することを確認することも、その一部です。 ブートストラップを処理する最善の方法は、プロアクティブに行うことだと彼は言いました。コンパイラが自己ホストされる前に、通常は別の言語で書かれます。そのコードを保存し、自己ホスト版と並行して維持することで、バイナリに何も隠されていないことを確認する手段が提供されます。GNU Guileプロジェクトが行っているのはこれです。これは、Guixやさまざまな他のプロジェクトで使用されているSchemeの方言です。Guileは、コンパイラのブートストラップに使用できる言語のC実装もまだ持っています。GNU Makeには当然makefileがありますが、makeが利用できない場合のためにシェルスクリプトも用意されています。「私たちは、私たちが基本的なビルドツールであり、ここにもう一つの参入経路があるべきだと認識しています。」 自己ホストビルドのみをサポートするツールについては、彼やブートストラップ可能なビルドコミュニティの他の人々がそれを回避するために使用するいくつかのテクニックがあります。最初のものは「考古学的発掘」であり、プロジェクトの履歴を使用して非自己ホスト版を見つけます。そのバージョンは、当時のツールを使用してビルドされます。「それから歴史をバージョンごとに進んでいきます [...] 最新のツールに到達するまで。」時々、バージョン間のステップをスキップできることもありますが、全体としては遅いプロセスです。「ある意味では、それは単に問題を先延ばしにしているだけです。」