Changeset 209 in lab

Timestamp:

Apr 13, 2013 4:25:25 PM (11 years ago)

Author:

mitty

Message:

• memo for 8th Kernel/VM expedition
• add about qemu/kvm/vt-x

File:

• trunk/Commentary/kernelvm/20130413.log (modified) (1 diff)

trunk/Commentary/kernelvm/20130413.log

@@ -362 +362 @@
             SSDのような小さなデバイス上に実装されているマイコンで行われるのを待ってCPUが
             ブロッキングされるより、CPUで行った方が結果として早かったりする
+
+@ntddk
+がんばれEMET
+    ntddk 由来はWindowsでドライバを書く際にincludeするヘッダから
+    
+    EMETとは
+        Windows上で脆弱性を突く攻撃を防ぐツール
+    VS2003
+        /GSオプションの導入
+        security cookieの検証
+            上書きされていないか
+    SEH Overwriting
+    SafeSEH
+        ビルド時に、正規の例外ハンドラの一覧を作りそれ以外は実行出来ないようにする
+        サードパーティのDLLなどは行われていないことが多い
+    SEHOP
+        VistaSP1～
+    HardwareDEP
+        NX/XD bit
+        実行不可能フラグ
+        処理を乗っ取ったが実行は出来ない
+        VirtualAllocによりメモリ属性を変更される
+        DEPを無効化するAPIなど
+    Return-orientied Programming
+    JITコンパイラによって、実行中に悪意のあるコードを生成
+    ASLR
+        アドレス空間のランダム化
+        HeapSprayによる攻撃
+        とりあえずHeapを埋めてしまう
+    いたちごっこの様相を示している
+        そこでEMET
+        XPの様な骨董品でも、脆弱性防御機能が有効になっていないバイナリでも防げる
+    EMETでも防げない攻撃もある
+    EMETを導入しないと当然使えないので、ビルド時にEMETの機能が付加されて欲しい
+    オレオレEMETの実装
+        shimというフレームワーク
+        Windowsの後方互換性を保つための仕組み
+        Windows版Wineの様なイメージ
+        EMET.dllにはGetHookAPIs, NotifyShimsというAPIがエクスポートされている
+            DLLインジェクションとは異なる
+        ダメだったよ
+    Shimに頼らずにオレオレEMET
+        一般的な方法でDLLインジェクション
+    オレオレDEP
+        実装は簡単
+        Win32APIでGetProcessDEPPolicyで無理矢理有効に出来る
+    オレオレEAF
+        EMET独自の実装
+        悪意のあるコードはfs:[30h]を読み取り、Win32APIのアドレスを得ようとする
+        Export Address Tableへのアクセスをフィルタ
+        ハードウェアブレークポイント
+    きみだけの最強EMETを作ろう
+    カーネルにはパッチを防ぐ機構がx64には別に存在している
+
+林佳寛
+QEMUとkvmとvt-x
+    QEMUとは…、kvmとは…、vt-xとは…
+        英語でよく分からない！
+        qemu-kvmはホストOSから見ると、一つのプロセスである
+        ゲストOSはCPUをベアマシンと変わらず使う
+        センシティブ命令に関しては、vt-xとホストOSが頑張るので、ゲストOSを改造する必要がない
+        qemu-kvmはカーネルのkvmもデューるを用いてvt-xを使う
+    目的
+        qemu, kvm, vt-xでどのように処理が流れているか知る
+        Fedora 15 x86_64 2.6.42
+        virtio-blkに何かをwriteした時にどのようなことが起きるのか
+    1. システムコール
+        ゲストOS上で、プロセスがファイルを開いて書き込む
+    2. センシティブ命令
+        ファイルシステムを通じて、BlockI/O
+        ブロックデバイスはvirtio-blk
+        virtioはゲストとホスト間でデータを共有するためのqueueに要求を入れる
+        virtqueue_kick
+        vp_notify
+        io_write16
+        -> PORT/IO
+        
+        vt-x
+            センシティブ命令をトラップするための仕組みがvt-x
+            VMExitし、kvmへ処理を移す
+        センシティブ命令
+            ゲストOSが発行したPORT/IOをホストOSでそのまま実行してしまうと、そのアドレスは
+            ホストでは違うデバイス、あるいは何もないかもしれない
+            -> VMExitしてエミュレーションする
+    3. VMExit
+        センシティブ命令を契機として、VMEnterした命令の次に処理が戻ってくる
+        vmx_vpcu_run
+            vmx_handle_exitに戻ってくる
+            VMExitの要因になったハンドラを呼び出す
+                どういう理由でExitしたかを格納した構造体がホストOSに渡される
+        今回は EXIT_REASON_IO_INSTRUCTION -> handle_io
+        handle_io
+            引数に指定されたポート版を処理するための関数が設定されているかを確認する
+            が、virtio-blk用の関数は設定されていない
+            関数が設定されていて、処理がうまくいけば1、そうでなければ0
+            -> 今回は0
+        __vpu_runには返値0で戻ってくる
+        __vpu_runからも0でreturnする -> kvm_arch_vcpu_ioctl_run
+        kvm_arch_vcpu_ioctl_run: /dev/kvmへのioctlを処理する
+    4. ioctlのreturn
+            /dev/kvmに対するioctlがreturnした、ということになる
+        qemu-kvmはioctlがreturnしてきた理由を確認する
+        kvm_handle_io
+            ポート番号からデバイスを検索
+            今回はvirtio-blkのデバイスが見つかる
+            デバイス毎にエミュレーション
+        qemu-kvm自体は普通のプロセスなので、ライブラリ関数を呼び出す -> 最終的にはホストOSのシステムコールへ
+    
+    8. VMEnter
+        ioctlされたkvmはVM Enterする
+    9. センシティブ命令のエミュレーション完了
+        ようやく2. のIOが終わったことになる
+    つまり…
+        qemu-kvm
+            vt-x/kvmの力を借りて、なるべくエミュレーションしないように改造されたQEMU
+        kvm
+            カーネルモジュール
+    最近の仮想化潮流
+        qemu-kvmの仕事を減らす方向
+        メモリのコピーやringの切替にCPUをたくさん使う
+            VMX NON-ROOT/VMX ROOTを超えるペナルティが大きい
+        ハードウェアやkvmで処理を行ってコンテキストスイッチを減らしたい
+        vt-d, vhost, 割り込み仮想化、など
+