Changeset de9540b in lab.git for Commentary/kernelvm
- Timestamp:
- Apr 13, 2013 4:25:25 PM (12 years ago)
- Branches:
- master, trunk
- Children:
- aa2cedc
- Parents:
- d3973ef
- File:
-
- 1 edited
-
Commentary/kernelvm/20130413.log (modified) (1 diff)
Legend:
- Unmodified
- Added
- Removed
-
Commentary/kernelvm/20130413.log
rd3973ef rde9540b 362 362 SSDのような小さなデバイス上に実装されているマイコンで行われるのを待ってCPUが 363 363 ブロッキングされるより、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 林佳寛 419 QEMUと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.
