POPLミーティング 10 12 修士研究進捗報告米澤研 M 2 吉野寿宏 tossy-2 yl

POPLミーティング 10/12 修士研究進捗報告米澤研 M 2　吉野寿宏 <tossy-2@yl. is. s. u-tokyo. ac. jp>

Agenda n n 研究テーマについて進捗報告 ¡ ¡ n 現状現在考えている問題点 Survey ¡ Program Verification Techniques on Java VM /. NET CLI

研究テーマについて

研究テーマ n An Implementation of Typed Assembly Language for Multiple Architectures ¡ 型付きアセンブリ言語の汎用的な実装要するに ¡ TAL 検証器を構成するための統一的な手法の確立

型付きアセンブリ言語 (TAL) n 実マシンのアセンブリ言語に型を導入 ¡ ¡ ¡ [1] レジスタの型・メモリの中身の型などを静的に検証メモリ安全性(範囲外のメモリをアクセスしないこと)などを保証 Java VM のバイトコード検証機構と類似 G. Morrisett, et al. From System F to Typed Assembly Language. In 1998 ACM SIGPLAN-SIGACT Symposium on Principles of Programming Language.

研究の着想 n TAL はアーキテクチャ(= CPU)に強く依存した言語 ¡ ¡ n アーキテクチャごとに処理系を用意する必要既存の処理系を移植する作業はコストが高いしかし、どの CPU も中でやっていることは一緒 ¡ ¡ レジスタ・メモリにデータを格納算術演算、論理演算、関数呼び出し… → 型システム・検証器などは大部分が共通に　使用できるのでは

研究の着想 n Formal に書けば、命令実行とは、 r 1=0, … n r 1=1, … したがって一般的に型を導入することができるいずれも型環境

型検証の手順 n コードの各所に annotation を挿入 ¡ ¡ n 「これ以下ではこの前提の下実行される」という意味の制約基本的には各基本ブロックごとに挿入全ての実行遷移について annotation を満たしているかどうかを検査 ¡ 分岐・関数呼び出しなどで飛び込んでくる場合

型検証の手順ラベル 1: 　　型情報　　　命令　　　… 制御フローラベル 2: 　　型情報　　　命令　　　… 流入可能条件基本ブロック

型検証の手順ブロックに流入する際には入口の条件をチェックラベル 1: 　　型情報　　　命令 A A 実行後の状態　　　命令 B B 実行後の状態　　　命令 C C 実行後の状態　　　… ラベル 2: 　　型情報各命令の意味論によって、実行後の　　　命令状態を求める　　　命令　　　…

アプローチ n 意味論記述用の言語を設計 ¡ 基本的な操作をカバーするシンプルな言語 n ¡ n 算術演算や論理演算、分岐、メモリの参照その上に型システムを導入実アーキテクチャのアセンブリ言語からの変換規則を記述 ¡ ¡ 変換ルールの記述方法の設計ソース言語の読み込みインターフェイス n 抽象化することにより、アセンブリでもオブジェクトコードでも対応可能なようにする

アプローチ型型高級言語プログラムコンパイラプロアーキテクチャ A グラ実行ファイルム変型換アーキテクチャ B 実行ファイル型意味論言語 ↑ この上で型を検証

なぜアセンブリ言語か？ n Java 等の言語で書けばいいのでは？ ¡ 確かに。しかし実際の機械が実行するのはあくまでそのアーキテクチャの機械語 n ¡ いわば水際作戦システムソフトウェアなどにも応用がきく n ただし OS 自体を安全な言語で書くという研究もある

進捗状況

全体の程 n 意味論記述部 ¡ ¡ ¡ n 抽象機械の定義 (その上の)意味論言語 (さらにその上の)型システム命令マッピング機構 ¡ Unification によるマッチング

関連研究 n Foundational TAL ¡ 目指すシステムは本研究と類似 n n ¡ [2] 「一般的な TAL」を開発することにより TCB (Trusted Computing Base) を小さくする目的抽象アーキテクチャと型システムを設計し、 Progress, Preservation を定理証明器で自動証明 K. Crary. Toward a Foundational Typed Assembly Language. CMU Technical Report CMU-CS-02 -196.

関連研究 n Foundational TAL ¡ Pointer arithmetic が入っていない n ¡ レジスタベースなので途中の計算結果を保存できない n n ¡ かわりに、メモリ参照のところで即値のオフセットをとることができる複雑な命令の記述性ただ、「複雑な命令」と一口に言ってもいろいろ処理系は未公開？

