意図せざる加速

4E

　あの日、NUSA報告 「ノヴァル意図せざる加速調査（unintended acceleration investigation）」を読み始めた夜のこと。

　僕が確認したかったあの……公判（トライアル）で陪審たちの目に触れたバイエル氏の引用箇所は。NTSA（ヌツァ）に提出されたうちの本編にはなかったのだが、「補遺Ａ：ソフトウェア」のほうで見つかった。それは……

NUSA:『◆スタック・オーバーフロー（Stack overflow）・チェッカー。 このシステム・スタックは４０９６バイトに限定されているから、これを超えて実行されることはありえないと確認するのが重要だが、安全重要組込ソフトウェアにおける標準である「再帰処理無し（the absence of recursive procedures）」の場合、やるべきチェックはシンプルである。』

　これで僕の頭に浮かぶのは、無数のバケツが次から次へと現れて。「※警告！※　この先、スタックエリア外」と書かれた立札の並ぶ境界を超え、地平線の向こうへと蔓延（はびこ）っていくイメージだ。溢れ出たバケツたちは何をしでかすのか？「補遺A」には、こう書いてあった。

NUSA:『この電子スロットルシステムのＣＰＵは、メモリ保護機能を有しておらず、スタック・オーバーフロー状態を正確に検知することはできない。とはいえ、そのようなオーバーフローが何らかのメモリ破損を引き起こして、それで何かよくない挙動を発生させ、ウォッチドッグ・タイマーのリセットにつながることはありそうである。』

　つまり、例の「番犬くん」の出番だという。ふぅーん。

　一方、原告側の専門家証人：マクシミリアン・バイエル氏の証言では……

A:『スタック・オーバーフローは、それ自体メモリー破損を引き起こしますので、まずやられるのは、４０９６バイトのスタック領域のすぐ隣にあるこの領域です。』

Q:『ここ……には、いったい何が？』

A:『ここにございますのはオペレーティングシステムのデータでして、保護されておりませんので。破損すれば、副作用としてタスクが死亡することもありえます。』

　つまり、簡単に言うと。

　溢れ出たバケツたちは、それぞれ、水が入っていたり／入っていなかったり……するわけだが、もともとその場所には。いちばん偉いオペレーティングシステム様のほうで、多数の仕事（タスク）を管理するためのバケツたちを置いているので。それらが、（ほんらい管理されてる側である）仕事（タスク）が新たに置いていくバケツへと入れ換わってしまうのである。

　オペレーティングシステム様が、何か別の職務で一区切りついて。「どれ、こっちをやるとするかぁ？」と、バケツを引き上げたときにはもう。置いた時とは全然違う内容になってるのだ。そんな事象が、オペレーティングシステム様にとって良いことであるワケがない。とりわけ、例の巨大「キッチン・シンク」プログラム：スロットル開度を出力する「タスクＸ」を管理するためのバケツが、勝手に置き換わったりした日には……！

　この点。「補遺A」を読む限り、NUSAは。「４０９６バイトのスタック領域のすぐ隣のバケツ置き場」が何に使われているか？……まで踏み込んでいないようだった。とはいえ、オーバーフローを凄っごく気にしていたのは間違いないようで。４０９６バイトを超えることが本当にないのか、算出しようとしていたのだ。

　ところが、その前に立ちはだかったのは。

NUSA:『電子制御スロットルのコードは、人間が書いて実装したもので、モデルから生成したものではないため、ノヴァルのエンジニアにとって利用可能な分析の選択肢は、人力でのコードレビューしかなかったことに注意すべきである。そのうえ、再帰の存在により gstack や AbsIntStackAnalyzer のようなスタック処理ツールが駄目になることから、完全自動分析も使えない。』

　障害となるのは、まさに当の「再帰（recursion）」……バケツを無限に置きまくる事態を起こし得る再帰（recursion）そのものであって。自動計測を封じられたNUSAは、各手順の絡まり合った状態をビジュアル化するツールの助けを借りながら、コードの動きを目で読み込んでいく羽目になったのだ。

　ちなみにノヴァル側は「最大でも１６８８バイトまでしか使わない」とNUSAに報告していた。どうやって算出したのか？ また、ほんとうにそうなら４０９６バイトものスタックエリアは過大ではないか？……と思うところだが。この報告値も、当の gstack で計測したものだったのだ。

