情報社会を支えるディペンダブル・プロセッサ

情報社会を支えるディペンダブル・プロセッサ

九州大学井上弘士（いのうえこうじ）

ディペンダブル・コンピューティング（ Dependable Computing）

あなたにとって，「○○先生」は頼りになりますか？ YES!

私の質問に対して，常に，正しい解答を示してくれる私に危害を加えない（私を裏切らない）勝手に他人へ危害を加えないなどなど

NO! 私の質問に対して，常に（たまに），誤った解答を示す私に危害を加える（突然きれる，突然暴れる）他人へ危害を加えるなどなど

頼る～できる計算すること

ディペンダブル・コンピューティング（ Dependable Computing）

「頼りになる」とは？提供されるサービス（利用者が認識するシステムの振舞い）が正確で信頼できる

結果として利用者に損害をもたらさない，また，被害が発生しても最小限に留める

でも現実は・・・様々な「想定外の事象」により正確性や信頼性が失われる「常に 100%正確かつ信頼できるシステム」はありえない

そこで・・・ Dependability：予測不可能性（想定外事象）を秘めた系において，システムに期待されるサービスが許容範囲内で提供される事を保障すること

Dependable Computing：「想定外事象は発生するもの」という前提に立ち，それを解決（回避）可能なシステムで計算する！

頼る～できる計算すること

ここまで発展したマイクロプロセッサ（シングルコア）

4004@1971(108KHz)

i486@1989(25MHz)

Pentium@1993(60MHz)

Pentium2@1997(450MHz)

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

PPE512KB

L2キャッシュ

Cell (Sony/Toshiba/IBM)

Niagara-T2 (Sun)

Opteron(AMD):http://techreport.com/

Opteron (AMD)

http://news.com.com/

0.1

1

10

100

1000

1984

1986

1988

1990

1992

1994

1996

1998

2000

2002

2004

80386

80486

Pentium

Pentium II

Pentium III

Pentium 4

Itanium

プロセッサの回路規模はどの程度 ?（トランジスタ数の観点から）

半導体集積度は３年で約４倍に！（ムーアの法則）インテル・プロセッサの場合

M Tr

an.

http://www-vlsi.stanford.edu/group/chips_micropro.html

On-Chip L1$

Super Scalar

Out-Of-OrderRenamingOn-Chip L2$

Trace CacheHyper Threading

命令の実行手順

・・・

add $t0, $s1, $s2

sub $t1, $t0, $s3

lw $t1, 320($s4)

・・・

主記憶アドレス

0x00104

0x00108

0x0010c

実際には，各命令は 2進表現でメモリに格納されている

レジスタ

0x00104デコーダ

プロセッサ

ALU

PC命令レジスタ

1.命令の取得： PCが指すアドレスの値をメモリから命令レジスタへ取得．同時に，次命令の取得に備えて PCの値を更新（例えば＋ 4）

2.命令の解読：命令レジスタの値をデコード

3.命令の実行：解読結果に従って実行

プロセッサ

レジスタ

0x00104デコーダ

add $t0, $s1, $s2・・・




add $t0, $s1, $s2

sub $t1, $t0, $s3

lw $t1, 320($s4)

・・・


0x00104

0x00108

0x0010c


PCの指す番地から取得した命令を保持実行する命令の

アドレス

ALU



レジスタ

0x00108デコーダ

add $t0, $s1, $s2・・・




add $t0, $s1, $s2

sub $t1, $t0, $s3

lw $t1, 320($s4)

・・・


0x00104

0x00108

0x0010c


次命令の取得にそなえて PCを更新

ALU

プロセッサ



ALUレジスタ

0x00108デコーダ

add $t0, $s1, $s2・・・




add $t0, $s1, $s2

sub $t1, $t0, $s3

lw $t1, 320($s4)

・・・


0x00104

0x00108

0x0010c


取得した命令を解読（ s1と s2を加算し， t0へ格納）

プロセッサ



ALUレジスタ

0x00108デコーダ

add $t0, $s1, $s2・・・




add $t0, $s1, $s2

sub $t1, $t0, $s3

lw $t1, 320($s4)

・・・


0x00104

0x00108

0x0010c


加算

プロセッサ



プロセッサ

レジスタ

0x00108デコーダ

sub $t1, $t0, $s3・・・




add $t0, $s1, $s2

sub $t1, $t0, $s3

lw $t1, 320($s4)

・・・


0x00104

0x00108

0x0010c



アドレス

ALU



