Transcript POPLミーティング 5/11 型付きアセンブリ言語の 一般化実装に関する展望

POPLミーティング 5/11
型付きアセンブリ言語の
一般化実装に関する展望
米澤研 M2 吉野 寿宏
<[email protected]>
本日の Agenda
 型付きアセンブリ言語
 背景
 概要・関連技術
 TALx86
 概要
 TAL の一般化実装の可能性について
 着想・要件
 関連技術
型付きアセンブリ言語
背景
 ネットワーク越しのコード配布の隆盛
 アプリケーションから、OS のパッチやドライバまで
 同時に不正なコードの脅威も蔓延
 どうしたら、コードを信用できる/信用してもらえるか？
 ユーザとしては、実行しなければよいのだが、不便
 ソフトウェア作成者としては、信用してもらうことでユーザの
獲得につながる
 全てのソフトウェアを自作することは現実的でない
関連技術:
電子署名
 コードの出自を保証
 悪意のあるコードを
含まないことは保証
できない
 コードの正統性・
同一性を保証するが
 中身を保証する技術で
はない
ハッシュ値 h
公開鍵
暗号化
{h}Kpri
コード
{h}Kpri
D(Kpub, {h})
H(M)
ハッシュ値 h
ハッシュ値 h’
h=
h’ ?
関連技術:
Proof-Carrying Code
 コードが安全である数学
的証明を添付
 受け取った側は、ツールで
安全性を検証
 検証に通ったコードは数学
的に信用できる
[1]
安全
証明
コード
このコード
は安全です
 数学的理論に基づいた、
中身の検証が可能
安全
ポリシー
[1]
G. Necula. Proof-Carrying Code. In POPL97
関連技術:
Java VM
 バイトコード検証機構
 バイトコードの型検査
 そもそも型安全になるような設計
 メソッドの型情報などをオブジェクトファイルに格納
 コンパイル時の静的型が正しくない場合に有効
 ライブラリのバージョンを途中で変えたり、一部のファイル
を再コンパイルしたり
 しかし、Java であるがゆえに
 デバイスドライバ等、基幹部分への応用は難しい
 Java 以外の言語からのコンパイルは想定されない
[2]
型付きアセンブリ言語(TAL)
 実マシンのアセンブリ言語に型を導入
 Java VM のバイトコード検証にヒント
 レジスタの型・メモリの中身の型などを静的に検証
 型システムの完全性・健全性を証明すること
で、検証の妥当性をも含めて保証
[2]
[3]
G. Morrisett, et al. From System F to Typed Assembly Language. In 1998 ACM
SIGPLAN-SIGACT Symposium on Principles of Programming Language.
G. Morrisett, et al. TALx86: A Realistic Typed Assembly Language. 1999 ACM
SIGPLAN Workshop on Compiler Support for System Software.
TAL の定式化
 TAL の文法定義
 基本は、RISC マシンに
よくある命令セット
 3 operands 命令
 ヒープの操作
 malloc
 解放は GC
 pack/unpack 操作
 操作的意味論の定義
 ほぼ直感的
 型の導入
デバイスドライバ
 デバイスドライバの安全性
 WindowsXP: 署名がない場合に警告を表示
 オオカミ少年的状況になっているのでは？
 署名されていないドライバが数多い
 私が知る限り、ちゃんと署名されていたドライバってあま
り見た記憶がない…
 署名されていないからといって、ハードウェア用
ドライバのインストールを中断するか？
 安全性を数学的に検証することによって、動
機付けを強くする
BREW
 携帯分野への応用
 個人情報を取り扱う端末 = 頑健でなくてはならない
 BREW アプリの登場
 低レベルなコード(C++ などで記述)を実行させる技術
 現在では認証を通った公式コンテンツプロバイダのみが
使用可能
 TAL 検証系を利用すれば、サードパーティーのコー
ド安全性を検証可
 認証を受けなくても BREW 使用可能に
 開発者側の幅が広がるのでは
TALx86
TALx86
 Morrisett らは、Intel x86 向けの処理系を
公開
 OCaml で記述されており、ツール群全体で
約 7 万行 (!)

(コンパイル全然通らないんですけど…)
[3]
 実装に関する論文
 実装したツール群に関する紹介的な意味合い？
[4]
 詳しいところはあまりない( が少し詳しい)
[3]
[4]
G. Morrisett, et al. TALx86: A Realistic Typed Assembly Language. 1999 ACM
SIGPLAN Workshop on Compiler Support for System Software.
http://www.cs.washington.edu/homes/djg/slides/talx86_wcsss_talk.pdf
TALx86
 アセンブリ言語ツール
 talc
型検査ツール
 アセンブラ
機械語への変換
 Link-verifier リンケージの安全性を検査
 Popcorn
C 言語のサブセットから TAL へのコンパイラ
 Scheme
Popcorn で書かれた scheme インタプリタ
TAL による検証の流れ
 アセンブリコードに
annotation を挿入
 基本ブロックの入り口に
記述
 レジスタの型・スタックの型
 各 annotation について
型を検証
 各命令の操作的意味論
 ブロックに流入するところで