関連研究 n LLVM ¡ ¡ ¡ もともとは最適化目的で作成された VM C ライクな構文を持っている弱い型付けがされている n n ¡ [2] [3] キャストが許可されている Formal な証明が与えられているわけではない Subset を定義して formal に型システムを導入すれば使えるかも C. Lattner. LLVM: An Infrastructure for Multi-Stage Optimization. Master Thesis at Computer Science Dept. , Univ. of Illinois at Urbana-Champaign, 2002.

抽象機械を定義する n 抽象機械 = 状態を保持する部分 ¡ 実アーキテクチャを包含できるような一般性が必要 ¡ いくつかのレジスタ n ¡ 抽象化するアーキテクチャと対応させるメモリ

抽象機械を定義するデータ定義 n データはすべてバイト単位に分割してそのタプルで記述

抽象機械を定義するデータ定義 n データはすべてバイト単位に分割してメモリアドレスはそのタプルで記述内部的に fat pointer で扱う

抽象機械を定義するデータ定義 n データはすべてバイト単位に分割してそのタプルで記述アドレス値の n バイト目未定義値

抽象機械を定義する抽象機械の持つ状態 n レジスタは名前で識別 ¡ n レジスタ r 1 の幅を w 1, … とするメモリへはラベル(とオフセット)でアクセス ¡ ラベルの異なるメモリ領域同士は「独立」 n 境界チェックができる

意味論言語 n 要件 ¡ 実行フロー関係の構文はほとんど必要ない n ¡ if による分岐と jump の組み合わせで記述可能演算の類は正確に記述できる必要がある n 型システムが値に依存する可能性が高い ¡ n 詳しくは後述意味論言語に変換されたプログラムと元の実プログラムとで結果が同一になることを検査可能 → 記述の正しさの検証につながると思われる

意味論言語言語構文 n Left value とは、C 言語でいうところの左辺値 ¡ つまりは代入可能な箇所

意味論言語言語構文 n goto と call/ret が分かれている理由については後述

意味論言語型システム n 基本的な型 ¡ Junk … 不明瞭な型

命令マッピング n アセンブリ命令 = オペコード(命令種別) + 0 個以上のオペランド関数にたとえて言えば… ¡ オペコードは関数本体を指定する ¡ オペランドは関数への引数 n 入力引数だけでなく、結果代入先も指定

