X-Git-Url: http://lab.mitty.jp/git/?a=blobdiff_plain;f=Commentary%2Fkernelvm%2F20130413.log;h=ece8842575ef8253b2329a3e2aa2cd6815f71ad6;hb=de9540b3b70a3084a0c894baa1399c84db76425e;hp=4350d9db317290a26149db2d6a95d285c6e9c3da;hpb=04eb6d70209bc2e65c16cac2922a5e6067f7cd9f;p=lab.git

diff --git a/Commentary/kernelvm/20130413.log b/Commentary/kernelvm/20130413.log
index 4350d9d..ece8842 100644
--- a/Commentary/kernelvm/20130413.log
+++ b/Commentary/kernelvm/20130413.log
@@ -293,3 +293,195 @@
 			日本ではMAKEというイベントに行けば見れるかも
 
 
+@fusioniojp
+FUSION-IO関連の楽しいお話
+	IOMEMORY SDKとNVMインターフェース
+		Non Volatile Memory
+	NANDフラッシュメモリとDMAコントローラを一体にしたもの
+	
+	現行
+		NANDとメインメモリの間にI/Fのコントローラが挟まっていて、遅い
+			SASコントローラなど
+	これから (カットスルーアーキテクチャ)
+		FPGAで実装されているデータバスコントローラを使う
+		メインメモリに直接コピーされる
+	512byte -> 10usで書ける
+	HPCではデータをHDD上に置かない
+	SSDが出てきた時、「NANDはメモリなんだから、メモリのようにI/O出来るようにすべきだ」
+	不揮発メモリであれば、BlockI/Oでは実現出来ないような操作が可能
+		BlockI/Oは回転型メディアにあわせて設計されている
+		テープ
+			open/read/write/rewind
+		ディスク
+			open/read/write/seek
+		SSD
+			ディスクと同じ様にあえてしている
+			Trimとかは一応あるが……
+		ioMemory NVM
+			不揮発メモリの特性を生かした追加機能
+			通常のライト＋アトミックライト・条件付きライト
+				ジャーナル要らなくね？
+			通常のライト＋TTLライト(のちに自動消去)
+				このデータは自動的に消滅する
+			mmap＋クラッシュセーフ・バージョニング
+				先ほどのftraceの様にどんどんログを書き込む
+	SSDの登場により、フラッシュメモリを使ったアプリケーションが実現した
+		フラッシュメモリをメモリとして利用すると、ソフトウェア開発のあり方が変化する
+	現行
+		アプリケーション -> BlockI/O、ネットワークファイル
+	これから
+		アトミックI/O
+		トランザクション
+		ユーザ定義のオブジェクトによりトランザクション
+		Key-Valueトランザクション
+			memcached
+	将来
+		高速なロギング
+		チェックポイントメモリ
+		メモリトランザクション
+		CPUからメモリに書き込むように、フラッシュメモリに書き込める
+	100万IOPSのカードは既に実現している
+		CPUのコンテキストスイッチの方が問題になってくる
+		-> mmaped I/Oすれば良いのでは
+	64byte/1thread -> 960万回
+	スパースアドレス空間
+	デバイスI/Fのオープン化と、OSS
+		directFS
+		NVM APIライブラリ
+		Atomic writeはSCSI標準化に向けてプロポーザルを出した
+	ハードウェア側で書き込みを保証出来るので、アプリケーションとしては単に「書き込む」だけで良い
+		MySQLのダブルバッファーのようなことは必要なくなる
+		書き込み量が減るので、製品の寿命も長くなって良い
+	書き込みの粒度を512byteから小さくすれば、一回の書き込みに掛かる時間は短くなる
+	directFS
+	swap -> Extended memory
+	
+	Q/A
+		ウェアレベリングなどはどこで行われているか
+			CPU側で行っている
+			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, 割り込み仮想化、など
+