Mondriaan Memory Protectionの調査

調べた人 : 前田俊行

一言でいうと• ハードウェアのメモリ保護を

ワード単位にします

– 理由 :細粒度メモリ保護が欲しい→ でも今のメモリ保護はページ単位で使えない→ じゃあワード単位にしよう

参考文献• E. Witchel, J. Cates and K. Asanovic

“Mondrian Memory Protection”In proc. of ASPLOS 2002.

• E. Witchel and K. Asanovic“Hardware Works, Software Doesn’t: Enforcing Modularity with Mondriaan Memory Protection”In proc. of HotOS 2003.

• E. Witchel, J. Rhee and K. Asanovic“Mondrix: Memory Isolation for Linux using Mondriaan Memory Protection”In proc. of SOSP 2005.

細粒度メモリ保護とは• 1 つのアドレス空間内で

複数のメモリ保護ドメインを持つこと• たいてい 1 スレッドに 1 保護ドメインを割り当てる

なぜ “ Mondriaan” か

• Piet Mondriaan (1872-1944)

Composition with Red, Yellow and Blue (1921)

どうやって実現するか ?

• “Permissions Table” を導入する– Permissions Table

• マッピング情報のないページテーブルのようなもの

• ワード単位でメモリ保護を指定できる• ( 実装方式については後述 )

• 元々の ISA は変わらない– Permissions Table を「付け加える」だけ

MMP (Mondriaan Memory Protection)System 概略図

Sidecar: 保護情報キャッシュ その 1

メモリアクセスに使えるレジスタそれぞれに用意

メモリアクセス時に使った保護情報をキャッシュする

PLB: 保護情報キャッシュ その 2

Protection Lookaside Buffer:TLB のようなもの ( タグ付 )

PLB のタグ

Permissions Table

ページテーブルのようなもの

ここで重要な問題• Permissions Table をどう実装する ?

– この論文が示す方法は 3 つ• SST: Sorted Segment Table• MLPT: Multi-level Permissions Table• MLPT + SST

SST: Sorted Segment Table

• 保護範囲 (= セグメント ) ごとに保護を指定する

Perm の値の意味

0x00000000

0x00100020SST で表すと…

メモリイメージ

SST の利点• Table のサイズが小さくなる (?)

– Table のサイズ = セグメントの数

メモリイメージ

00000000 000100110011000100100010000100

SST

SST で表すと…

SST の欠点• Table の検索がバイナリサーチ (= O(log n))• Table の更新が重い

メモリイメージ

00000000 000100110011000100100010000100

SST

ここに新たなセグメントを追加するには ?

1. まず、該当する

エントリを探す( バイナリサー

チ )

2. 新たなエントリを追加する

1000

これらのエントリをずらさなければならない

MLPT: Multi-level Protection Table

• アドレスごとに保護を指定する

アドレス分解

Table のエントリサイズ = 32 bit

Perm Table Base

1 エントリで指定できる保護 = (32 / 2) 個 = 16 個指定できる保護単位 = (64 / 16) バイト = 4 バイト = 1 ワード

MLPT エントリ

MLPT の利点• Table 検索が速い (= O(1))

– 最悪でも 3 回のメモリアクセスでエントリが必ず得られる

Perm Table Base

MLPT の欠点• 無駄な table 検索が増える

メモリイメージ

SST の場合

MLPT の場合

0x01000

0x08000

こことここにアクセスすると…

検索回数 : 2 回 ( 同じセグメントに 2 回アクセスしたことがわからない )

検索回数 : 1 回 ( 最初のアクセス結果が PLB にキャッシュされる )

SST と MLPT の比較• SST

– サイズが小さい (?)

– 検索回数が少ない

– 検索が遅い( バイナリサーチ )

– 更新が重い

• MLPT– 無駄なエントリが多い

– 検索回数が多い

– 検索が速い(O(1))

– 更新が軽い

MLPT + SST( 例によって ) おいしいとこどりを目指す

• SST– サイズが小さい (?)

– 検索回数が少ない

– 検索が遅い( バイナリサーチ )

– 更新が重い

• MLPT– 無駄なエントリが多い

– 検索回数が多い

– 検索が速い(O(1))

– 更新が軽い

MLPT + SST

• MLPT のエントリに SST を取れるようにするmini-SST エントリ

Perm Table Base

MLPT with mini-SST の利点• 検索回数が減る

– エントリがアドレス範囲外のセグメントの情報も持てるため

• (PLB にキャッシュされやすくなる )

mini-SST エントリ

MLPT with mini-SST の欠点• Table の更新が複雑

– 1 つのセグメントの情報が複数エントリに存在するため

mini-SST エントリ

ここに新たにセグメン

トを作るには ?

性能評価実験• MMP によるオーバヘッドを評価した

– ベンチマークプログラムの実行オーバヘッドを測定した– 2 種類の実験 :

• 従来の保護を MMP で再現したときのオーバヘッド測定» Read-only text, read-only data, read-write data and stacks

• 細粒度保護を MMP で実現したときのオーバヘッド測定» malloc で確保したメモリごとにセグメントを作る

( 正確には確保したメモリの周りにもう 2 つ無効セグメントを作る )

– ハードウェアがないのでシミュレータ上で実験した• MIPS アーキテクチャ上に実現

ベンチマークの種類

Refs : メモリアクセス回数 (load & store)Segments : 作られるセグメント数 ( = malloc 回数 ×2)Refs/Update: メモリアクセス回数 / Table 更新の回数Cs : 従来の保護で実行したときのセグメント数

従来の保護を MMP で再現したときのオーバヘッド

X-ref : Table へのアクセス回数 / プログラムのメモリアクセス回数Space : Table のサイズ / プログラム終了時の有効メモリ領域のサイズl/k : Table 検索時のメモリアクセス回数 / Table 検索回数

細粒度保護を MMP で実現したときのオーバヘッド

SST vs. MLTP with mini-SST

Space : Table のサイズ / プログラム終了時の有効メモリ領域のサイズX-ref : Table へのアクセス回数 / プログラムのメモリアクセス回数upd : Table 更新時のメモリアクセス回数 / Table 検索 & 更新時のメモリアクセス回数ld/lk : Table 検索時のメモリアクセス回数 / Table 検索回数

細粒度保護を MMP で実現したときのオーバヘッド

MLPT vs. MLPT with mini-SST

Space : Table のサイズ / プログラム終了時の有効メモリ領域のサイズX-ref : Table へのアクセス回数 / プログラムのメモリアクセス回数upd : Table 更新時のメモリアクセス回数 / Table 検索 & 更新時のメモリアクセス回数ld/lk : Table 検索時のメモリアクセス回数 / Table 検索回数

その他• MMP を使って Linux を改造した (Mond

rix)– Linux のバグを 1 つ見つけた

• ( これは x86 シミュレータで , SOSP 2005)

まとめ• Mondriaan Memory Protection は

ワード単位で保護を指定できるハードウェアメモリ保護機構です