情報社会を支える
ディペンダブル・プロセッサ
九州大学
井上弘士（いのうえこうじ）
ディペンダブル・コンピューティング
（Dependable Computing）
頼る
～できる
計算すること
あなたにとって，「○○先生」は頼りになりますか？
YES!
私の質問に対して，常に，正しい解答を示してくれる
私に危害を加えない（私を裏切らない）
勝手に他人へ危害を加えない
などなど
NO!
私の質問に対して，常に（たまに），誤った解答を示す
私に危害を加える（突然きれる，突然暴れる）
他人へ危害を加える
などなど
ディペンダブル・コンピューティング
（Dependable Computing）
頼る
「頼りになる」とは？
計算すること
提供されるサービス（利用者が認識するシステムの振舞い）が正確で信
頼できる
結果として利用者に損害をもたらさない，また，被害が発生しても最小限
に留める
でも現実は・・・
～できる
様々な「想定外の事象」により正確性や信頼性が失われる
「常に100%正確かつ信頼できるシステム」はありえない
そこで・・・
Dependability：予測不可能性（想定外事象）を秘めた系において，シス
テムに期待されるサービスが許容範囲内で提供される事を保障すること
Dependable Computing：「想定外事象は発生するもの」という前提に立
ち，それを解決（回避）可能なシステムで計算する！
ここまで発展したマイクロプロセ
ッサ（シングルコア）
4004@1971
(108KHz)
Pentium2@1997
(450MHz)
i486@1989
(25MHz)
Pentium@1993
(60MHz)
Pentium4@2000
(1.5HGz)
出展：http://www.intel.com/museum/online/hist_micro/hof/index.htm
ここまで発展したマイクロプロセ
ッサ（マルチコア）
256KB LS
256KB LS
256KB LS
256KB LS
256KB LS
256KB LS
256KB LS
256KB LS
Opteron (AMD)
Niagara-T2 (Sun)
http://news.com.com/
PPE
512KB
L2キャッシュ
Cell (Sony/Toshiba/IBM)
Opteron(AMD):http://techreport.com/
プロセッサの回路規模はどの程度?
（トランジスタ数の観点から）
半導体集積度は３年で約４倍に！（ムーアの法則）
インテル・プロセッサの場合
1000
Itanium
Trace Cache
Hyper Threading
100
Pentium 4
Super Scalar
Pentium III
Pentium
1
80486
http://www-vlsi.stanford.edu/group/chips_micropro.html
20
04
19
98
19
94
19
92
19
90
19
88
19
86
19
96
On-Chip L1$
80386
0.1
Out-Of-Order
Renaming
On-Chip L2$
20
02
10
20
00
M Tran.
Pentium II
19
84
命令の実行手順
プロセッサ
命令レジスタ
アドレス
PC
0x00104
デコーダ
レジスタ
ALU
主記憶
・・・
0x00104
add $t0, $s1, $s2
0x00108
sub $t1, $t0, $s3
0x0010c
lw $t1, 320($s4)
・・・
1.命令の取得：PCが指すアドレスの値をメモリ
から命令レジスタへ取得．同時に，次命令の
取得に備えてPCの値を更新（例えば＋4）
2.命令の解読：命令レジスタの値をデコード
3.命令の実行：解読結果に従って実行
実際には，各命令は2進表現
でメモリに格納されている
命令の実行手順
PCの指す番地から取
得した命令を保持 プロセッサ
命令レジスタ
add $t0, $s1, $s2
実行する命令の
アドレス
アドレス
PC
0x00104
デコーダ
レジスタ
ALU
主記憶
・・・
0x00104
add $t0, $s1, $s2
0x00108
sub $t1, $t0, $s3
0x0010c
lw $t1, 320($s4)
・・・
1.命令の取得：PCが指すアドレスの値をメモリ
から命令レジスタへ取得．同時に，次命令の
取得に備えてPCの値を更新（例えば＋4）
2.命令の解読：命令レジスタの値をデコード
3.命令の実行：解読結果に従って実行
実際には，各命令は2進表現
でメモリに格納されている
命令の実行手順
プロセッサ
命令レジスタ
add $t0, $s1, $s2
次命令の取得にそ
なえてPCを更新
アドレス
PC
0x00108
デコーダ
レジスタ
ALU
主記憶
・・・
0x00104
add $t0, $s1, $s2
0x00108
sub $t1, $t0, $s3
0x0010c
lw $t1, 320($s4)
・・・
1.命令の取得：PCが指すアドレスの値をメモリ
から命令レジスタへ取得．同時に，次命令の
取得に備えてPCの値を更新（例えば＋4）
2.命令の解読：命令レジスタの値をデコード
3.命令の実行：解読結果に従って実行
実際には，各命令は2進表現
でメモリに格納されている
命令の実行手順
プロセッサ
命令レジスタ
add $t0, $s1, $s2
アドレス
PC
0x00108
デコーダ
レジスタ
ALU
取得した命令を解読
（s1とs2を加算し，t0へ格納）
1.命令の取得：PCが指すアドレスの値をメモリ
から命令レジスタへ取得．同時に，次命令の
取得に備えてPCの値を更新（例えば＋4）
2.命令の解読：命令レジスタの値をデコード
3.命令の実行：解読結果に従って実行
主記憶
・・・
0x00104
add $t0, $s1, $s2
0x00108
sub $t1, $t0, $s3
0x0010c
lw $t1, 320($s4)
・・・
実際には，各命令は2進表現
でメモリに格納されている
命令の実行手順
プロセッサ
命令レジスタ
add $t0, $s1, $s2
アドレス
PC
0x00108
デコーダ
レジスタ
加算
ALU
主記憶
・・・
0x00104
add $t0, $s1, $s2
0x00108
sub $t1, $t0, $s3
0x0010c
lw $t1, 320($s4)
・・・
1.命令の取得：PCが指すアドレスの値をメモリ
から命令レジスタへ取得．同時に，次命令の
取得に備えてPCの値を更新（例えば＋4）
2.命令の解読：命令レジスタの値をデコード
3.命令の実行：解読結果に従って実行
実際には，各命令は2進表現
でメモリに格納されている
命令の実行手順
PCの指す番地から取
得した命令を保持 プロセッサ
命令レジスタ
sub $t1, $t0, $s3
実行する命令の
アドレス
アドレス
PC
0x00108
デコーダ
レジスタ
ALU
主記憶
・・・
0x00104
add $t0, $s1, $s2
0x00108
sub $t1, $t0, $s3
0x0010c
lw $t1, 320($s4)
・・・
1.命令の取得：PCが指すアドレスの値をメモリ
から命令レジスタへ取得．同時に，次命令の
取得に備えてPCの値を更新（例えば＋4）
2.命令の解読：命令レジスタの値をデコード
3.命令の実行：解読結果に従って実行
実際には，各命令は2進表現
でメモリに格納されている
命令の実行手順
プロセッサ
命令レジスタ
sub $t1, $t0, $s3
次命令の取得にそ
なえてPCを更新
アドレス
PC
0x0010c
デコーダ
レジスタ
ALU
主記憶
・・・
0x00104
add $t0, $s1, $s2
0x00108
sub $t1, $t0, $s3
0x0010c
lw $t1, 320($s4)
・・・
1.命令の取得：PCが指すアドレスの値をメモリ
から命令レジスタへ取得．同時に，次命令の
取得に備えてPCの値を更新（例えば＋4）
2.命令の解読：命令レジスタの値をデコード
3.命令の実行：解読結果に従って実行
実際には，各命令は2進表現
でメモリに格納されている
命令の実行手順
プロセッサ
命令レジスタ
sub $t1, $t0, $s3
アドレス
PC
0x0010c
デコーダ
レジスタ
ALU
取得した命令を解読
（t0とs3を減算し，t1へ格納）
1.命令の取得：PCが指すアドレスの値をメモリ
から命令レジスタへ取得．同時に，次命令の
取得に備えてPCの値を更新（例えば＋4）
2.命令の解読：命令レジスタの値をデコード
3.命令の実行：解読結果に従って実行
主記憶
・・・
0x00104
add $t0, $s1, $s2
0x00108
sub $t1, $t0, $s3
0x0010c
lw $t1, 320($s4)
・・・
実際には，各命令は2進表現
でメモリに格納されている
命令の実行手順
プロセッサ
命令レジスタ
sub $t1, $t0, $s3
アドレス
PC
0x0010c
デコーダ
レジスタ
減算
ALU
主記憶
・・・
0x00104
add $t0, $s1, $s2
0x00108
sub $t1, $t0, $s3
0x0010c
lw $t1, 320($s4)
・・・
1.命令の取得：PCが指すアドレスの値をメモリ
から命令レジスタへ取得．同時に，次命令の
取得に備えてPCの値を更新（例えば＋4）
2.命令の解読：命令レジスタの値をデコード
3.命令の実行：解読結果に従って実行
実際には，各命令は2進表現
でメモリに格納されている
命令の実行手順
PCの指す番地から取
得した命令を保持 プロセッサ
命令レジスタ
lw $t1, 320($s4)
実行する命令の
アドレス
アドレス
PC
0x0010c
主記憶
・・・
デコーダ
レジスタ
ALU
0x00104
add $t0, $s1, $s2
0x00108
sub $t1, $t0, $s3
0x0010c
lw $t1, 320($s4)
・・・
1.命令の取得：PCが指すアドレスの値をメモリ
から命令レジスタへ取得．同時に，次命令の
取得に備えてPCの値を更新（例えば＋4）
実際には，各命令は2進表現
でメモリに格納されている
2.命令の解読：命令レジスタの値をデコード
3.命令の実行：解読結果に従って実行
以降，繰り返し・・・
信頼できるマイクロプロセッサとは?
マイクロプロセッサのお仕事は？
「正しいプログラム」を「正しく実行」する
正しい命令の取得（フェッチ）と実行の繰り返し
必要に応じてメモリにデータを正しく書込み/読出し
マイクロプロセッサにとっての「想定外事象」は？
正しく実行できない！
ハードウェア（回路）が正しく動作しない
誰かに実行を邪魔される
正しいプログラムではない！
不正なプログラムを実行させられる
コンピュータ・システムにおける
「想定外の事象」とは？
情報漏洩
Secure
Processor
コンピュータ
データ改竄
ウィルス
ソフトウェア
バグ
外部ノイズ
製造プロセ
スの揺らぎ
Reliable Processor
経年劣化
内部ノイズ
設計の誤り
なぜ、プロセッサでセキュリティ?
インターネット・セキュリティに関する多くの研究
システム・ソフトウェアに関する多くの研究
OS, Libraryなど
専用ハードウェアに関する多くの研究
暗号技術，不正侵入検知，認証技術など
特に暗号処理ハードウェア
プロセッサでのセキュリティに関する研究は???
2000年ごから「プロセッサ・アーキテクチャ」に関する国際会議
での発表が相次ぐ
コンピュータ処理の本質である「演算」と「記憶」の安全性
「最後の砦」では?（⇒トランジスタ・レベルでは難しい・・）
発表手順
はじめに
プログラム実行の乗っ取りを防止する!
信用できるプログラムしか実行しない!
その他のディペンダブル・プロセッサ
「ディペンダビリティ」はより重要になる!
不正プログラムの実行
を防止する!
攻撃方法が既知の場合
ハードウェアによる攻撃の検知
猛威を振るうコンピュータ・ウィルス
10億米ドル
1.2～1.5兆円の規模で推移
独立行政法人 情報処理推進機構, “国内・国外におけるコンピュータ
ウイルス被害状況調査,” 2003情財第0314号, 2004年4月
バッファ・オーバフロー攻撃
バッファ・オーバフロー
最も多く活用される脆弱性の１つ
Blaster@2003, CodeRed@2001
CERTバッファ・オーバフロー勧告
メカニズム
データ境界を越えた書込み
C標準ライブラリ内に存在（strcpyなど）
スタックの破壊（スタック・スマッシング）
悪質コードの挿入と戻りアドレスの改ざん
プログラム実行制御の乗っ取り
改ざん後の戻りアドレスがＰＣへ設定
R.B.Lee, D.K.Karig, J.P.McGregor, and Z.Shi, “Enlisting Hardware
Architecture to Thwart Malicious Code Injection,” Proc. of the Int.
Conf. on Security in Pervasive Computing, Mar. 2003.
関数呼出し/復帰時の動作
実行
コード
処理
手順
int f ( ) {
…
g (s1);
…
}
int g ( char *s1) {
char buf [10];
…
strcpy(buf, s1);
…
}
1.
2.
3.
4.
関数f ( )の実行
関数g( )の呼出し
文字列コピー
関数f( )へ復帰
関数呼出し/復帰時の動作
実行
コード
処理
手順
int f ( ) {
…
g (s1);
…
}
int g ( char *s1) {
char buf [10];
…
strcpy(buf, s1);
…
}
1.
2.
3.
4.
関数f ( )の実行
関数g( )の呼出し
文字列コピー
関数f( )へ復帰
上位アドレス
FP
s1
g()呼出し
戻りアドレス
の次命令
スタックの
伸張
FP退避
ローカル変数
buf
SP
下位アドレス
関数呼出し時の
スタック
正常時
関数呼出し/復帰時の動作
実行
コード
処理
手順
int f ( ) {
…
g (s1);
…
}
int g ( char *s1) {
char buf [10];
…
strcpy(buf, s1);
…
}
1.
2.
3.
4.
関数f ( )の実行
関数g( )の呼出し
文字列コピー
関数f( )へ復帰
上位アドレス
FP
s1
g()呼出し
戻りアドレス
の次命令
スタックの
伸張
FP退避
ローカル変数
buf
文字列
SP
下位アドレス
関数呼出し時の
スタック
正常時
関数呼出し/復帰時の動作
実行
コード
処理
手順
int f ( ) {
…
g (s1);
…
}
int g ( char *s1) {
char buf [10];
…
strcpy(buf, s1);
…
}
1.
2.
3.
4.
関数f ( )の実行
関数g( )の呼出し
文字列コピー
関数f( )へ復帰
上位アドレス
FP
s1
g()呼出し
戻りアドレス
の次命令
スタックの
伸張
FP退避
ローカル変数
buf
文字列
SP
下位アドレス
関数呼出し時の
スタック
正常時
スタック・スマッシングによる実
行制御の乗っ取り
実行
コード
処理
手順
int f ( ) {
…
g (s1);
…
}
int g ( char *s1) {
char buf [10];
…
strcpy(buf, s1);
…
}
1.
2.
3.
4.
関数f ( )の実行
関数g( )の呼出し
文字列コピー
関数f( )へ復帰
上位アドレス
FP
s1
g()呼出し
戻りアドレス
の次命令
スタックの
伸張
FP退避
ローカル変数
buf
文字列
SP
下位アドレス
関数呼出し時の
スタック
正常時
スタック・スマッシングによる実
行制御の乗っ取り
実行
コード
処理
手順
int f ( ) {
…
g (s1);
…
}
int g ( char *s1) {
char buf [10];
…
strcpy(buf, s1);
…
}
1.
2.
3.
4.
関数f ( )の実行
関数g( )の呼出し
文字列コピー
関数f( )へ復帰
上位アドレス
上位アドレス
FP
FP
s1
g()呼出し
戻りアドレス
の次命令
スタックの
伸張
FP退避
スタックの
伸張
FP退避
ローカル変数
ローカル変数
buf
buf
文字列
SP
下位アドレス
s1
g()呼出し
戻りアドレス
の次命令
SP
関数呼出し時の
スタック
異常時
下位アドレス
関数呼出し時の
スタック
正常時
スタック・スマッシングによる実
行制御の乗っ取り
実行
コード
処理
手順
int f ( ) {
…
g (s1);
…
}
int g ( char *s1) {
char buf [10];
…
strcpy(buf, s1);
…
}
1.
2.
3.
4.
関数f ( )の実行
関数g( )の呼出し
文字列コピー
関数f( )へ復帰
上位アドレス
上位アドレス
FP
FP
s1
攻撃コー
g()呼出し
戻りアドレス
ドの先頭
の次命令
スタックの
伸張
FP退避
s1
g()呼出し
戻りアドレス
の次命令
スタックの
伸張
攻撃
ローカル変数
コード
ローカル変数
buf
SP
下位アドレス
FP退避
buf
文字列
SP
関数呼出し時の
スタック
異常時
下位アドレス
関数呼出し時の
スタック
正常時
スタック・スマッシングによる実
行制御の乗っ取り
実行
コード
処理
手順
int f ( ) {
…
g (s1);
…
}
int g ( char *s1) {
char buf [10];
…
strcpy(buf, s1);
…
}
1.
2.
3.
4.
関数f ( )の実行
関数g( )の呼出し
文字列コピー
関数f( )へ復帰
上位アドレス
上位アドレス
FP
FP
s1
攻撃コー
戻りアドレス
ドの先頭
スタックの
伸張
FP退避
s1
g()呼出し
戻りアドレス
の次命令
スタックの
伸張
攻撃
ローカル変数
コード
ローカル変数
buf
SP
下位アドレス
FP退避
buf
文字列
SP
関数呼出し時の
スタック
異常時
下位アドレス
関数呼出し時の
スタック
正常時
動的な戻りアドレス改ざん検出
～Secure Cache: SCache～
プロセッサ
コア
問題点：
CPU
スタック
Mem.
スタックに書込んだ戻りアドレスが改ざんされる
解決策：
キャッシュ
キャッシュで戻りアドレスを保護しよう！
手段：
戻りアドレス書込み時に複製（レプリカ・ライン）を作成
戻りアドレス読出し時に複製と比較
不一致であれば戻りアドレス改ざん発生と判定
内部構成
レプリカ・フラグ
R-flag （1b)
tag
way0
Ref. Addr.
Index
Tag
Offset
Data (Ret. Addr.)
way1
way2
way3
ML
RL
RL
master
Tag Match
&& R-flag
Tag Match
&& no R-flag
RL: Replica Line
ML: Master Line
ヒット条件
HIT?
Store (push)
Data (Ret. Addr.)
Word-Data
Match
Safe?
replica
data
(line)
レプリカ・ライン
用選択回路
replica
Replica-MUX
Read-MUX
ワード比較器
（32b）
Load (pop)
動作（戻りアドレス書込み時）
RL: Replica Line
ML: Master Line
キャッシュ・アクセス
（戻りアドレス）
Store
no
yes
Load
Original
Data
Replica
tag
Store?
way0
戻りアドレスをMLへストア
全てのウェイからラインを読出し
(MLから戻りアドレス値を出力)
同一タグのRLが存在する
場合は上書き
RLヒット(タグ比較)
way1
way2
data
(line)
no
R-flag
yes
no
RL数＝Nrepとなるまで新
規RLを作成
way3
Replica-MUX
戻りアドレス一致
yes
Read-MUX
Word-Data
Match
正常終了
危険異常終了
キャッシュ・ヒット時
安全正常終了
危険正常終了
Data (Ret. Addr.)
Safe?
生成レプリカ数（Nrep）=2の場合
動作（戻りアドレス読出し時）
RL: Replica Line
ML: Master Line
キャッシュ・アクセス
（戻りアドレス）
Store
no
yes
Load
tag
Store?
way0
戻りアドレスをMLへストア
全てのウェイからラインを読出し
(MLから戻りアドレス値を出力)
同一タグのRLが存在する
場合は上書き
RLヒット(タグ比較)
way1
危険異常終了
キャッシュ・ヒット時
安全正常終了
data
(line)
Replica
Replica-MUX
戻りアドレス一致
yes
way3
R-flag
no
RL数＝Nrepとなるまで新
規RLを作成
way2
no
yes
正常終了
Data
Original
危険正常終了
Data (Ret. Addr.)
Read-MUX
Word-Data
Match
Safe?
生成レプリカ数（Nrep）=2の場合
SCacheの特徴（利点と欠点）
Pros
戻りアドレス改ざんの動的検
出が可能
ただし、レプリカ・ラインが存在
する場合のみ
プロセッサの内部構成へ与え
る影響は極めて小さい
アクセス時間/面積オーバヘッ
ドは極めて小さい
レプリカ数を変更可能
安全性と消費エネルギーのバ
ランスを決定可能
Cons
レプリカ作成に伴うヒット率の
低下
平均メモリアクセス時間の増大
下位階層メモリへのアクセス消
費エネルギー増大
レプリカ作成に伴う消費エネ
ルギーの増加
書込みエネルギーの増大
ライトバック・エネルギーの増大
読出しエネルギーの増大（他低
消費電力キャッシュと比較して）
評価環境
消費エネルギー
安全性/消費エネルギー/性能
SimpleScalar3.0
16KB 4-way Dキャッシュ
ラインサイズ：32B
2-way IO/4-way OOO実行
SPEC2000
7個のintプログラム
4個のfpプログラム
Small input（完全実行）
4KB×4 SRAM設計
0.18μm CMOSプロセス
Scache機構は未実装
8bメモリセルが1個のラッチ
型センスアンプを共有
回路シミュレーション
カスタム・レイアウトと容量抽
出（周辺回路は含まない）
ビット当たりのアクセス消費
エネルギー測定
評価モデル
評価対象モデル
モデル レプリカ生成ポリシ
LRU1L
配置
LRU
数
1
追出し禁止
LRU1
LRU2
MRU1
LRU
LRU
MRU
1
2
1
MRU2
ALL
CONV
MRU
-----
2
3
MRUウェイ予測
危険度
Vulnerability = (Nv-rald / Nrald) * 100
安全性を保障できない
戻りアドレス・ロード回数
全戻りアドレス
ロード回数
消費エネルギー
Etotal = Erd + Ewt + Ewb + Emp
読出し 書込み
キャッシュ・ミス
レプリカ生成に伴う
ライトバック
キャッシュミス率（2-way IO）
Benchmark
#IRA
Load(Nrald)
CONV
LRU1L
LRU1
LRU2
MRU1
MRU2
ALL
164.gzip
4,932,448
5.18%
5.20%
5.18%
5.19%
5.19%
5.19%
5.21%
175.vpr
8,227,868
3.63%
3.69%
3.67%
3.74%
3.70%
3.77%
3.86%
176.gcc
34,850,486
4.37%
4.42%
4.39%
4.47%
4.43%
4.53%
4.75%
181.mcf
98,2013
20.93%
20.96%
20.94%
20.95%
20.97%
20.98%
21.02%
197.parser
47,935,856
4.17%
4.30%
4.22%
4.51%
4.27%
4.57%
5.12%
255.vortex
22,411,559
1.72%
1.77%
1.76%
1.87%
1.78%
1.90%
2.27%
256.bzip
18,172,443
2.31%
2.32%
2.31%
2.33%
2.31%
2.33%
2.45%
177.mesa
4,731,538
0.15%
0.15%
0.15%
0.16%
0.15%
0.17%
1.09%
32,439
41.96%
41.96%
41.96%
41.96%
41.96%
41.96%
41.96%
183.equake
3,588,123
2.46%
2.47%
2.46%
2.48%
2.47%
2.49%
2.54%
188.ammp
6,307,811
30.31%
30.32%
30.32%
30.34%
30.31%
30.33%
30.40%
179.art
レプリカ数の増加と共にミス率は悪化
ALLでもミス率増加の影響は極めて小さい
どの程度安全なのか?
Vulnerability
2-way In-Order Processor
164.gzip
176.gcc
197.parser
256.bzip2
179.art
188.ammp
175.vpr
181.mcf
255.vortex
177.mesa
183.equake
13.7% 16.8% 23.4% 12.5%
Vulnerability
4-way OOO Processor
164.gzip
176.gcc
197.parser
256.bzip2
179.art
188.ammp
175.vpr
181.mcf
255.vortex
177.mesa
183.equake
LRU1L
LRU1
LRU2
MRU1
MRU2
ALL
Normalized Energy
CONV
LRU1L
LRU1
LRU2
MRU1
MRU2
ALL
どの程度エネルギーを消費する
のか?
164.gzip
175.vpr
176.gcc
2-way In-Order Processor
Emp
Ewb
Ewt
Erd
197.parser
256.bzip2
179.art
188.ammp
181.mcf
255.vortex
177.mesa
183.equake
レプリカ数の増加に伴い「Ewt」と「Emp」が増大
オーバヘッドは20%以下（4-way OOOでも同様）
どの程度性能が低下するのか?
Performance Overhead
2-way In-Order Processor
LRU1L
LRU1
LRU2
MRU1
MRU2
ALL
164.gzip
176.gcc
197.parser
256.bzip2
179.art
188.ammp
175.vpr
181.mcf
255.vortex
177.mesa
183.equake
レプリカの増加に伴い性能は低下
性能低下は1%以下（「All」と「197.parser」除く）
不正プログラムの実行
を防止する!
攻撃方法が未知の場合
動的なプログラム実行の認証
現在の主な不正プログラム対策
と問題点
ブラックリスト方式
→既知の不正プログラム
を検出して駆除
Trusted
Programs
B
C
ホワイトリスト方式
→認められたプログラムのみ
を実行
Virus
Key Program
X
A
D
CPU
A
+
Y
OS
Z
CPU
問題点
データベースが必要（ウィルス定義
リストやルール定義リスト）
新種ウィルスに対応できない
A
問題点
鍵照合プログラムが改ざんされた
場合は機能しない
実行中に突然ウィルスが暴走した
場合は対応できない
実行の振舞いに基づく動的プロ
グラム認証方式
秘密鍵より「プログラム認証のための実行の振舞い」を決定
Memory-Access Patternなど
コンパイル時に「決定した実行振舞い」を実現できるようコー
ドを生成
実行時に「実行の振舞い」をモニタリング
同一プログラムでも異なる振舞いを鍵情報として実現
Program
compile
Secret Key
Behavior
Model
object
code
Behavior
Model
?
CPU
鍵となる実行の振舞い（例）
～メモリアクセス・パタン～
「ある実行命令数毎に必ずアドレスAにアクセスする」
正規
プログラム
N命令
プロファイラ
実行終了
実行制御の
乗っ取り！
アタック
コード
プロファイラ
コンパイル時における実行振舞
いコントロール
基本
ブロック
分岐命令への対応
基本ブロック・サイズ
の統一
投機/OOO実行への
対応
コミット時にチェック
鍵となる
メモリアクセス命令
Load for Key
Nop
Original
BB Size (#Inst.)
Normalized Exe. Time
Normalized Code Size
性能/コスト・オーバヘッド
StrongARM Model
•In-Order execution
•Branch Pred. (not-taken)
BB Size (#Inst.)
統一基本ブロックサイズの縮小に伴い性能/
コードサイズ・オーバヘッドは増大
信頼性の向上
ハードウェア資源を有効利用!
いまどきのプロセッサ（例）
POWER6 Microprocessor
Jeffrey Kellington et. al., “IBM POWER6 Processor Soft Error Tolerance Analysis Using Proton Irradiation ,” IEEE
Workshop on Silicon Errors In Logic (SELSE3), Apr. 2007. (http://www.selse.org/selse07.program.linked.htm)
マルチスレッド・プロセッサでの
空間冗長化
IF：命令フェッチ
ID：命令デコード
IS：命令発行
EX：命令実行
MEM：メモリアクセス
WB：ライトバック
FC：フォールト・チェック
ID
IS
EX MEM WB
IF
2つの異なるスレッドを
同時実行可能（SMT）
FC
FC
FC
追跡スレッド
命令A’
ID
メイン
パイプライン
追跡スレッドの実
行終了まで待機
先行スレッド
命令A
IF
プログラム
プログラム
IS
EX MEM WB
実行
再実行
結果を比較
FC
実行結果
を比較
FC
不一致の場合は実行をや
り直し（命令フェッチから）
命令A
IF
ID
IS
EX MEM
T. N. Vijaykumar, I. Pomeranz, and K. Cheng, “Transient-Fault Recovery Using Simultaneous
Multithreading,” International Symposium on Computer Architecture, pp.87-98, May 2002.
時間
バグ対策
ハードウェア資源を有効利用!
商用プロセッサにおけるバグ
1994
Pentium defect costs Intel $475 million
1999
Defect leads to stoppage in shipping Pentium III servers
2004
AMD Opteron defect leads to data loss
2005
A version of Itanium 2 recalled
Design Defect
Non-Critical
Critical
Performance counters
Error reporting registers
Breakpoint support
Defects in memory, IO, etc.
Concurrent
Complex
All signals – same time
Different times
J. Torrellas, “Novel Architectural Techniques to Mitigate Processor Errors due to Design Defects and Parameter
Variation,” CoolChips’07.
どのようなバグが，どの程度あるのか?
商用プロセッサのエラーレポートを調査
Intel Pentium III, IV, M, and Itanium I and II, AMD K6, Athlon, Athlon 64,
IBM G3 (PPC 750 FX), MOT G4 (MPC 7457)
31%
69%
J. Torrellas, “Novel Architectural Techniques to Mitigate Processor Errors due to Design Defects and Parameter
Variation,” CoolChips’07.
どこにバグが潜んでいるのか?
プロセッサコアのバグは比較的少ない
メモリ周りのバグが多い
J. Torrellas, “Novel Architectural Techniques to Mitigate Processor Errors due to Design Defects and Parameter
Variation,” CoolChips’07.
Phoenix: Hardware Patching
Signature Buffer
Concurrent Defect（CD）に着目
イベント信号の状態を監視すれば検
出可能
e.g. L1 miss, L2 flush, and Power
Management ON
バグが見つかったら・・・
ベンダーからCD発生条件に関する情報
入手(Defect Signature)
SSUとBDRを再構成
CE発生条件が成立したらリカバリ
pipeline flush, recovery handler
Programmable HW
Signal Selection Unit
(SSU)
Bug Detection Unit
(BDU)
Global Recovery Unit
S. R. Sarangi, A. Tiwari, and J. Torrellas, “Phoenix: Detecting and Recovering from Permanent Processor Design Bugs
with Programmable Hardware,” MICRO’06.
Phoenixの実装
Subsystem
To Recovery
Unit
BDU
Neighborhood
Subsystem
SSU
HUB
Examples of Subsystems
Inst. Cache
FP ALU
Virtual Mem.
Fetch Unit
L1 Cache
IO Cntrl.
S. R. Sarangi, A. Tiwari, and J. Torrellas, “Phoenix: Detecting and Recovering from
Permanent Processor Design Bugs with Programmable Hardware,” MICRO’06.
SSU
To Recovery
Unit
BDU
Phoenixのバグ検出/回復能力
10種類のプロセッサをベースにPhonixを設計
他5種類のプロセッサでバグ検出/回復能力を評価
S. R. Sarangi, A. Tiwari, and J. Torrellas, “Phoenix: Detecting and Recovering from Permanent Processor Design Bugs
with Programmable Hardware,” MICRO’06.
「ディペンダビリティ」はよ
り重要になる!
「マルチコア」から「メニーコアへ」
現実味を帯びてきた「メニーコア」
（Intel 80cores）
Frequency
Voltage
Power
Aggrega
te
Bandwid
th
Perform
ance
3.16 GHz
0.95 V
62W
1.62
Terabits/
s
1.01
Teraflop
s
5.1 GHz
1.2 V
175W
2.61
Terabits/
s
1.63
Teraflop
s
5.7 GHz
1.35 V
265W
2.92
Terabits/
s
1.81
Teraflop
s
60
http://www.intel.com/research/platform/terascale/teraflops.htm?iid=newstab+supercomputing
オンチップ・スーパーコンピュー
ティング@2017
チップ内コア数：×[email protected]年（ムーアの法則）
2017年には512コア（?）
10,000,000
Performance (Gflop/s)
Top 500 Supercomputers
source: http://www.top500.org/
1,000,000
Tsubame
100,000
Blue-Gene/L
Earth Simulator
10,000
Intel Test (80cores)
1,000
Cell (9cores)
ClearSpeed (96cores)
100
Power6, Xeon (2cores)
10
Single-Chip
Multi-Core Processors
1
1
10
100
1,000
10,000
Total Number of Processor Chips
100,000
ディペンダビリティの重要性
同一チップ上に「数百のコア」を集積→故障
対策は?検証は?
同一チップ上で「複数ユーザ」が「複数アプリ」
を実行→安全性は?
同一チップ上で「数百のスレッド」を同時に実
行→発熱に伴う信頼性の低下は?
などなど
宣伝その１
システムLSIワークショップ’07
システムLSIの新時代：未来を拓くヒトと技術
2007年11月19日～21日
北九州国際会議場
ポスター（73件の研究を一度にみれます！）
学生部門44件（学生による発表）
一般部門9件（企業や研究所による発表）
デザインガイア20件
宣伝その2
Cell Speed Challenge’07
マルチコア・プログラミングコンテスト
主催：情報処理学会ARC/EMB/HPC
先進的計算基盤システムシンポジウム
SACSIS2008との併設企画
超豪華賞品
PS3, HD DVDプレーヤー, 液晶テレビ(47型)など
スケジュール
11月初旬に参加申し込み開始予定（規定課題/自
由課題）
Back-Up Slides
メモリデータの改竄を
検出する!
メモリ整合性検証の高速化
メモリ・データの保護
Security boundary
（前提：オンチップはセキュア）
CPU
core
Tamper Resistant
→インテグリティ検証
改竄
L1$
L2$
Integrity
Verification
Memory
Encryption
Private Tamper Resistant
→オフチップ・データの暗号化
盗み見
メモリ整合性検証
M(t1)＝M(t2)：
メモリ整合性が保たれている⇒改ざんされていない
M(t1)≠M(t2)
改ざん発生！
Processor
Processor
Processor
読み込み
書き込み
memory
M(t0)
memory
M(t1)
データ改ざん
memory
の発生
M(t2)
t
t0
t1
書き込みが発生しない
t2
ハッシュ木によりメモリ・イメージの
ダイジェストを保存する！
データ読出し時
データ書込み時
On-Chip Storage
root=h(h5, h6) (Trusted)
メモリ整合性検証の実行
rootまでハッシュ値を比較
一致していればOK
ハッシュ木を更新
rootまでのハッシュ値を更新
書込み前にMIVを実行
ハッシュ値のキャッシングにより
性能オーバヘッドを削減
root
h5=h(h1, h2)
h1=h(V1)
h6=h(h3, h4)
h5
h6
h1
h2
h3
h4
v1
v2
v3
v4
h1 h2 h3 h4 h5 h6
Memory Space (insecure)
メモリ整合性検証により
プロセッサ性能が低下する！
理由：プログラム実行処理とメモリ整合性検証処
理が様々な「資源」を共有する！
具体的には・・
オンチップ・キャッシュ（⇒ミス率の増加）
オフチップ・メモリバス（⇒メモリバンド幅の浪費）
プロセッサが参照するデータ
プロセッサ
コア
整合性検証
ハッシュ値
キャッシュ
CPU
プロセッサが
参照するデータ
Mem.
キャッシュの衰退ラインを利用した
性能オーバヘッドの抑制
キャッシュの衰退ラインを活用
衰退ライン⇒プロセッサから参照されない（使用済み
の）データを保持しているデータブロック
衰退ライン（使用済みライン）にハッシュ値を格納
ハッシュ値のキャッシング時，プログラム実行に必要なデータ
を追い出さないようにする
プロセッサ
コア
整合性検証
衰退ライン
ハッシュ値
キャッシュ
CPU
プロセッサが
参照するデータ
Mem.
衰退ライン（使用済みライン）はどの
程度存在するのか？
L2キャッシュサイズ：128KB
177.mesa
167.gzip
255.vortex
キャッシュ中に格納すべきハッシュ
値の割合(%)
73.2
34.7
56.2
キャッシュ中に存在する衰退ライ
ンの割合(%)
99.1
98.3
98.4
60%
255.vortex
Overhead Reduction (%)
性能オーバヘッド削減率
Benchmark Programs
今後の展開
上位階層
Mem
ASIC
ASIC
CPU
LSI community
CPU
Mem
CPU
共同体としての処理
お互いの監視
自己状態の伝達
お互いに修復（助け合い）
悪影響を上位階層へ伝播させない仕組み
Trusted
Programs
Virus
A
D
B
C
CPU
安全性と消費エネルギーの
トレードオフ
LRU2 MRU1 MRU2 ALL
EV Product
E2V Product
3.5%
EV2 Product
Vulnerability
Vulnerability
LRU1-L&I
LRU1-L&U
MRU1-L&U
(Nv-rald / Nrald) * 100
Insecure issued
RA load
Total #of issued
RA load
Benchmark Programs
Performance Overhead
Performance Overhead
LRU1-L&I
LRU1-L&U
MRU1-L&U
Benchmark Programs
衰退ライン（使用済みライン）は
どの程度存在するのか？
衰退ラインが閉める割合(%)
総キャッシュラインに対してCPU/
ハッシュデータが占める割合（%）
8K
16K
32K
ハッシュデータが閉める割合(%)
64K
chash
100
80
60
40
20
0
mesa
gcc
vortex
ベンチマーク・プログラム
bzip
安全性に関する考察
不正プログラム実行可能性
鍵情報の推測容易性
秘密鍵情報の漏洩→安全な秘密鍵管理
不正プログラム実行命令数＜鍵命令実行間隔→短い間隔
外部からの実行振舞い観測→プロファイラのオンチップ化
不正プログラム伝播容易性
同一秘密鍵→ユーザ/プログラム毎で異なる実行の振舞い
を実現可能
UL2 Cache Miss Rate (%)
プロセッサ性能オーバヘッドの削減
Conventional
Proposed
4-way OOO Superscalar Processor
128KB 4-way set-associative UL2 Cache
キャッシュミスによる影響のみ考慮
Performance Overhead (%)
Benchmark program
Conventional
Proposed
Benchmark program
Performance Overhead (%)
性能オーバヘッド
Conventional
Proposed
Benchmark Programs
Table 1: Processor Configurations
2-way In-Order
Superscalar
4-way Out-Of-Order
Superscalar
2
4
Bimodal (128-enrty),
1-way BTB(128-entry),
RAS(4-entry)
Gshare(4K-entry),
4-way BTB (512-set),
RAS(8-entry)
RUU
8
32
LSQ
8
16
L1 D-Cache
4-way 16KB, 32B lines
4-way 16KB, 32B lines
L1 I-Cache
2-way 16KB, 64B lines
2-way 32KB, 64B lines
none
4-way 512KB, 64B lines
64 cycles
64 cycles
1/1/1/1
4/2/4/2
Fetch/Issue/Commit
Width
Branch Prediction
L2 Cache
Memory Latency
Function Unit
iALU/iMUL/fALU/fMUL
本講演でのトピック
Architectural Support for
ＩＬＰ
ＴＬＰ
分岐予測
スラック予測
命令パイプライン
スーパスカラ
アドレス予測
ＯＯＯ実行
シグナル・ゲーティング
ＤＶＳ
パイプライン統合
リサイジング
選択的活性化
値予測
プリフェッチ
キャッシュ
CTV
BPRF
クロック・ゲーティング
© Copyright 2024 ExpyDoc
