サーバーの暴力性を選ぶ

 (cliffle.com)
1 ポイント 投稿者 GN⁺ 2024-04-28 | 1件のコメント | WhatsAppで共有

Hubris IPC の概要

  • Hubris は小型でアプリケーション非依存のカーネルを使用し、コードの大半（ドライバー、アプリケーションロジック、ネットワークスタックなど）は個別にコンパイルされた分離タスク内に存在する
  • これらのタスクは、クロスタスク・メッセージングシステム（IPC）を使って相互に通信できる
  • Hubris の IPC は、カーネルに実装された 3 つの中核操作（RECV、SEND、REPLY）で構成される
    • RECV: 到着した最優先メッセージを取得するか、メッセージが届くまでブロックする
    • SEND: メッセージと制御を受信タスクへ送信し、呼び出し元を停止する。呼び出し元は応答を受け取るまで待機状態に入る
    • REPLY: 以前に SEND を使ったタスクへ応答を返し、処理を継続できるようにする

新しく興味深い失敗モード

  • IPC はタスク境界をまたぎ、Hubris のタスクは個別にコンパイルされたプログラムであるため、コンパイラが関数呼び出しで前提にするような仮定を IPC で置く際には注意が必要
  • Hubris で IPC サーバーの役割を担うすべてのタスクは、次のような潜在的エラーを処理しなければならない
    • インターフェースや不適切なオペレーションコードを持つメッセージを受け取る場合
    • 期待したメッセージ型の代わりに解釈不能なバイト列を受け取る、あるいは短すぎる／長すぎるメッセージを受け取る場合
    • 必要なメモリ（書き込み可能メモリなど）を受け取れない場合

正常で正しいプログラムではこのような状況は起きない

  • 正常な Hubris プログラムでは、上で挙げた状況は発生しない
  • タスクはビルドシステムの構成によって相互接続されるため、取り違えが起きにくい
  • クライアントとサーバーは生成された Rust コードを使うため、型システムがタスク境界を越えて機能しているかのように前提できる

カーネルはいかなるナンセンスも許さない

  • Unix ではシステムコールの前提条件に違反すると呼び出し元へエラーコードが返るが、Hubris ではタスクが即座に破壊される
  • Hubris カーネルは Synthetic Fault（合成フォールト）という概念を通じて、カーネル規則に違反したタスクへエラーを渡す
  • Hubris ではハードウェアまたは合成フォールトが発生すると、タスクは即座に停止し、回復不能となる

サーバーもいかなるナンセンスも許さない

  • REPLY_FAULT という 13 番目で最も特異なシステムコールを通じて、サーバーはクライアントへエラーを伝達できる
  • REPLY_FAULT は REPLY に似ているが、メッセージを届けてタスクを実行可能状態にする代わりに、エラーを伝えてタスクを停止させる
  • REPLY_FAULT によって不要な IPC エラー処理を避けられる。正常なプログラムは問題が起こりえないかのように動作し、異常なプログラムはエラーを処理する機会すら与えられない
  • REPLY_FAULT は、アクセス制御ルールのようなアプリケーション固有のエラーを定義・実装する新しい方法を提供する

GN⁺ の見解

  • REPLY_FAULT は、サーバーがクライアント側の協力なしにクライアント上でクロスプロセス panic! を発生させられる強力な仕組みであり、これによって Hubris は悪意あるプログラムに対して非常に敵対的なシステムになる
  • REPLY_FAULT の欠点は、ファジングテストが非常に難しくなることだ。ランダムな IPC やシステムコールを生成するカオスエンジニアリング用タスクは、ほぼあらゆる動作で即座にリセットされる
  • しかし正常な Hubris タスクは動的に IPC メッセージを生成しないため、REPLY_FAULT の存在自体を意識せずに動作できる
  • REPLY_FAULT によってサーバーはクライアントへ任意にエラーを発生させられるが、これに対する評価はまだ十分に行われていない
  • Hubris の攻撃的なエラー処理は、開発初期にエラーを発見する助けとなり、エラーコードと違ってエラーを無視できなくする
  • IPC エラーを処理する汎用的な方法を使うと、正常なプログラムにも不要なオーバーヘッドが発生しうる。REPLY_FAULT はこれを避けつつ、異常なプログラムには厳格に対処できるエレガントな解決策に見える

関連記事

1件のコメント

 
GN⁺ 2024-04-28
Hacker News の意見

要約すると次のとおりです:

  • REPLY_FAULT が連鎖的に伝播するかどうかと、それによって生じる脆弱性への懸念が提起されている

    • A が B を待ち、B が C を待っている状況で、C が REPLY_FAULT を返した場合に A も一緒に終了するのか確認が必要
    • もしそうなら、システム全体が脆弱になりうる
    • SEND が循環構造なら、意図せず自分自身を終了させてしまう可能性もある

  • REPLY_FAULT は、アクセス制御などアプリケーション固有のエラーを定義・実装する方法を提供する

    • これはシステムが小規模で密結合しており、たいていシステム設計者自身がアプリケーションを書く場合には有用
    • しかしサードパーティのコードと連携する際には、相手がいつでもプロセスを即座に終了させられるため懸念がある
    • 世の中には、管理者に振り回される開発者が書いた質の低いドライバやバックグラウンドプロセスが数多く存在する

  • 1つのチームがすべてのコードを書くシステムでは、疑わしいクライアントを排除することが反復速度を高める可能性がある

  • Hubris は、サーバーがクライアントでは処理できない効果を実行するようにするカーネルと見なせる

    • これはコード再利用と構成を難しくするが、実行モデルを単純化する
    • 静的な組み込みシステムでは、適切なトレードオフになりうる

  • Hubris と Humility は深く没頭してみたい技術だが、時間と責務の制約で難しい

  • HTTP に関するエイプリルフール RFC として、「あなたは恥じるべきです」を意味する HTTP 499 ステータスコードを提案している

    • これは「なんだこれ…でも実は悪くないね」という文脈に合う

  • アインシュタインの名言「できるだけ単純に、しかし単純すぎないように」を引用し、Hubris の設計は後者に違反していると指摘している

    • 現実世界の混沌をまったく許容しない運用環境には関心がない

  • Humility はデバッガとして素晴らしい名前である

    • 多くのプログラマは「良い」コードにはデバッグ不要だと考え、デバッガの使用を拒む

  • Linux ではソケットだけで他のプログラムを直接終了させることはできないが、root 権限があれば他のプロセスを終了させたり、さらには再起動させたりできる

    • コンテナでは root 権限が一般的なので、この種の危険性が存在する

  • 「受け入れるときは寛容に、送り出すときは厳格に」という従来のネットワークシステムの知恵とはやや相反する

    • ただし、API を変更しつつ既存プログラムとの互換性を維持するには、受け入れ側を寛容にせざるをえない