Changeset 209 in lab


Ignore:
Timestamp:
Apr 13, 2013 4:25:25 PM (12 years ago)
Author:
mitty
Message:
  • memo for 8th Kernel/VM expedition
  • add about qemu/kvm/vt-x
File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/Commentary/kernelvm/20130413.log

    r208 r209  
    362362            SSDのような小さなデバイス上に実装されているマイコンで行われるのを待ってCPUが 
    363363            ブロッキングされるより、CPUで行った方が結果として早かったりする 
     364 
     365@ntddk 
     366がんばれEMET 
     367    ntddk 由来はWindowsでドライバを書く際にincludeするヘッダから 
     368     
     369    EMETとは 
     370        Windows上で脆弱性を突く攻撃を防ぐツール 
     371    VS2003 
     372        /GSオプションの導入 
     373        security cookieの検証 
     374            上書きされていないか 
     375    SEH Overwriting 
     376    SafeSEH 
     377        ビルド時に、正規の例外ハンドラの一覧を作りそれ以外は実行出来ないようにする 
     378        サードパーティのDLLなどは行われていないことが多い 
     379    SEHOP 
     380        VistaSP1~ 
     381    HardwareDEP 
     382        NX/XD bit 
     383        実行不可能フラグ 
     384        処理を乗っ取ったが実行は出来ない 
     385        VirtualAllocによりメモリ属性を変更される 
     386        DEPを無効化するAPIなど 
     387    Return-orientied Programming 
     388    JITコンパイラによって、実行中に悪意のあるコードを生成 
     389    ASLR 
     390        アドレス空間のランダム化 
     391        HeapSprayによる攻撃 
     392        とりあえずHeapを埋めてしまう 
     393    いたちごっこの様相を示している 
     394        そこでEMET 
     395        XPの様な骨董品でも、脆弱性防御機能が有効になっていないバイナリでも防げる 
     396    EMETでも防げない攻撃もある 
     397    EMETを導入しないと当然使えないので、ビルド時にEMETの機能が付加されて欲しい 
     398    オレオレEMETの実装 
     399        shimというフレームワーク 
     400        Windowsの後方互換性を保つための仕組み 
     401        Windows版Wineの様なイメージ 
     402        EMET.dllにはGetHookAPIs, NotifyShimsというAPIがエクスポートされている 
     403            DLLインジェクションとは異なる 
     404        ダメだったよ 
     405    Shimに頼らずにオレオレEMET 
     406        一般的な方法でDLLインジェクション 
     407    オレオレDEP 
     408        実装は簡単 
     409        Win32APIでGetProcessDEPPolicyで無理矢理有効に出来る 
     410    オレオレEAF 
     411        EMET独自の実装 
     412        悪意のあるコードはfs:[30h]を読み取り、Win32APIのアドレスを得ようとする 
     413        Export Address Tableへのアクセスをフィルタ 
     414        ハードウェアブレークポイント 
     415    きみだけの最強EMETを作ろう 
     416    カーネルにはパッチを防ぐ機構がx64には別に存在している 
     417 
     418林佳寛 
     419QEMUとkvmとvt-x 
     420    QEMUとは…、kvmとは…、vt-xとは… 
     421        英語でよく分からない! 
     422        qemu-kvmはホストOSから見ると、一つのプロセスである 
     423        ゲストOSはCPUをベアマシンと変わらず使う 
     424        センシティブ命令に関しては、vt-xとホストOSが頑張るので、ゲストOSを改造する必要がない 
     425        qemu-kvmはカーネルのkvmもデューるを用いてvt-xを使う 
     426    目的 
     427        qemu, kvm, vt-xでどのように処理が流れているか知る 
     428        Fedora 15 x86_64 2.6.42 
     429        virtio-blkに何かをwriteした時にどのようなことが起きるのか 
     430    1. システムコール 
     431        ゲストOS上で、プロセスがファイルを開いて書き込む 
     432    2. センシティブ命令 
     433        ファイルシステムを通じて、BlockI/O 
     434        ブロックデバイスはvirtio-blk 
     435        virtioはゲストとホスト間でデータを共有するためのqueueに要求を入れる 
     436        virtqueue_kick 
     437        vp_notify 
     438        io_write16 
     439        -> PORT/IO 
     440         
     441        vt-x 
     442            センシティブ命令をトラップするための仕組みがvt-x 
     443            VMExitし、kvmへ処理を移す 
     444        センシティブ命令 
     445            ゲストOSが発行したPORT/IOをホストOSでそのまま実行してしまうと、そのアドレスは 
     446            ホストでは違うデバイス、あるいは何もないかもしれない 
     447            -> VMExitしてエミュレーションする 
     448    3. VMExit 
     449        センシティブ命令を契機として、VMEnterした命令の次に処理が戻ってくる 
     450        vmx_vpcu_run 
     451            vmx_handle_exitに戻ってくる 
     452            VMExitの要因になったハンドラを呼び出す 
     453                どういう理由でExitしたかを格納した構造体がホストOSに渡される 
     454        今回は EXIT_REASON_IO_INSTRUCTION -> handle_io 
     455        handle_io 
     456            引数に指定されたポート版を処理するための関数が設定されているかを確認する 
     457            が、virtio-blk用の関数は設定されていない 
     458            関数が設定されていて、処理がうまくいけば1、そうでなければ0 
     459            -> 今回は0 
     460        __vpu_runには返値0で戻ってくる 
     461        __vpu_runからも0でreturnする -> kvm_arch_vcpu_ioctl_run 
     462        kvm_arch_vcpu_ioctl_run: /dev/kvmへのioctlを処理する 
     463    4. ioctlのreturn 
     464            /dev/kvmに対するioctlがreturnした、ということになる 
     465        qemu-kvmはioctlがreturnしてきた理由を確認する 
     466        kvm_handle_io 
     467            ポート番号からデバイスを検索 
     468            今回はvirtio-blkのデバイスが見つかる 
     469            デバイス毎にエミュレーション 
     470        qemu-kvm自体は普通のプロセスなので、ライブラリ関数を呼び出す -> 最終的にはホストOSのシステムコールへ 
     471     
     472    8. VMEnter 
     473        ioctlされたkvmはVM Enterする 
     474    9. センシティブ命令のエミュレーション完了 
     475        ようやく2. のIOが終わったことになる 
     476    つまり… 
     477        qemu-kvm 
     478            vt-x/kvmの力を借りて、なるべくエミュレーションしないように改造されたQEMU 
     479        kvm 
     480            カーネルモジュール 
     481    最近の仮想化潮流 
     482        qemu-kvmの仕事を減らす方向 
     483        メモリのコピーやringの切替にCPUをたくさん使う 
     484            VMX NON-ROOT/VMX ROOTを超えるペナルティが大きい 
     485        ハードウェアやkvmで処理を行ってコンテキストスイッチを減らしたい 
     486        vt-d, vhost, 割り込み仮想化、など 
     487 
Note: See TracChangeset for help on using the changeset viewer.