静的LinuxバイナリでGPUドライバを動かす「SoLo」登場
Solo – a .so loader for static Linux binaries
SoLoは、完全に静的なLinuxバイナリに、実行時にホストのglibcベースのGPUドライバをロードする機能を提供する。独自のELFローダーとglibc ABIブリッジを備え、VulkanやOpenGLのドライバを利用可能にする。デモでは、静的なVulkan実行ファイルがホストのドライバをロードし、コンピュートシェーダーを実行してPNGを生成する。CIでは、Debianパッケージの上位1000の共有ライブラリをロードしてテストしている。
ドライバはホストに残し、それ以外はすべてあなたが出荷する。
HNでの議論
235- comex
これは大きな前方互換性リスクです。glibcが新しいシンボルを追加し、その後GPUドライバがそのシンボルへの依存を追加したとします。ユーザーは古い実行ファイルを更新されたGPUドライバで実行したいと考えています（古いGPUドライバが自分のGPUをサポートしていないかもしれません）。通常、これは問題なく動作します。ユーザーは新しいglibcを使用する必要があり、それは新しいGPUドライバと古い実行ファイルの両方と互換性があります。しかし、あなたのアプローチでは、GPUドライバは実行ファイルに静的にリンクされたglibcの再実装を使用せざるを得ません。実行ファイルは古いため、新しいシンボルを実装することは不可能です。
同じ問題は、glibcが既存のシンボルの新しいバージョンを追加し、GPUドライバが再コンパイルされた場合にも発生します。（あるいは、GPUドライバがglibcが常にサポートしているが、あなたが再実装したサブセットに含まれていないシンボルへの依存を追加した場合にも発生しますが、理論的には100%のシンボルを再実装すれば解決できるかもしれません。）
- pjmlp
つまり、ELFが発明される前にUNIXシステムが動的ロードを導入し始めた頃の、パッチされたa.outファイルを再発明しているのでしょうか？
静的リンクの支持者たちは、かつてUNIXが静的リンクのみだったこと、その後オーバーレイがあり、最終的に動的リンクが登場したことを忘れ続けています。
- nomel
muslについてはあまり詳しくありません。
> GPU: VulkanとOpenGLドライバはホストから共有オブジェクトとして提供され、通常はglibcに対してビルドされており、完全に静的なmuslバイナリは通常それらをdlopen()できません。
なぜですか？人々は共有ライブラリの古代の概念を壊してしまったのでしょうか、そしてこれはそのための修正なのでしょうか？
- eqvinox
自分でELFローダーを理解できるなら、これを必要としない部分的に静的な実行ファイルをビルドする方法も理解できるはずです。静的リンクと動的リンクを混在させることができます。それを中心としたビルドツールがただひどいだけです。
- pg83
これが先行技術とどう違うか（優れているか）- https://github.com/pg83/solo#how-this-differs-from-prior-wor...
- sieve
数年ごとに、私はプログラミング言語開発の趣味を再訪しますが、今回は命令燃料を使ったプリエンプティブスケジューリングを備えた言語/ランタイムを作ることにしました。いつもフリースタンディングビルドをしていますが、今回はネイティブFFIもサポートしたいと思いました。
そのとき、私は（g）libcの真の恐怖に気づきました。それはライブラリ/プログラムのルートに自分自身を注入したがり、スレッドからdlopen/dlsymまで、すべてに影響を与えます。私は多くの回避策を試しましたが、自分でローダーを実装しようとすることも含めて、複雑さ（と脆弱性）が大きくなりすぎて、価値がないと感じました。
最終的に、私はフリースタンディングランタイム+システムコールの安全な世界に撤退しました。FFIは、もし必要なら、何らかのIPCを介して行われます。glibcにリンクされた別のプロセスが、クリーンな最初のプロセスの代わりに呼び出しを管理します。
- rfgplk
私は同じことをmicronのために（多かれ少なかれ）実装しました。一つアドバイスするとすれば、SysV/ELF ABIの規約には本当に注意を払うべきです。そこには文書化されていないことがたくさんあり、何かを台無しにしたり、セキュリティ上の欠陥を引き起こしたりするのは非常に簡単です（AT_SECUREを参照）。とはいえ、あなたのやり方も（やや）トリッキーです。なぜなら、私の理解が正しければ、あなたはすでに実行中のmuslにこれをフックしているので、muslがあなたの下で変更された場合、後方互換性の問題を引き起こす可能性があります。ランタイム全体を制御している場合は、これを行う方が安全です。
- torginus
私は過去に同様の問題に直面したことがありますが、ホストからの静的バイナリがこれをどのように解決するのか理解できません。
私の記憶では、LinuxでのGPUアクセスは、/dev下の特定のFDにアクセスすることで「機能」し、それらはベンダー固有です - これがこれらのライブラリが内部で行っていることです。
ライブラリには魔法の力はありません - FDにアクセスできなければ、何もできません。
したがって、コンテナ内ではいずれにしてもベンダー固有のアクセスが必要です（または包括的な許可、これは悪い考えです）。
また、動的リンクがこれに十分でない理由もわかりません - 問題はライブラリのロード/リンク方法ではなく、権限にあります。