命令マッピングテンプレートの記述 inc r 1 : inc REG : inc r 2 : { r 1 : = r 1 + 1; } { REG r 2 + 1; } { r 2 : = REG + 1; } inc というテンプレートで一般化される } r 3 : { r 3 : = r 3 + 1; . . . mov R 1, R 2 : { R 1 : = R 2 ; } add R 1, R 2 : { R 1 : = R 1 + R 2 ; }

命令マッピングテンプレートの適用 n テンプレート mov R 1, R 2 : { R 1 : = R 2 ; } n 実際の命令 mov r 2, r 5 要するに unification → テンプレートパラメータ部分との対応 R 1 = r 2, R 2 = r 5

命令マッピングアドレッシングモードの問題 n 大抵のプロセッサは、いろいろなアドレッシングモードがある ¡ ¡ レジスタ+定数オフセットの指すメモリレジスタ+レジスタ×定数云々これらをテンプレート引数として統一的に扱うにはどうしたらよいか？ n 考え中

現在考えている問題点 n Architecture-Specific Feature の扱い ¡ Delayed Branch の解決 n Pointer Arithmetics 関数呼び出し n 等々 n

Architecture-Specific Feature の取り扱い n Delayed Branch ¡ ¡ Delay なしの semantics に変換して扱う問題: annotation のないラベルができる可能性. . . bge lbl_ge bl temp mov r 1, r 2 lbl_lt: . . . ba lbl_ge temp: mov r 1, r 2 lbl_lt: . . .

問題点 Pointer Arithmetics n 次のような C コードをコンパイルしたとする struct foo { int id; char *name; } bar = { 1, “bar” }; void func() {. . . bar. name. . . } &bar + sizeof(int) という風な記述になる

問題点 Pointer Arithmetics n ラベル “bar” の型 B 4 0 n B* ptr 4 Dependent type が必要 ¡ ¡ ¡ *(bar + 4) のような記述になる + のオペランドは e なので計算する必要がある static に決まらないものも指定できてしまう… struct foo { int id; char *name; } bar = { 1, “bar” }; void func() {. . . bar. name. . . }

問題点 Pointer Arithmetics n Static な解析で追いつかない場合にどうする？ ¡ たとえばレジスタ+レジスタおそらく非決定的だということで検証が失敗することになる ¡ 記述できなくする手もある ¡ n n TALT では、メモリ参照は即値オフセットをとることができるしかしレジスタ値と足したりした場合には型付けルールがない

問題点関数呼び出し n call, ret どちらも無条件分岐として扱える ¡ ¡ call の戻り先アドレスは、関数の返り値の型をとるようなコード列それを callee 側の precondition として記述すればよい n n たとえばスタックに戻り先を積む場合、 {引数…, sp: <戻り値をとるコードへのポインタ, …> } のように

問題点関数呼び出し Callee の precondition として記述したとして… n 戻り先のコードが実際にその条件を満たすかどうか検証の必要単純な jump として捉えた場合、この一致を記述するのが難しい ¡ たとえば、「次の命令のラベルの型」といった記法を導入する必要 → 複雑化してしまう ¡

問題点関数呼び出し n call, ret を jump とは別に用意することで解決できるかどうか ¡ call については、関数のシグネチャから実行後状態を取り出してくればよい ¡ 問題: アセンブリ言語では関数構造が見えないこと n 関数から必ず戻っているか… fall through していないかどうかが簡単にはわからない

Survey: Program Verification Techniques on Java VM /. NET CLI

信用できないコード n 基本的にクライアント側で実行させる ¡ n しかしネットワーク上のコードは基本的に信用できない可能性がある ¡ ¡ n たとえば、ブラウザ用の Java Applet 悪意のあるコードが混じっているとかスパイウェア、トロイの木馬… 不正なコードを実行して影響を蒙るのは実行したクライアントである

Java におけるセキュリティ確保 n Java のコアクラスと外部のクラスを分別システムクラスを置き換えるなど悪意のある動作を防ぐ → サンドボックスの仕組み ¡ ¡ しかし不正なコードによって VM の動作がおかしくなってしまうことは防げない n たとえばメソッド呼び出しの型があってないとかまた、動的検査ではコストが高い → バイトコード検証 ¡

Java VM n Java バイトコードを実行する仮想機械 ¡ アーキテクチャとしてはスタックマシン n 計算はスタックに対して行われる ¡ ローカル変数・メソッドの引数用の記憶領域が別に与えられている ¡ 扱う値は、プリミティブ型(int など)か参照 (Object 型のサブクラス)の 2 種類

Java VM method func() iconst_1 iconst_2 iadd istore_0 スタック 3 1 記憶領域 3 0 2

バイトコード検証によって保証できること n 命令の型が一致していること ¡ n 足し算に Object を持ってきたりしていないか？スタックをはみださないこと ¡ ¡ アンダーフローしていないか？または最大使用量をオーバーしていないか？ n 最大使用量はメソッドのシグネチャに含まれる

バイトコード検証によって保証できること n プログラムカウンタが正当であること ¡ ¡ n Java の場合、分岐は必ず同一メソッド内バイトコードの命令の途中を指したりしていないか？値の初期化 ¡ ¡ 記憶領域を使う前に初期化しているか？オブジェクトにアクセスするより前にコンストラクタを呼んでいるか？

Type-Level Abstract Interpreter n あたかも”普通の” Java VM のようにバイトコードの semantics に沿って計算 ¡ n 計算過程で、バイトコードの安全性を保証するために必要な点を検証取り扱う値は全て型 ¡ バイトコードは型情報を含んでいるので容易に検証ができる

. NET CLI n CIL (Common Intermediate Language) と呼ばれる言語を実行する仮想機械 ¡ ¡ アーキテクチャはスタックマシンメソッド引数用・ローカル変数用の記憶領域が別に与えられている n ¡ Java とは異なり、これらは別々である整数型・浮動小数点型(F)・ポインタ(&)・参照(O)を持つ

CLI のプログラム検証 n CIL の命令セット定義には検証可能性についても含めて書かれている ¡ n 基本的には Java の場合と同様にやるポインタは鬼門 ¡ ポインタ演算があると検証可能でなくなる n n ポインタ+整数、ポインタ-ポインタの演算が有効 (ただし検証不可能) Java はポインタを見せない(配列かオブジェクトに全てカプセルする)ので検証性は落ちない

参考文献 n n X. Leroy. Java Bytecode Verification: Algorithms and Formalizations. Journal of Automated Reasoning 30(3 -4): 235 -269, 2003. Sun. The Java Cirtual Machine Specification. http: //java. sun. com/docs/books/vmspec/ n Microsoft. The CLI Specification. http: //msdn. microsoft. com/netframework/programming/clr/default. aspx

POPLミーティング 10 12 修士研究進捗報告 米澤研 M 2 吉野 寿宏 tossy-2 yl

POPLミーティング 10 12 修士研究進捗報告米澤研 M 2 吉野寿宏 tossy-2 yl