レジスタ

0x0010cデコーダ

sub $t1, $t0, $s3・・・




add $t0, $s1, $s2

sub $t1, $t0, $s3

lw $t1, 320($s4)

・・・


0x00104

0x00108

0x0010c


ALU

次命令の取得にそなえて PCを更新

プロセッサ



ALUレジスタ

0x0010cデコーダ

sub $t1, $t0, $s3・・・




add $t0, $s1, $s2

sub $t1, $t0, $s3

lw $t1, 320($s4)

・・・


0x00104

0x00108

0x0010c


取得した命令を解読（ t0と s3を減算し， t1へ格納）

プロセッサ



ALUレジスタ

0x0010cデコーダ

sub $t1, $t0, $s3・・・




add $t0, $s1, $s2

sub $t1, $t0, $s3

lw $t1, 320($s4)

・・・


0x00104

0x00108

0x0010c


減算

プロセッサ



プロセッサ

レジスタ

0x0010cデコーダ

lw $t1, 320($s4)・・・




add $t0, $s1, $s2

sub $t1, $t0, $s3

lw $t1, 320($s4)

・・・


0x00104

0x00108

0x0010c



アドレス

ALU

以降，繰り返し・・・



信頼できるマイクロプロセッサとは ?

マイクロプロセッサのお仕事は？「正しいプログラム」を「正しく実行」する

正しい命令の取得（フェッチ）と実行の繰り返し必要に応じてメモリにデータを正しく書込み /読出し

マイクロプロセッサにとっての「想定外事象」は？正しく実行できない！

ハードウェア（回路）が正しく動作しない誰かに実行を邪魔される

正しいプログラムではない！不正なプログラムを実行させられる

コンピュータ・システムにおける「想定外の事象」とは？

製造プロセスの揺らぎ

設計の誤り

情報漏洩

コンピュータウィルス

ソフトウェア

バグ

外部ノイズ

内部ノイズ

データ改竄

経年劣化

Reliable Processor

Secure ProcessorPatchable

Processor

なぜ、プロセッサでセキュリティ ?

インターネット・セキュリティに関する多くの研究暗号技術，不正侵入検知，認証技術など

システム・ソフトウェアに関する多くの研究 OS, Libraryなど

専用ハードウェアに関する多くの研究特に暗号処理ハードウェア

プロセッサでのセキュリティに関する研究は ??? 2000年ごから「プロセッサ・アーキテクチャ」に関する国際会議での発表が相次ぐ

コンピュータ処理の本質である「演算」と「記憶」の安全性「最後の砦」では ?（⇒トランジスタ・レベルでは難しい・・）

発表手順

はじめにプログラム実行の乗っ取りを防止する !信用できるプログラムしか実行しない !その他のディペンダブル・プロセッサ「ディペンダビリティ」はより重要になる !

不正プログラムの実行を防止する !

攻撃方法が既知の場合

ハードウェアによる攻撃の検知

猛威を振るうコンピュータ・ウィルス

10億

米ドル

独立行政法人情報処理推進機構 , “ 国内・国外におけるコンピュータウイルス被害状況調査 ,” 2003情財第 0314 号 , 2004年 4 月

1.2～ 1.5 兆円の規模で推移

バッファ・オーバフロー攻撃

バッファ・オーバフロー最も多く活用される脆弱性の１つ

Blaster@2003, CodeRed@2001 CERT バッファ・オーバフロー勧告

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.

メカニズムデータ境界を越えた書込み

C 標準ライブラリ内に存在（ strcpyなど）スタックの破壊（スタック・スマッシング）

悪質コードの挿入と戻りアドレスの改ざんプログラム実行制御の乗っ取り

改ざん後の戻りアドレスがＰＣへ設定

関数呼出し / 復帰時の動作int f ( ) { … g (s1); …}

int g ( char *s1) { char buf [10]; … strcpy(buf, s1); …}

実行コード

1. 関数 f ( )の実行2. 関数 g( )の呼出し3. 文字列コピー4. 関数 f( )へ復帰

処理手順

s1

戻りアドレス

FP退避

ローカル変数buf

FP

SP

上位アドレス

下位アドレス

スタックの伸張

関数呼出し時のスタック

正常時



実行コード


処理手順

g() 呼出しの次命令

s1

戻りアドレス

FP退避


FP

SP

上位アドレス

下位アドレス



正常時



実行コード


処理手順


文字列



実行コード


処理手順

s1

戻りアドレス

FP退避


