IPAも開発プロセスに取り組む

　開発プロセスにセキュリティの考え方を入れ込むプロジェクトは，IPAでも進行中である。現在，IPAでは組み込みソフトウェアの標準的な開発プロセスを整備中だが，その中にセキュリティ評価を取り入れる予定だ。また，ユーザーが間違った設定や操作をしないように分かりやすいユーザー・インタフェースを用意するユーザビリティのガイドラインも併せて提供する。2005年末にも公開する。

　セキュリティ評価に関しては，同じIPAの中に設置されたセキュリティ・センター＊2と連携して取り組む。

　ユーザビリティの部分ではエンドユーザーが迷うことなく設定/操作でき，危険な状態のときにはそれを感知できるようなインタフェースを目指す。「車の場合，急カーブを曲がる際にハンドルが重くなったりタイヤが鳴ったりすることで，ユーザーに注意を促すように設計されている。セキュリティ上危険な状態にあるなら，それをユーザーが直感的に理解できるようなインタフェースが設計できるようにしたい」（IPAソフトウェア・エンジニアリング・センター組込み系プロジェクトの田丸喜一郎プロジェクトサブリーダー）という。

安全なアセンブリ言語でOSを開発

　開発プロセスではなく実装の部分でも改善の余地はある。

　一般にOSの開発では言語として，CやC++，アセンブリ言語が選ばれる。OSやドライバではメモリーやI/Oを直接アクセスする（たたく）操作が不可欠になるからだ。また，パフォーマンスを高めるためにもハードウェアが見える形でプログラミングする必要がある。

　しかしこういったメモリー操作は，プログラマが注意しないとバッファ・オーバーフローの脆弱性を作ったり，プログラムの暴走を引き起こしかねない。

図5●OSがセキュアになりにくい理由

　そこで，東京大学の米澤明憲教授の研究室では，不正なメモリー操作を事前にチェックできる拡張されたアセンブリ言語を使って脆弱点のないOSの開発に取り組んでいる（図5[拡大表示]）。開発には米Harvard大学のGreg Morrisett教授（開発当時は米Cornell大学に所属）らが1998年に開発したTAL（Typed Assembly Language）を拡張して利用する（別掲記事「安全なアセンブリ言語TAL」を参照）。拡張するのは従来のTALはOS開発に向いていないから。TALはメモリーの不正操作や意図しない制御フローからの逸脱などが検知できるので，バグは残りにくい。

　アセンブリ言語を使うのはバグが混入するのを極力防ぐため。例えば，C言語ではライブラリやコンパイラなど開発環境自体にバグが残る危険性がある。

　デバイス・ドライバ，メモリー管理機構を従来のTAL，スレッド切り替え機構を拡張TALにより実装できることをすでに確認している。今後は，割り込み機構を実装できるようにTALを改良し，OSの開発につなげる。


図●TALの型検査器の動作
コード呼び出し時の状態と計算後の状態を定義しておく。型の検査プログラムで，この状態を満たしているかチェックし，問題があれば，エラーを発する。スタックの構造や値も定義できる。例ではリターン・アドレスの上にint型の何らかの数があり，さらにその上に処理前後で変わらないデータσが載っているという条件がある。計算前後でこの構造が変わらないため，図では○になっている。

安全なアセンブリ言語TAL

　TALはアセンブリ言語を拡張した仕様をもっている。あるコード（例えば関数）が利用される前後のデータの配置，それぞれの領域に収まるデータの型や長さをプログラマが定義しておく。TALで書かれたプログラムをコンパイルすると，結果としてバイナリデータと型定義情報が出力される。プログラムが逸脱した動作をしていないかは，バイナリデータと型定義情報を使って検査プログラムがチェックする。

　下のリストはTALで記述したプログラムである。先頭に定義を書き，その下に実際の処理が書いてある。この処理では，レジスタ3（R3）にスタックポインタ（SP）から4バイト先にある部分を代入し，レジスタ（R1）にR3を2回足したものを格納する関数を示している。

　リストでは「関数が呼ばれたときと，関数から結果が返る場合でR3の値が変わらない」「4バイト分のリターン・アドレス領域，4バイト分の整数型値（値の中身は問わない），長さが不定の“任意の値（図[拡大表示]のσ）”というスタック構造は変わらず，さらにσの部分は処理の前後で変化しない」「結果が返る際，R1が整数（int）型になっている」と定義している。

　図に示した例では処理前後でR3が変化しているのでエラーになる。