ネットワークスイッチを殺した犯人は？ 「Hubrisバグ」の話

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

Hubrisバグの話: ネットワークスイッチを殺したのは誰か？

  • Hubrisとは何か？

    • Hubrisは深く組み込まれたシステム向けのオペレーティングシステムで、キーボード内部のような、コンピュータとして認識されないコンピュータのために設計されている。
    • Oxide Rackで大型プロセッサを起動するために必要なあらゆる処理を担うために開発された。
    • Hubrisはかなり独特であり、この話に関係する部分は以下で説明される。

  • 犯行現場

    • Oxideのネットワークスイッチファームウェアを担当する同僚のArjen Roodselaarが、電源シーケンスとクロック構成に関する変更をテストしていた。
    • 小さな変更の後、突然スイッチが起動しなくなった。
    • ファームウェアの一部は応答していたが、電源供給シーケンスを担当する重要な部分は停止していた。

  • 限られたRAMからさらに多くを引き出す

    • Hubrisを使う低価格マイクロコントローラは、RAMとフラッシュが非常に限られている。
    • Hubrisはタスクと呼ばれる別個にコンパイルされた多数のプログラムで構成されており、他のオペレーティングシステムよりやや高いリソース要求を持つ。
    • 同僚のMatt Keeterは最近、システムをより賢くして、複数の2のべき乗領域を使い、できるだけタスクを詰め込もうと試みた。

  • 動かぬ証拠

    • ArjenはHumilityというHubrisデバッガを使って、故障したネットワークスイッチを調査した。
    • humility tasks コマンドを使って、プロセッサ上で実行中のタスク一覧と状態情報を出力した。
    • 電源シーケンスを担当するタスクが、メモリ障害により115回再起動していたことを発見した。

  • Hubris IPCでRustの借用をタスク間へ拡張する

    • HubrisのタスクはIPCを通じて互いにメッセージをやり取りできる。
    • メッセージは関数呼び出しと非常によく似た見た目と振る舞いを持つ。
    • タスクが別のタスクにメモリを貸し出すとき、実際には所有していないメモリを貸し出そうとしてはならない。

  • 機能が襲いかかるとき

    • 2つの機能が組み合わさることでバグになることがある。
    • タスクのパッキングはビルドシステム内で日和見的に動作する。
    • タスクAのサイズが少し変わると、無関係なタスクBのMPU領域境界の位置が移動する可能性がある。

  • 内線からの電話！

    • メモリ保護アルゴリズムを変更する必要があった。
    • 貸し出されたメモリがMPU領域をまたぐことを許可しなければならなかった。

  • Hubrisで失敗する

    • システムが失敗したときに起こらなかったことがいくつもあった。
    • 壊れたネットワークスイッチを3時間で修理できた。
    • 障害の分離、安全側への失敗、安全な共有メモリ、カーネルとデバッガの共同設計、設計と実装の単純さ、チームの緊密で非階層的な統合などが役立った。

GN⁺の見解

  • この記事は、Hubrisというオペレーティングシステムで発生したバグを発見し、解決する過程を通じて、複雑なシステムでも堅牢なソフトウェア設計が重要であることを示している。
  • バグの発見と解決の過程は、ソフトウェアエンジニアリングの複雑な問題を解くうえで、チームワークと効率的なデバッグツールの重要性を強調している。
  • Hubrisのようなシステムを使う際に、システムの分離と障害管理機能がいかに重要かを示している。これはシステムの安定性と保守性を大きく向上させうる。
  • この記事はまた、安全なプログラミング言語であるRustを用いてメモリ安全性を保証し、バグを最小化する方法も示している。Rustを使うシステムではこの種のバグはまれであり、これはRustのメモリ安全性保証が実際にどれほど有効かを裏付けている。
  • 類似の機能を持つ他のプロジェクトや製品としては、seL4、FreeRTOS、Zephyrなどがあり、これらはそれぞれ異なる目的と特性を持つ組み込みシステム向けオペレーティングシステムである。
  • Hubrisのようなシステムを導入する際には、メモリ制約、タスク管理、IPCメカニズムの設計といった要素を考慮する必要がある。このようなシステムを選ぶことで得られる利点は、堅牢なシステム設計と安全なメモリ管理にあり、欠点はシステムの複雑さと学習曲線になりうる。

関連記事

1件のコメント

 
GN⁺ 2024-03-27
Hacker Newsのコメント

  • Hubris カーネルコードのレビュー

    • Hubris のカーネルコードを30分ほど読んでみたが、とても明快でよく書かれている。以前に見た、複雑なマクロや2文字の変数名、コメント不足の C コードとはまったく違う。寝る前の読み物としてもおすすめできる。

  • 求人広告への称賛

    • これは自分が見た中で最高の求人広告の1つだ。カルチャーの話への自然な流れがあり、最後に「私たちは採用中です」と続く。しかも、アプリケーションレベルの開発者でも理解できる優れたポストモーテムでもある。ちょうど Rust を勉強中なので、こうした内容を楽しむ準備ができていた。また、コードにたくさんコメントを付けている人の仕事を見るのはいつでも楽しい。

  • コードレビューと提案

    • コードについて1点だけ簡単に指摘すると、これは特定の関数の詳細ではなく、すべての作者が守るべきで、すべての読者が利用できるフィールドの不変条件に関するコメントなので、TaskDesc::regions のドキュメント文字列に追加するとよい。

  • デバッグ過程への評価

    • 複雑な問題をデバッグするための掘り下げた分析が示されており、システムの他の部分が安定して保たれていたことは、Oxide チームの高品質なエンジニアリングの証だ。個人的にも刺激を受けて、職場で似たような技法を使ってみたいと思った。

  • Oxide チームの文化への関心

    • Oxide のエンジニアリングチームは内部で孤立しておらず、オープンさ、好奇心、コミュニケーションを奨励し、防御的な態度、帝国づくり、ゲートキーピングを抑える文化を持っている。こうした文化を作り、それを守るために努力してきたのだろうし、他の組織なら別チームと呼ばれるような範囲をまたいで水平的に組織されている点にもそれが表れている。このような文化を作る動機や、具体的な実践の詳細についてもっと知りたい。組織の中で「オープンさ、好奇心、コミュニケーション」を奨励することに欠点はあるのか、あるいはより厳格な階層型システムを選ぶ場面があるのかも気になる。組織図は戦略的に決めるべきものだと思うが、そのトレードオフはよく分からない。

  • 関連情報へのリンク

    • 事前情報は提示されたリンクから見つけられる。

  • デバッグ時に起こる問題への共感

    • デバッグ用のコードを追加すると消えてしまうランダムクラッシュは、最悪のクラッシュだという点に共感する。

  • ハードウェア処理への提案

    • ハードウェアをソフトフィル TLB のように扱うことで、8個を超えるリージョンをサポートできると述べている。

  • Oxide の仕事への称賛

    • Oxide が行っている仕事には驚かされる。

  • OS 名への反応

    • OS の名前を Hubris にしたことへの驚きと反応を示している.