プロフィール

大山恵弘

  • Author:大山恵弘
  • 公式なサイトはこちら

最近の記事

最近のコメント

最近のトラックバック

月別アーカイブ

ブロとも申請フォーム

ブログ内検索

RSSフィード

リンク

FC2カウンター

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

【セキュリティ】 Safe Java Native Interface 【プログラミング言語】

In IEEE ISSSE 2006.
http://www.cs.princeton.edu/~appel/papers/

SafeJNIの提案。アッペルさんの最近の研究。

JNIを使ったときにJavaの型安全性をバイパスできるような抜け道をidentifyした。

・Javaの世界からもらったリファレンスはJNI APIを使って操作されることを期待されている。しかしそれにしたがわず、リファレンスをいじったりたどったりすれば、想定外の領域をアクセスできる。
・JNI API関数の関数テーブルを上書きされてしまう。
・Cのコードは、Javaの世界からもらった配列の添字を超えてアクセスできる。
・Cのコードはヒープのどこでも読めるので、privateみたいなアクセス制御機構が効かない。
・JNIではmalloc/freeのような感じで明示的にメモリ管理をするので、ダングリングポインタ、多重フリー、メモリリークなどのバグが入る。
・JavaからCに来る時点で、どんなオブジェクトも単一の型に変換されるので、Javaの世界とCの世界で型が合わないことがある。
・Cの世界からJavaの世界のオブジェクトをアクセスするときには、型を意識して適切な関数を呼び出さなければならない。
・Cの関数からJavaの関数を呼び出せる。呼び出しから返った後には例外の検査などが必要。それをしないと予期しない結果になる。
・Cの世界にはJavaのセキュリティマネージャの制御が及ばない。

解決。

・CCuredをJavaハンドルポインタと読み出しオンリーポインタで拡張(?)した型システム。JNIに関連するinvariantを静的に強制。リファレンスをいじられて変なとこ触られたり、関数テーブルを上書きされることを防ぐ。

Javaハンドルポインタは、読むことも書くこともできない(JNI APIに渡される)ポインタ。

読み出しオンリーポインタは、そのポインタが指す領域に書き込みできないポインタ。Cで言う、ポインタのconstみたいなもの。

・動的検査の挿入。配列境界、アクセス制御、例外などの検査。

・安全なメモリ管理。メモリ領域に有効タグをつける。確保したらセット。フリーしたらクリア。タグがクリアされてる領域をフリーしようとしたら二重フリーと判断。

あまり奇をてらわず、スタンダードな感じ。
スポンサーサイト

【エミュレータ】 Dynamic Binary Translation and Optimization in a Whole-System Emulator -- SkyEye 【動的コード生成】

In ICPPW '06

システム全体エミュレータSkyEyeの話。命令列を動的に変換しながら実行する。ゲストアーキテクチャの命令列を、Translated Block (TB) というコードブロックに変換する。QEMUのようなシステムと思えばいい?

ARMやMIPSのエミュレータ、LCDやフラッシュのデバイスエミュレータも含む。

ゲストマシンの消費電力計算もしてくれるようだ。

性能は、QEMUに勝ったり負けたり。

仮想デバイスやらMMU仮想化やらの話に一番興味があるのだが、その手の話にはあまりふれられていない。

TBを検索する新規な戦略によって、短時間で適切なTBを見つけられるようになっている(そして実験でARMの高速エミュレーションを確認している)ってのが一番の売りのように読める。この手のシステムではTBの管理って重要なのかな。

仮想マシンモニタ系のVM論文てよりはJava系のVM論文といった印象。

【プロファイル】 Framework for Instruction-level Tracing and Analysis of Program Executions 【instrumentation】

In VEE 2006.
http://www.veeconference.org/vee06/

ユーザプログラムの完全トレースの記録と決定的再実行(シミュレーション)を可能にするシステム。命令レベルでトレース/再実行/解析ができる。

タイムトラベルデバッガでデバッグできるツールあり。データ局所性解析ツールあり。