FP

SP

上位アドレス

下位アドレス



正常時

文字列


スタック・スマッシングによる実行制御の乗っ取りint f ( ) { … g (s1); …}


実行コード


処理手順

s1

戻りアドレス

FP退避


FP

SP

上位アドレス

下位アドレス



正常時

文字列




実行コード


処理手順

s1

戻りアドレス

FP退避


FP

SP

上位アドレス

下位アドレス



正常時

文字列


s1

戻りアドレス

FP退避


FP

SP

上位アドレス

下位アドレス



異常時


s1

戻りアドレス

FP退避


FP

SP

上位アドレス

下位アドレス



異常時




実行コード


処理手順

攻撃コードの先頭

攻撃コード

s1

戻りアドレス

FP退避


FP

SP

上位アドレス

下位アドレス



正常時

文字列




実行コード


処理手順

s1

戻りアドレス

FP退避


FP

SP

上位アドレス

下位アドレス



異常時

攻撃コードの先頭

攻撃コード

s1

戻りアドレス

FP退避


FP

SP

上位アドレス

下位アドレス



正常時

文字列


CPU

動的な戻りアドレス改ざん検出～ Secure Cache: SCache～

問題点：スタックに書込んだ戻りアドレスが改ざんされる

解決策：キャッシュで戻りアドレスを保護しよう！

手段：戻りアドレス書込み時に複製（レプリカ・ライン）を作

成戻りアドレス読出し時に複製と比較不一致であれば戻りアドレス改ざん発生と判定

Mem.

プロセッサコアキャッシュスタック

ML RL RL

way0 way1 way2 way3tag

data(line)

Data (Ret. Addr.) Load (pop)

Replica-MUX

Safe?

replica replica

Read-MUX

masterTag Match && R-flag

Tag Match&& no R-flag

HIT?

Word-DataMatch

Ref. Addr.Index

TagOffset

Store (push)Data (Ret. Addr.)

RL: Replica LineML: Master Line

R-flag

内部構成

レプリカ・ライン用選択回

路

ワード比較器（ 32b）

ヒット条件

レプリカ・フラグ（ 1b)


data(line)

Data (Ret. Addr.)

Replica-MUX

Safe?

Read-MUXWord-Data

Match

Data

R-flag

動作（戻りアドレス書込み時）

キャッシュ・アクセス（戻りアドレス）

Store?yes

戻りアドレスをMLへストア

RL数＝Nrepとなるまで新規RLを作成

正常終了

Store

同一タグのRLが存在する場合は上書き


no

全てのウェイからラインを読出し(MLから戻りアドレス値を出力)

RLヒット(タグ比較)

戻りアドレス一致

Load

yes

危険正常終了

no

安全正常終了

noyes

危険異常終了

生成レプリカ数（ Nrep）=2の場合

Original Replica

キャッシュ・ヒット時

動作（戻りアドレス読出し時）


data(line)

Data (Ret. Addr.)

Replica-MUX

Safe?

Read-MUXWord-Data

Match

Data

R-flag

OriginalReplica

キャッシュ・アクセス（戻りアドレス）

Store?


no

全てのウェイからラインを読出し(MLから戻りアドレス値を出力)

RLヒット(タグ比較)

戻りアドレス一致

Load

yes

危険正常終了

no

安全正常終了

noyes

危険異常終了

yes

戻りアドレスをMLへストア

RL数＝Nrepとなるまで新規RLを作成

正常終了

Store

同一タグのRLが存在する場合は上書き

生成レプリカ数（ 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 LRU 1LRU2 LRU 2MRU1 MRU 1MRU2 MRU 2ALL ----- 3CONV MRUウェイ予測

Vulnerability = (Nv-rald / Nrald) * 100

全戻りアドレスロード回数

安全性を保障できない戻りアドレス・ロード回数

消費エネルギーEtotal = Erd + Ewt + Ewb + Emp

読出し書込み

レプリカ生成に伴うライトバック

キャッシュ・ミス

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%179.art 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%

キャッシュミス率（ 2-way IO）

レプリカ数の増加と共にミス率は悪化 ALLでもミス率増加の影響は極めて小さい

どの程度安全なのか ?Vu

lner

abilit

y

LRU1LLRU1LRU2MRU1MRU2ALL

13.7% 16.8% 23.4% 12.5%

Vuln

erab

ility

164.gzip 176.gcc 197.parser 256.bzip2 179.art 188.ammp 175.vpr 181.mcf 255.vortex 177.mesa 183.equake


