HN 日本語サマリー

← 一覧へ戻る
インフラ・DevOps

ユニカーネルは難しかった。キーワード:過去形

Unikernels were hard. key word: were (ghuntley.com)

41 pointsby ghuntley15 コメント

要約

かつては実装が困難とされていたユニカーネルが、AIの進化により再注目されています。AIはライブラリの移植やコード生成を支援し、ユニカーネル開発のハードルを下げています。これにより、攻撃対象領域の縮小や、よりセキュアなシステム構築が可能になると期待されています。

全文翻訳

かつては難しかったユニカーネル。キーワード:過去形。 Justin Cormack、かつてMirageOSとUnikernel Systemsで働いていた人物が、私と同じことに気づいています。人々は再びユニカーネルを発見(または再発見)しています。彼はニュースレターでこのトピックに関する一連の対談を企画しており、私が最初でした。彼は私にメールを送り、5分後には私はパブからビールジョッキを手に話していました。私たちはMirage、Orleans、Haskell、Nix、Cursedなど、多くのことについて深く掘り下げました。 以下がその要点です。会話の特定の部分にジャンプしたい場合は、下部にある章のリンクを参照してください。Justinによる編集済みのトランスクリプトはIgnore Previous Directionsにあります。 ユニカーネルは難しかった。キーワード:過去形。今、私たちはAIを持っています。 ユニカーネルとは何か、そしてなぜそれが難しかったのか 私がユニカーネルに初めて触れたのは2015年頃でした。私はHaskellerのチームを編成し、関数型プログラミングに深く入り込んでいました。HaskellerがいるところにはOCamlプログラマーがおり、そこからMirageOSを見つけました。素晴らしいアイデアです。当時、私はそれで遊びました。 ユニカーネルとは、アプリケーションがオペレーティングシステムであるという考え方です。ユーザーランドはありません。Webサーバー、DNS、またはメールを送信したい場合、フォークしたりスパンしたりできるものはありません。それらをアプリケーション内のライブラリとして記述する必要があります。 それが摩擦でした。Justinはそれをよく覚えています。彼らがMirageを構築していたとき、TCPスタックとHTTPSスタックはありましたが、ストレージに関するものはほとんどありませんでした。彼らはNetBSDからドライバーを引っ張ってきて、ユーザー空間で実行できるようにしていました。当時それは困難でした。 私たちの業界には多くのドグマがあります。Nixは難しい。Bazelは難しい。ユニカーネルは難しい。はい、そうでした。これらの難しい概念は今やモデルの重みの中にあります。あなたがする必要があるのは、それらをプロンプトで要求し、認知的に、それらが難しいというドグマを取り除くことだけです。 オペレーティングシステムは設計上の負債 ユニカーネルではないすべてのアプリケーションは、アプリケーションがあり、その下にオペレーティングシステムがあるという仮定の上に構築されてきました。なぜ私たちはオペレーティングシステムを持っているのでしょうか?40年前にはヒューマンオペレーターがいたからです。私はIBM 5250、AIX、Solaris、メインフレームを経験しました。マルチユーザーオペレーティングシステムは、人がその前に座っていたために存在し、その後アプリケーションをその上に置きました。 私はそれを設計上の負債と見なしています。そして、なぜそれが今重要なのかを説明します。アプリケーションは侵害されます。AI以前から侵害されていました。誰かがユーザーランドアプリケーションを侵害し、シェルを取得します。そのシェルは、情報漏洩のためのVIPバトラーサービスです。 ユニカーネルでは、攻撃対象領域ははるかに小さくなります。機能がアプリケーション(オペレーティングシステム)にない場合、攻撃者は詰みます。次のホップはありません。 Justinはここで公平に反論しました。攻撃対象領域の削減は、人々が非常に曖昧にしていることです。Linuxコンテナからシェルを削除することはできますが、ほとんどすべてのLinux環境には、実質的にインタープリターのようなものがまだあります。書き込み可能なファイルシステムなしで新しいプログラムを実行できます。まだメモリ安全性とガジェットについて心配する必要があります。 すべて真実です。しかし、私たちが26年間行ってきたことを見てみましょう。SunOSとcgi-binの時代から覚えている最も古い格言は「コンパイラを本番環境に置くな」でした。次にビルドコンテナと本番コンテナが登場しました。次にChainguardです。私たちは攻撃対象領域を削り続けていますが、逆方向に行って攻撃対象領域がないことを保証していません。 そして、これが人々が見落としている点です。シェルもインタープリターもなければ、次に何をすべきかを知っているモデルの重みの中に何もありません。これは、ドライブバイ(あなたのフレームワークの週刊RCEを選択し、シェルを取得し、モデルの重みがシェルアクセスで何をするかを知っている)を、ソースコードを必要とする標的型攻撃に変えます。 欠落しているライブラリをポートするだけです。 古典的な反論:あなたのユニカーネルはStripeと通信する必要がありますが、OCamlにはStripeライブラリがありません。AI以前は、ため息をついてそれを書いたでしょう。今?GoライブラリをOCamlにポートするためにループを実行します。どうぞ:ユニカーネル内のStripe。 Justinも同じことの素晴らしい例を持っていました。彼はアプライアンス用の最小限のLinux OSイメージを構築していましたが、これはユニカーネルへの半歩です。なぜなら、PID 1として1つのアプリケーションしか実行しないからです。彼はXFSファイルシステムを作成する必要がありました。xfsprogsとそれがもたらすすべてをドラッグする代わりに、彼はエージェントと一緒に座り、Rustでmkfs.xfsを書かせました。バイト単位で同一の出力を生成し、すべてのフラグを解釈しました。ディスクフォーマットを一つずつリバースエンジニアリングし、ブロックサイズごとにテストしました。数時間かかりました。 これは、元のツールがゴールデンオラクルであるため機能します。両方の実装でさまざまなサイズのファイルシステムを生成し、それらを比較します。テストを移植します。それを自動化します。 ソフトウェアのポートはしばらく前から簡単になっています。やり方はここにあります。 オラクルがあれば、ポートはループです。 Geoffrey Huntley Geoffrey Huntley ストレージももう一つの大きなギャップでした。今日のほとんどのワークロードはクラウドシェイプであり、オンプレミスでも同様です。そのため、ターボパファーアプローチを取ります。S3をプライマリ、無限に拡張可能なストレージとして使用し、ローカルNVMeブロックキャッシュとホットビット用のLRU(または好みのキャッシュアルゴリズム)を使用します。Justinも「すべてにS3」の大ファンです。レイテンシが制約にならない限り、無限のストレージとマルチユーザーアクセスが得られ、その上にすべてを構築できます。 nix machine testsとオーバーレイ JustinもNixを試しており、エージェントにOSのプロトタイプを作成させた最初の時に、すべてのテストがフレークにビルドされたことに驚きました。 Nix言語はひどいです。Nixpkgsは素晴らしいです。NixOSマシンテストは最高です。マシンのフリートを起動し、ネットワークルールとアプリケーション間の相互作用を実行するテストを記述します。これは人々が知らないことです。 そして、アップストリームで何かが壊れたり、依存関係にサプライチェーンの問題があったりした場合、それは単なるオーバーレイです。 世界はまだ、Nixオーバーレイで文字通りすべてを修正できることに気づいていません。 世界をパッチする。 Geoffrey Huntley Geoffrey Huntley 人間(「Dear Maintainer」としても知られる)にツールコールする必要がある場合、その人は休暇中かもしれないし、プロジェクトを放棄したかもしれないし、1日、2日、あるいは5分待つ必要がある場合、それはAGIではありません。 私たちはここで再帰的な製品を構築しています。エージェントは、サードパーティのバンドルされたバイナリとしてではなく、ファーストパーティのソースとして世界を変更する能力が必要です。私たちはcontribフォルダとUnixパッチに戻っています。 セキュリティを気にするなら、2つの選択肢があります。 Justinは、ユニカーネルが人々に見つけてもらうためにまだ何が必要か尋ねました。正直に言って、それはこれです。私たちは、それが存在することすら知らない開発者の2世代を育ててきました。 セキュリティを深く気にするなら、実際には2つの選択肢があります。 宇宙に衛星を送るなら、おそらくセキュアでフォーマルに検証されたオペレーティングシステムであるseL4を使用すべきです。(オーストラリア政府がそのチームを解散したことには、まだ少し不満があります。) それ以外のすべての人々は、真剣にユニカーネルを検討すべきです。非常にハッキングされやすいものを強化しようとするのをやめてください。それを反転させ、反対方向から設計してください。 もう一つの古典的な批判は、多くの初期のユニカーネル設計がすべてを単一の特権レベルで実行していたことです。あなたのアプリケーションはOSと同じリングで実行されていました。2026年、リング分離を望むなら、それはプロンプト一つで修正できます。それは、systemd cgroupの設定が正しいことを神に祈るよりも確かに安全です。 企業がLinuxに新しいものが登場するたびに、世界をパッチするのにどれだけの時間を費やしているかを考えてみてください。アップストリームは現在、カーネルを毎週パッチすることを期待しています。私たちが録音した週、誰かがKVM(基本的にFirecracker、私たちがすべて良いサンドボックスと考えていたコアプリミティブ)を侵害し、Vercelや他のいくつかのベンダーから50,000ドルを収集しました。これは、世界中のすべてのマネージドクラウドプロバイダーをルートできる可能性のあるものとしては、それほど多くのお金ではありません。 spaceleans:分散型ユニカーネルオペレーティングシステム 約7ヶ月前、私はユニカーネルについて深く掘り下げ、私のメンタルモデルが正しいかどうかを確認しました。Justinに私のMirageフォルダを見せました。そこには、追加する必要があったすべての機能が含まれていました。 ユニカーネルフリートが時間を維持する方法はありませんでした。そのため、NTを取りました。