NUSA:『この結果には注意が必要である。すなわち gstack は、そのユーザ・マニュアルにも：「プログラムに直接的・間接的再帰が潜在する場合には、再帰が何度生ずるか予測できないため、gstack はうまく機能できません。gstack は、呼び出しグラフに再帰の可能性を検知すると、警告メッセージを出力します。」……とあるように、再帰を解釈することができないのだ。』

　gstack というのを僕自身使ったことがないのであれだが。たぶん……「再帰あり」と警告が出たときも、とりあえず「ループが生じなかった場合でバケツの数が最も多くなる予測値」を出してくる仕様のツールではなかろうか。「再帰」を考慮しなければ算出できるわけなので。逆に「再帰」があるとわかっているからこそ……

NUSA:『ノヴァルは余分な安全マージンを追加するため、スタック領域として４０９６バイトを割り当てたが、これは元の予測値の倍以上である。』

　ところが、同様な予測値はバイエル証人も算出していて。「再帰」抜きでも、被告（ノヴァル）へ突き刺さる一撃を放っていた。それは……

Q:『貴方が発見したといわれる諸々を、概ね伺ってきたわけですが、この「スタック・ミステイク」というのは……どういうことでしょうか？』

A:『ノヴァルの大きな過ち……つまり、スタックエリアの最大利用率が４１％としてしまった原因は、解析のやり方に間違いがあったことです。その一つは、オペレーティングシステム自身のスタックもあると気付いていなかったこと。もう一つは、３５０もの関数の分を見逃していたこと。これらを含むようにして、私どもで算出した最大値は９４％です。これは「再帰」を考慮しておりませんので、スタック使用率はさらにこれを超える可能性があります。』

Q:『NUSAは、気づいていなかったのでしょうか？』

A:『はい、私はそのように考えております。安全マージンがほんの僅かであるとNUSAが気づくことはありませんでした。』

　ウッ……と来るところだが、「再帰（recursion）」の話に戻ろう。

　僕が構想して、父に「再帰（recursion）だ」と指摘された「迷路の抜け方」は。「基本手順」にしたがって自キャラを動かしている最中に、さらに「基本手順」を始めるような「自分で自分を呼び出す」ものだったが。ノヴァル・キャブラの電子スロットル制御ソフトウェアの３か所で（！）NUSAが発見した「再帰（recursion）」は。いずれもそういう「自己再帰」タイプではなく、

「自分が、ある場合に、『手順Ａ』を呼び出し」

　↓

「その『手順Ａ』が、ある場合に、『手順Ｂ』を呼び出し」

　↓

「その『手順Ｂ』が、ある場合に、さらに自分を呼び出す」

……という、「間接再帰」タイプだったのだ。

　しかも、NUSAとしては。ノヴァルの「間接再帰」よりも、僕がやらかした「自己再帰」のほうが、まだマシだと考えていたようなのだ。それというのも……

NUSA:『関節再帰のタイプは極めて稀（まれ）であるが、それは以下の理由による：

( i ) 間接再帰では通常、「再帰の循環」がいつ止むかを自動検出することはできず、それゆえ自動分析ツールで取り扱うことができない。このため、電制スロットルのような安全重要かつハード・リアルタイムなシステムに必要となる検証や妥当性検査は難しくなる。

( ii ) 間接再帰の呼び出し構造が自動ツールで扱うのに複雑すぎると、人間のプログラマにとっても、複雑すぎて完全に把握できないものとなるのが普通である。つまり、このような複雑さに対して手動解析は有効でない。

( iii ) 多重に入れ子となった再帰は、スタック空間を消耗し、メモリ破損やランタイム障害に繋がる可能性があるが、テストで検知するのは難しいかもしれない。

( iv ) 再帰は本質的にはループであり、どんなループとも同様、終了しない危険がある。無限のループはデッドロックにつながり、システムリセットを引き起こす可能性がある。』

　このように、「コトの厄介さ」を強く訴える前置きをしたうえで。NUSAは、問題の「再帰」でつながる「基本手順」たちを、宇宙（あま）駆ける超技術力を駆使して解析し尽くし、実際にはスタック・オーバーフローを起こさないのであると。みごと、確認していくことになる………

　………………筈（ハズ）だった、のだが。