バイナリ変換とインタープリテーションを組み合わせて実装。再実行に必要な情報を集めるためのcallbackをアプリケーションに挿入する。決定的再実行に影響を与える外部との相互作用は、記録しておく(時刻取得命令の返り値とか)。

オーバヘッドは微妙(平均トレースオーバヘッドは11倍!再実行オーバヘッドはさらにその3、4倍!)。トレースのサイズは、新方式によってかなり圧縮されている(1命令あたりのビット数が0.5くらい)。

自己改変コードにも対応。マルチスレッド、マルチプロセッサにも対応。キャラメルだけでも十分なのに、おまけ2個ついてますみたいな。この実装の馬力はすごい。

トレースの圧縮と聞くとまず私はWPPが浮かぶんですが、WPPとこの研究てどんな関係にあるんでしょうね(bibには挙げられているが、関連研究の章では比較されてないみたい)。もちろん、再実行するとかバイナリ変換するとかの点で、差分ありまくりなわけですけど、純粋に圧縮手法の部分だけを比較したらどうなのかなって思って。

あとやっぱQEMUとかbochsとの関係も気になるなあ。

【セキュリティ】 Separation of Concerns for Security 【アスペクト指向】

In ICSE 2000.
http://www.cs.virginia.edu/~evans/pubs.html

アスペクト指向でセキュリティ処理のコードを挿入して安全性を高めましょうという話。ビッグネーム揃い踏みの論文。ていうかポジションペーパ。

セキュリティ処理のコードは関心事分離するのがいいのか、ソースに埋め込むほうがいいのかは、まだはっきりしない問題だし、そもそも時と場合によるので一概に言えなかったりする。アスペクトの素人の個人的意見としては、セキュリティ処理は本処理と一緒に書かれていてほしいと思います。開発段階から分離して書くのはなんか肩がこりそうだし危なそうだなと。既存のコードをいじりたくない場合にアスペクト指向でセキュリティコードを突っ込んで急場をしのぐって用途はありなんじゃないかと思います。

2000年の論文なので、今読むと牧歌的な雰囲気が漂っている。セキュリティを研究してると、もうやること残ってないんじゃないかと思うことがある。でも、2000年から2006年の間に、技術は確実に進歩した。技術の進歩に終わりなし。今後の6年にも、セキュリティ技術は進歩するはず。

【IA-32】 IA-32 Execution Layer: a two phase dynamic translator designed to support IA-32 applications on Itanium-based systems 【バイナリ変換】

In MICRO-36 2003.

IA-32の命令列をItaniumの命令列に動的に変換することにより、IA-32アプリケーションをItanium上で実行することを可能にするソフトウェア層IA-32 ELの話。

IA-32 ELはWindows上でもLinux上でも動く。ユーザレベルのみで動く。ハードウェア支援不要。

二段階JITコンパイル。第一段階は最小限の最適化の単純なバイナリ変換を行い、hotspotを知るためのinstrumentationを埋め込む。第二段階はinstrumentationで得た情報にもとづいて、最適化を効かせてhotspotをバイナリ変換。

IA-32 EL自体はOS独立バイナリ。OS独立部分とOS依存部分をきれいに切り分けて作られているのがポイント。

正確な例外処理などのフィーチャーもあり。

90年代末のJavaの論文を読んでいるような、青春がよみがえってくるような、デジャブ感満載の論文。

Rosettaが出てきたりして、この分野もコンスタントに注目は集めている。
あるアーキテクチャ上で別のアーキテクチャをエミュレーションによって動かしたときの性能は現実的なのか非現実的なのか。3年後、5年後はどうか。

PCの性能もコアの個数もCPUエミュレータの賢さもグングン上昇するとして、こういうシステムの将来は果たしてどうなるのか、今ぼわっと考えています。

【フック】 Detours: Binary Interception of Win32 Functions 【Windows】

In 3rd USENIX Windows NT Symposium.
http://research.microsoft.com/sn/detours/

Win32の関数にinterception codeを入れるためのライブラリ。
ユーザはアプリケーションコードの中でdetoursライブラリ関数を呼ぶ。その関数の引数には、interceptされるWin32の関数名と、interception codeを提供する関数名を与える。その関数は、メモリ上に存在する、interceptされる関数の先頭の命令列を、interception codeを提供する関数へのジャンプ命令列に書き換える。