入り口条件を満足するか
mov eax,ecx
inc eax
mov ebx,0
jmp test
body: {eax: B4,
add ebx,eax
test: {eax: B4,
dec eax
cmp eax,0
jg body
; i = n
; ++i
; s = 0
ebx: B4}
; s += i
ebx: B4}
; --i;
; i > 0
EAX は 4-byte integer を持つ
EBX は 4-byte integer を持つ
TAL による検証の流れ
mov
add
jmp…
TAL
ソースコード
val f:
int ->
int …
TAL インター
フェイス
外部ライブラリ
アセンブラ
・リンカ
実行可能
コード
検証
エンジン
01000
10111
01010
0010
検証結果
talc
外部ライブラリ
インターフェイス
TAL の一般化実装の
可能性について
CPU は一種類ではない
 プロセッサはいろいろな種類
 x86, PowerPC, SPARC, ARM, SuperH, …
 PC 用としては x86 (互換)が多いが
 携帯デバイスだと ARM や SH が多い
 各 CPU ごとに処理系を作成する必要
 CPU が違えば命令セットも異なる
別のアーキテクチャに対応させる
 最初から作るのは面倒であるし
 現在ある TAL の実装を他のプロセッサ向け
に書き換えると
 しかし、TALx86 は(コードをざっと見た感じ)実装
のかなり中枢において x86 に依存している
 マシン状態、浮動小数点レジスタのスタック(というか
リング)構造
 命令セットを variant で列挙してるし (!)
 など
 どこまで作り直す必要があるか？
コンパイルの流れ
mov
add
jmp…
高級言語
中間言語
アセンブリ
0100101
1011101
0101011
機械語 00101…
コンパイルの流れ
(複数アーキテクチャ)
x86
mov
add
jmp…
中間言語
0100101
1011101
0101011
機械語 00101…
アセンブリ
mov
add
jmp…
高級言語
機種ごとの
TAL 処理系
中間言語
アセンブリ
mov
add
jmp…
中間言語
Alpha
0100101
1011101
0101011
機械語 00101…
アセンブリ
PPC
0100101
1011101
0101011
機械語 00101…
着想
 アーキテクチャが変わっても、CPU の構成
自体はあまり変わらない
 レジスタがいくつかあり、メモリ(スタック･ヒープ・
グローバル変数)があって
 その間で計算を行ったり、関数を呼び出したりする
→ これらの共通項を、理論として定式化できない
だろうか？
着想
 実装をいくつかの部分に分離して行う
 CPU の命令セットの操作的意味論
 ここは CPU ごとに独立する必要
 基本操作の定義
 記述を簡単にするためのライブラリ的なもの
 型検証エンジン
 レジスタの型・メモリの構造などを保持、検証を行う
中核部分
 マイクロカーネルからの類推
共通項の抽出
←この記述を簡潔
x86
Alpha SPARC
にできるように
固有情報 固有情報 固有情報
するには？
(μOP 的なレイヤ)
抽象ハードウェア
←この層に型を
導入できるか？
関連研究:
Foundational TAL
 TAL の検証系自体が正しいことはどう証明？
 TALx86 の妥当性はインフォーマルにしか
与えられていない
 実装が正しいことをユーザは信用する必要
 TCB (Trusted Computing Base) を小さく
することが重要
 実装を 2 つの段階に分けることを提案
 まず一般的な型付きアセンブリ言語を開発し
 実際のアーキテクチャからその言語へマッピング
関連研究:
Foundational TAL
 TALT (TAL Two)
 抽象機械
 レジスタ N 個 (任意)
 即値、レジスタ、メモリへの参照をオペランドとする
RISC 系命令セット
 レジスタ間接やメモリ間接などのアドレッシングモードを
記述できる
 算術演算と mov, cmp, 分岐命令, malloc を持つ
 Twelf (logical framework) で構築された LF
の上に構築
 Foundational PCC と同様
コンパイルの流れ (再掲)
mov
add
jmp…
高級言語
中間言語
このへんをターゲット
にした型検証系
アセンブリ
0100101
1011101
0101011
機械語 00101…
CPU 非依存な型システム
 Modular な型の処理・検証
 CPU の実体とできるだけ癒着しないように
 CPU 依存の部分を分離して記述するように
 あるいは、コードジェネレータを作成する (yacc みたいに)
 もちろん拡張性も必要
 既存のアセンブラに組み込めるとよい
 わざわざアセンブラから自作する必要はありや、なしや
 たとえば GNU as などに組み込めたら、利用しやすい？
 擬似命令はマクロなどで処理
型安全な中間言語を定義する
 実機の機械語とほぼ一対一対応する言語
 簡単なトランスレータで各アーキテクチャに対応
 型の処理系は一つで済む
 高級言語からのコンパイラが、その分必要に
なるが…
 近いものとして、RTL (gcc の内部表現)
 現在詳細調査中
命令の分類
固有命令
(特権命令など)
x86
ARM
算術命令、論理演算
など
SPARC
命令の分類
x86 用定義・
ライブラリ
による拡張
x86
余白はできてしまう
だろう
型検証カーネル
高級言語
ARM
SPARC
静的型付けだけでうまくいかない部分
 加減算は、数値にもアドレスにも用いることが
できる
 どちらとして用いている？
 アドレス+数値、数値+数値
 アドレス同士でオフセット計算もできそう
 逆に、アドレス演算器で計算させるなんて芸当も
 lea eax, [eax+eax*4]
; eax = eax * 5
 レジスタオフセット
 レジスタの値が静的に定まらない場合が難しい