2-way In-Order Processor

4-way OOO Processor

どの程度エネルギーを消費するのか ?

レプリカ数の増加に伴い「 Ewt」と「 Emp」が増大

オーバヘッドは 20%以下（ 4-way OOOでも同様）

CONV

LRU1

LLR

U1LR

U2M

RU1

MRU

2AL

L

Norm

alize

d En

ergy

EmpEwb

EwtErd



どの程度性能が低下するのか ?

レプリカの増加に伴い性能は低下性能低下は 1%以下（「 All」と「 197.parser」除く）

Perfo

rman

ce O

verh

ead


LRU1LLRU1LRU2MRU1MRU2ALL


不正プログラムの実行を防止する !

攻撃方法が未知の場合

動的なプログラム実行の認証

ブラックリスト方式→ 既知の不正プログラムを検出して駆除

ホワイトリスト方式→認められたプログラムのみを実行

現在の主な不正プログラム対策と問題点

問題点データベースが必要（ウィルス定義リストやルール定義リスト）

新種ウィルスに対応できない

CPU

A B C DXYZ

CPUCPU

A B C DXYZ

TrustedPrograms

Virus

問題点鍵照合プログラムが改ざんされた場合は機能しない

実行中に突然ウィルスが暴走した場合は対応できない

CPU

A + A

CPUCPU

A + A

ProgramKey

OS

実行の振舞いに基づく動的プログラム認証方式

秘密鍵より「プログラム認証のための実行の振舞い」を決定

Memory-Access Patternなどコンパイル時に「決定した実行振舞い」を実現できるようコードを生成

実行時に「実行の振舞い」をモニタリング同一プログラムでも異なる振舞いを鍵情報として実現Program

BehaviorModel

compile object code

Secret KeyCPUBehavior

Model ?

鍵となる実行の振舞い（例）～メモリアクセス・パタン～

正規プログラム実行終了

アタックコード

実行制御の乗っ取り！

プロファイラ

「ある実行命令数毎に必ずアドレス Aにアクセスする」

N命令

プロファイラ

コンパイル時における実行振舞いコントロール

分岐命令への対応基本ブロック・サイズの統一

投機 /OOO実行への対応コミット時にチェック

基本ブロック

鍵となるメモリアクセス命令

性能 /コスト・オーバヘッド

StrongARM Model • In-Order execution• Branch Pred. (not-taken)

Load for KeyNopOriginal

Norm

alize

d Co

de S

ize