Windows上で関数をinterceptする方式について述べている数少ない論文の一つ。

ついついセキュリティへの応用を考えたくなるが、Detoursはセキュリティ用途には使いにくいように思う。資源を操作する重要な関数の呼び出しに検査を挟んで、資源を不正に操作されないようにするなんて処理は、Detoursではうまく実現できない。たとえば、バッファオーバフローによって注入されたコードは、直接System Serviceを呼び出すことによって、悪意の操作を実行できる。注入コードをここに述べられてるような凝ったものにすれば、注入コードはinterceptionをバイパスしてオリジナルの関数に直接飛ぶことができる。

セキュリティ用途に使うなら、System Serviceの直接呼び出し対策やバイパス対策が必須。
もしくは、Detours方式は捨てて、System Serviceフック方式を採用してしまうのが、筋が良いように思われる。

【ソフトウェア工学】 Highly Reliable Upgrading of Components 【プログラミング言語】

In ICSE '99.
http://www.cs.nmsu.edu/~jcook/papers/

コンポーネントをアップグレードしても信頼性を失わせないための技法。

コンポーネントをアップグレードしても古いコンポーネントは消さない。そのコンポーネントが呼び出されたら、新しいコンポーネントも、過去のコンポーネント群も実行。プロキシみたいなプログラム(Arbeiter)がコンポーネント群のインタフェースをメインプログラムへ提供する役を果たす。メインプログラムは一つの普通のコンポーネントだと思って呼び出す。Arbeiterが複数モジュールから結果を受け取ったら、一つを選んで返す。各バージョンがどんな結果を返したかを解析。

どういうコンポーネントが信頼できるかについての仕様を、制約?で指示。特定の呼び出しに対して、どのバージョンが正しい結果を返すかを求める。各バージョンが正しい結果を返す回数を数え、どんな呼び出しについてはどのバージョンが信頼できるかを判断。最も信頼できるコンポーネントによる実行結果を返すとか、危ないコンポーネントは実行しないなどの制御ができる。

【異常検知】 Artemis: Practical Runtime Monitoring of Applications for Errors 【instrument】

Purdue University TR-ECE 05-02
https://engineering.purdue.edu/ECE/Research/TR/2005.whtml

異常検知などのためにプログラム監視用に挿入されたinstrumentのオーバヘッドを削減するための枠組みの提案。シングルスレッドCプログラム用。

各手続きについて、instrumentを入れたバージョンと、instrumentを入れないバージョンの2つを用意。異常をできるだけ見逃さないようにしながら、できるだけinstrumentを入れないバージョンを実行したいってのが動機。

方法。まずプログラムを訓練モードで実行して、各関数が呼び出されるときの実行コンテキストについてのinvariantを作る。後にプロダクションモードで実行。実行コンテキストは、すべてのスコープ内変数、手続きのパラメタ、それらから辿れるデータすべてによって表現。

関数を呼び出した際には、呼び出し時の実行コンテキストが、訓練モードで作られたinvariantを満たしているかどうか検査。満たしている場合には、その関数の実行には、instrumentを入れてないコードを使う。満たしていない場合には、instrumentを入れたコードを使う。

背後にある観察は、関数呼び出し時の実行コンテキストが同じで、かつ、シングルスレッドならば、その関数は決定的に、訓練モードと同じように実行される可能性が高い、というもの。

筑波大時代にDIDUCEの論文読んでショック受けました。で、これはDIDUCEに引き続く研究。DIDUCE的手法の適用先として、instrumentのオーバヘッド削減ていう目新しいものをもってきたってところが、この研究のポイントか。つい、この手の研究では、異常検知の精度を上げるだのオーバヘッドを減らすだのって方向に行ってしまいがち。別の方向を向いて、Artemisは異常検知のための技法ではない、って位置づけてるあたりのやり方がうまいかも。

過去の挙動の学習に基づく異常検知についての論文は、このへんとかこのへんにもあります。

| ホーム |


 BLOG TOP 


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。