BB Size (#Inst.)No

rmal

ized

Exe.

Tim

eBB 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命令 A

IF ID IS EX MEM WB FC命令 A’

実行結果を比較

FC FC FC

IF ID IS EX MEM命令 A

不一致の場合は実行をやり直し（命令フェッチか

ら）2つの異なるスレッドを同時実行可能（ SMT）

時間

IF：命令フェッチID：命令デコードIS：命令発行EX：命令実行MEM：メモリアクセスWB：ライトバックFC：フォールト・チェック

プログラムプログラム

メインパイプライン

実行再実行

結果を比較

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 million1999 Defect leads to stoppage in shipping Pentium III servers

2004 AMD Opteron defect leads to data loss2005 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.

31%

69%

どのようなバグが，どの程度あるのか ?

商用プロセッサのエラーレポートを調査Intel Pentium III, IV, M, and Itanium I and II, AMD K6, Athlon, Athlon 64,IBM G3 (PPC 750 FX), MOT G4 (MPC 7457)


どこにバグが潜んでいるのか ?

プロセッサコアのバグは比較的少ないメモリ周りのバグが多い


Phoenix: Hardware Patching

Concurrent Defect（ CD）に着目イベント信号の状態を監視すれば検出可能

e.g. L1 miss, L2 flush, and Power Management ON

バグが見つかったら・・・ベンダーから CD発生条件に関する情報入手 (Defect Signature)

SSUと BDRを再構成 CE発生条件が成立したらリカバリ

pipeline flush, recovery handlerS. R. Sarangi, A. Tiwari, and J. Torrellas, “Phoenix: Detecting and Recovering from Permanent Processor Design Bugs with Programmable Hardware,” MICRO’06.

Signature Buffer

Bug Detection Unit(BDU)

Global Recovery Unit

Signal Selection Unit(SSU)

Programmable HW

Phoenixの実装

Subsystem

SSUBDU

Subsystem

BDUSSUHUB

Neighborhood

To RecoveryUnit

Inst. Cache

FP ALU Virtual Mem.

Fetch Unit L1 Cache IO Cntrl.

Examples of Subsystems

To 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のバグ検出 /回復能力

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.

「ディペンダビリティ」はより重要になる !

「マルチコア」から「メニーコアへ」

60

現実味を帯びてきた「メニーコア」（ Intel 80cores）

Frequency

Voltage Power Aggregate Bandwidth

Performance

3.16 GHz 0.95 V 62W 1.62 Terabits/s

1.01 Teraflops


1.63 Teraflops


1.81 Teraflops

http://www.intel.com/research/platform/terascale/teraflops.htm?iid=newstab+supercomputing

オンチップ・スーパーコンピューティング@2017

チップ内コア数：×[email protected]年（ムーアの法則） 2017年には 512コア（ ?）

1 10 100 1,000 10,000 100,00010

100

1,000

10,000

100,000

1,000,000

10,000,000

Total Number of Processor Chips

Perfo

rman

ce (G

flop/

s)

Top 500 Supercomputers

Blue-Gene/L

Earth Simulator

Cell (9cores)ClearSpeed (96cores)Power6, Xeon (2cores)

Intel Test (80cores)

Tsubame

Single-Chip

source: http://www.top500.org/

Multi-Core Processors

ディペンダビリティの重要性同一チップ上に「数百のコア」を集積→

故障対策は ? 検証は ? 同一チップ上で「複数ユーザ」が「複数アプリ」を実行→安全性は ?

同一チップ上で「数百のスレッド」を同時に実行→発熱に伴う信頼性の低下は ?

などなど

宣伝その１システム LSI ワークショップ’07

システム LSIの新時代：未来を拓くヒトと技術 2007年 11 月 19 日～ 21 日北九州国際会議場

ポスター（ 73 件の研究を一度にみれます！）学生部門 44 件（学生による発表）一般部門 9 件（企業や研究所による発表）デザインガイア 20 件

宣伝その 2Cell Speed Challenge’07

マルチコア・プログラミングコンテスト主催：情報処理学会 ARC/EMB/HPC 先進的計算基盤システムシンポジウム

SACSIS2008との併設企画超豪華賞品

PS3, HD DVDプレーヤー , 液晶テレビ (47 型 )など

スケジュール 11 月初旬に参加申し込み開始予定（規定課題

/自由課題）

Back-Up Slides

メモリデータの改竄を検出する !

メモリ整合性検証の高速化

メモリ・データの保護

CPUcore L1$

L2$

Security boundary（前提：オンチップはセキュア）

Memory

盗み見

改竄

Private Tamper Resistant→ オフチップ・データの暗号化

Tamper Resistant→インテグリティ検証

Integrity VerificationEncryption

M(t1) ＝ M(t2)：メモリ整合性が保たれている⇒改ざんされていない

M(t1)≠M(t2) 改ざん発生！

M(t1)

t1t

t2

Processor

memory M(t2)

Processor

memory書き込み読み込み

書き込みが発生しない

M(t0)

Processor

memory

t0

データ改ざんの発生

メモリ整合性検証

ハッシュ木によりメモリ・イメージのダイジェストを保存する！

データ読出し時メモリ整合性検証の実行 rootまでハッシュ値を比較一致していれば OK

データ書込み時ハッシュ木を更新 rootまでのハッシュ値を更新書込み前にMIVを実行

ハッシュ値のキャッシングにより性能オーバヘッドを削減

Memory Space (insecure)

v1 v2 v3

h1 h2

v4

h1=h(V1)h5

rooth5=h(h1, h2)

root=h(h5, h6)

h3 h4

h6

h6=h(h3, h4)

h1 h2 h3 h4 h5 h6

On-Chip Storage(Trusted)

メモリ整合性検証によりプロセッサ性能が低下する！理由：プログラム実行処理とメモリ整合性検

証処理が様々な「資源」を共有する！具体的には・・

オンチップ・キャッシュ（⇒ミス率の増加）オフチップ・メモリバス（⇒メモリバンド幅の浪

費）

CPU Mem.

プロセッサコアキャッシュ

整合性検証

ハッシュ値

プロセッサが参照するデータ

プロセッサが参照するデータ

キャッシュの衰退ラインを利用した性能オーバヘッドの抑制キャッシュの衰退ラインを活用

衰退ライン⇒プロセッサから参照されない（使用済みの）データを保持しているデータブロック

衰退ライン（使用済みライン）にハッシュ値を格納

ハッシュ値のキャッシング時，プログラム実行に必要なデータを追い出さないようにする

CPU Mem.

プロセッサコアキャッシュ

整合性検証

衰退ライン

ハッシュ値プロセッサが参照するデータ

衰退ライン（使用済みライン）はどの程度存在するのか？

177.mesa

167.gzip 255.vortex

キャッシュ中に格納すべきハッシュ値の割合 (%)

73.2 34.7 56.2

キャッシュ中に存在する衰退ラインの割合 (%)

99.1 98.3 98.4

L2キャッシュサイズ： 128KB

60%

255.vortex

性能オーバヘッド削減率

Benchmark Programs

Over

head

Red

uctio

n (%

)

今後の展開

CPUCPUCPU

Mem

CPUCPUCPUCPUCPUCPU

ASIC

ASIC

LSI communityMem

CPU

A B C D

CPUCPU

A B C D

TrustedPrograms

Virus

上位階層

共同体としての処理お互いの監視自己状態の伝達お互いに修復（助け合い）

悪影響を上位階層へ伝播させない仕組み

安全性と消費エネルギーのトレードオフ

EV Product E2V Product EV2 Product

3.5%

255.v

ortex

175.v

pr

181.m

cf

197.p

arser

179.a

rt

255.v

ortex

175.v

pr

181.m

cf

197.p

arser

179.a

rt

255.v

ortex

175.v

pr

181.m

cf

197.p

arser

179.a

rt

LRU2 MRU1 MRU2 ALL

VulnerabilityVu

lner

abilit

y

Benchmark Programs

LRU1-L&ILRU1-L&UMRU1-L&U

(Nv-rald / Nrald) * 100 Total #of issued

RA loadInsecure issued

RA load

Performance OverheadPe

rform

ance

Ove

rhea

d

Benchmark Programs

LRU1-L&ILRU1-L&UMRU1-L&U

衰退ライン（使用済みライン）はどの程度存在するのか？

0

20

40

60

80

100

mesa gcc vortex bzipベンチマーク・プログラム

CPU/

総キャッシュラインに対して

%ハッシュデータが占める割合（）

8K 16K 32K 64K chash

衰退ラインが閉める割合 (%)ハッシュデータが閉める割合 (%)

安全性に関する考察

不正プログラム実行可能性秘密鍵情報の漏洩→安全な秘密鍵管理不正プログラム実行命令数＜鍵命令実行間隔→短い間隔

鍵情報の推測容易性外部からの実行振舞い観測→プロファイラのオンチップ化

不正プログラム伝播容易性同一秘密鍵→ユーザ /プログラム毎で異なる実行の振舞いを実現可能

プロセッサ性能オーバヘッドの削減

4-way OOO Superscalar Processor128KB 4-way set-associative UL2 Cacheキャッシュミスによる影響のみ考慮 Per

form

ance

Ove

rhea

d (%

)

UL2

Cac

he M

iss

Rat

e (%

)

Benchmark program

Benchmark program

ConventionalProposed

ConventionalProposed

性能オーバヘッドPe

rform

ance

Ove

rhea

d (%

)

Benchmark Programs

Conventional Proposed

2-way In-Order Superscalar

4-way Out-Of-Order Superscalar

Fetch/Issue/Commit Width

2 4

Branch Prediction Bimodal (128-enrty), 1-way BTB(128-entry),

RAS(4-entry)

Gshare(4K-entry),4-way BTB (512-set),

RAS(8-entry)RUU 8 32LSQ 8 16L1 D-Cache 4-way 16KB, 32B lines 4-way 16KB, 32B linesL1 I-Cache 2-way 16KB, 64B lines 2-way 32KB, 64B linesL2 Cache none 4-way 512KB, 64B linesMemory Latency 64 cycles 64 cyclesFunction UnitiALU/iMUL/fALU/fMUL

1/1/1/1 4/2/4/2

Table 1: Processor Configurations

Architectural Support for

ＯＯＯ実行

命令パイプラインスーパスカ

ラ

ＩＬＰＴＬＰ

分岐予測

アドレス予測

値予測

キャッシュ

プリフェッチ

パイプライン統合

ＤＶＳ

クロック・ゲーティング

シグナル・ゲーティング

リサイジング選択的活性化

スラック予測

CTV BPRF

本講演でのトピック

情報社会を支える ディペンダブル・プロセッサ

Documents

情報社会を支えるディペンダブル・プロセッサ