3 ftrace snapshotを作った、Kernel 3.9で利用可能になる
6 この発表においては、プログラムの実行を理解する上で有益なデータをバッファ等に記録すること
10 常時トレースを動かしておき、システムが停止した時にダンプを用いて理由を解析する
16 元々はRTツリーのFunction tracerから始まった (なのでftrace)
26 あらかじめ埋め込まれたトレースポイントを踏んだ時にイベントを記録
27 現在のLinux Kernelでは500以上が設定されている
29 Kernelの中のTrace bufferに記録される
36 Kernelsharkというツールで可視化出来る
39 カーネル内の全ての関数呼び出し・リターンを記録出来る
64 /sys/kernel/debug/tracing/ 以下にファイルが出来る
70 # cat trace するだけでバッファを読み出せる
73 書き込み可能、かつO_TRUNCでopenするとクリア
85 バッファが満杯になった時に上書きするか、記録をやめるか
86 1 -> 古いイベントを捨てる (デフォルト)
93 ユーザ空間からトレースバッファにイベントを記録する
94 write(2)で好きな文字列を書き込むだけで記録出来る
97 Kprobes event(2.6.33~)
98 動いているカーネルに動的に好きな場所にイベントを埋め込める
100 Uprobes event (2.6.35~)
103 Ojbdumpなどでアドレスを持ってくる必要がある
105 トレースを止めずに、ある瞬間のバッファのスナップショットを取る機能
106 予備のトレースバッファを用意しておいて、好きなタイミングで切り替える
110 バッファの割り当て時間が気になる場合は、あらかじめ1を書いてバッファを確保しておくと良い
112 トレースバッファを用途別に複数個使い分ける機能
113 今までは一つのグローバルバッファしかなかった(せいぜいCPU毎)
114 バッファの個数はmkdir/rmdirで動的に変更可能
115 # cd instances/; mkdir buf_1
116 今のところ、Trace Eventsのみ利用可能
118 特定の関数が呼ばれた時にアクションを起こす
120 特定のイベントが呼ばれたらトレースイベントをOn/Off
123 # echo 'vfs_read:snapshot:1' > set_ftrace_filter
127 local -> CPU間で同期を取らない
128 global -> ロックを取って同期させる
130 x86-tsc (3.8~) -> 生のTSC
131 local/globalはTSCをマイクロ秒などに変更している
132 uptime -> jiffersだけなので軽い
133 perf -> perfと同じタイムスタンプをつける
137 取りたいイベントをあらかじめOnにして、その後負荷の具合を見ながら調整する
138 記録する際にロックを取るなどによりメモリ帯域を食ってしまうことはないか
139 基本的にCPU間でロックを取ることはない(ロックレス)
144 ZigBeeは日本では名前しか知られてない
154 ZigBee 2004とZigBee 2006は互換性がない
157 IEEEで決まっているのはPHYとMACで決まっている (802シリーズ)
160 この層がZigBeeとしてもっともよく知られた層
162 この層が全然理解されていない (後方互換性が無いのはここ)
166 802.15.1 -> Bluetooth
167 802.15ワーキンググループ (WPAN)
174 どのようなネットワークトポロジーになっているかはあまり重要ではない
175 世の中に出回っているのはほとんどZigBee Pro
193 基本的にPCだったりして、ゲートウェイ的働きをする
195 ネットワークを作成出来ない他はCoordinatorと同じ
202 Coordinator/RouterからEndDeviceにメッセージを投げると、直接届いているように見える
204 EndDeviceはスリープから復帰した時、自分で取りに行く
206 宛先のEndDeviceが取りに来なかったら、無慈悲に削除される
209 たぶんWakeupボタンみたいなのがあるはず
214 Coordinator/Routerは常にRXはON
216 極力スリープ状態を長くすることでしか解決出来ない
217 Wakeupを5分毎くらいにすると、半年くらいは電池が持つようになる
220 MACアドレスで使われるネットワーク識別ID
222 IEEE adressとNetwork address
223 IEEE -> いわゆるMAC adress (64bit)
224 Network adress IPスタックにおけるIPアドレスのようなもの
228 APS、Application Framework (ZDO/ZCL)の二つに分かれている
229 アプリケーションフレームワークがプロトコルレベルで決まっている
230 ZigBeeは単なる「通信方式の一つ」ではない
234 オブジェクト指向の概念がふんだんに取り入れられている
236 上位のフレームワーク層と直接やりとりする層
237 Binding, Group Management, etc...
238 Endpoint毎にユーザのアプリケーションが格納される
240 あるApplication Objectと別のそれをリンクする
245 複数のApplication Objectに対して一括送信したい
246 基本的にブロードキャスト、受信側が責任を持ってフィルタする
254 ウィンドウサイズがあったりと、TCPに似ている
256 これだけで仕様書別になっているので、今回は省略
257 Application Framework
260 Application Objectが外部にどのような機能を提供するか
261 Application Objectには必ずClusterが一つ以上ある
266 APSメッセージはCluster IDとProfile IDを指定する必要がある
269 Application Objectの実装
271 ユーザが作成するApplication Objectは通常APSDE以外触れることが出来ない
274 ZigBee Cluster Library
275 ユーザが作成するApplication Objectの実質的な仕様、枠組み
276 必ずサーバとクライアントが対になって通信しなければいけない
277 Profile固有のClusterと共通のClusterが存在する
280 Pure Java ZigBee Application Framework: Bekko (LGPL)
282 ZigBeeを名乗るプロダクトを開発する権利
283 HAやSE等PAPプロダクトを開発する権利
285 営利目的であっても既に認定を受けたプロダクトを利用するだけなら入会不要
290 BluetoothやWiFiとは違い、B2Bが目的なので、コンシューマ向けではない
291 アメリカにおいては、Control4Cが、「一戸建て建てる時にZigBee組み込みませんか」みたいなキャンペーンはしている
292 蛍光管をLEDに代える際に、ZigBee組込みで、配線無しでOn/Off出来る製品とか
293 日本ではMAKEというイベントに行けば見れるかも
298 IOMEMORY SDKとNVMインターフェース
300 NANDフラッシュメモリとDMAコントローラを一体にしたもの
303 NANDとメインメモリの間にI/Fのコントローラが挟まっていて、遅い
306 FPGAで実装されているデータバスコントローラを使う
310 SSDが出てきた時、「NANDはメモリなんだから、メモリのようにI/O出来るようにすべきだ」
311 不揮発メモリであれば、BlockI/Oでは実現出来ないような操作が可能
312 BlockI/Oは回転型メディアにあわせて設計されている
314 open/read/write/rewind
322 通常のライト+アトミックライト・条件付きライト
324 通常のライト+TTLライト(のちに自動消去)
326 mmap+クラッシュセーフ・バージョニング
327 先ほどのftraceの様にどんどんログを書き込む
328 SSDの登場により、フラッシュメモリを使ったアプリケーションが実現した
329 フラッシュメモリをメモリとして利用すると、ソフトウェア開発のあり方が変化する
331 アプリケーション -> BlockI/O、ネットワークファイル
335 ユーザ定義のオブジェクトによりトランザクション
342 CPUからメモリに書き込むように、フラッシュメモリに書き込める
343 100万IOPSのカードは既に実現している
344 CPUのコンテキストスイッチの方が問題になってくる
345 -> mmaped I/Oすれば良いのでは
346 64byte/1thread -> 960万回
351 Atomic writeはSCSI標準化に向けてプロポーザルを出した
352 ハードウェア側で書き込みを保証出来るので、アプリケーションとしては単に「書き込む」だけで良い
353 MySQLのダブルバッファーのようなことは必要なくなる
354 書き込み量が減るので、製品の寿命も長くなって良い
355 書き込みの粒度を512byteから小さくすれば、一回の書き込みに掛かる時間は短くなる
357 swap -> Extended memory
360 ウェアレベリングなどはどこで行われているか
362 SSDのような小さなデバイス上に実装されているマイコンで行われるのを待ってCPUが
363 ブロッキングされるより、CPUで行った方が結果として早かったりする
367 ntddk 由来はWindowsでドライバを書く際にincludeするヘッダから
370 Windows上で脆弱性を突く攻撃を防ぐツール
377 ビルド時に、正規の例外ハンドラの一覧を作りそれ以外は実行出来ないようにする
378 サードパーティのDLLなどは行われていないことが多い
385 VirtualAllocによりメモリ属性を変更される
387 Return-orientied Programming
388 JITコンパイラによって、実行中に悪意のあるコードを生成
395 XPの様な骨董品でも、脆弱性防御機能が有効になっていないバイナリでも防げる
397 EMETを導入しないと当然使えないので、ビルド時にEMETの機能が付加されて欲しい
400 Windowsの後方互換性を保つための仕組み
402 EMET.dllにはGetHookAPIs, NotifyShimsというAPIがエクスポートされている
409 Win32APIでGetProcessDEPPolicyで無理矢理有効に出来る
412 悪意のあるコードはfs:[30h]を読み取り、Win32APIのアドレスを得ようとする
413 Export Address Tableへのアクセスをフィルタ
416 カーネルにはパッチを防ぐ機構がx64には別に存在している
420 QEMUとは…、kvmとは…、vt-xとは…
422 qemu-kvmはホストOSから見ると、一つのプロセスである
423 ゲストOSはCPUをベアマシンと変わらず使う
424 センシティブ命令に関しては、vt-xとホストOSが頑張るので、ゲストOSを改造する必要がない
425 qemu-kvmはカーネルのkvmもデューるを用いてvt-xを使う
427 qemu, kvm, vt-xでどのように処理が流れているか知る
428 Fedora 15 x86_64 2.6.42
429 virtio-blkに何かをwriteした時にどのようなことが起きるのか
431 ゲストOS上で、プロセスがファイルを開いて書き込む
433 ファイルシステムを通じて、BlockI/O
435 virtioはゲストとホスト間でデータを共有するためのqueueに要求を入れる
442 センシティブ命令をトラップするための仕組みがvt-x
445 ゲストOSが発行したPORT/IOをホストOSでそのまま実行してしまうと、そのアドレスは
446 ホストでは違うデバイス、あるいは何もないかもしれない
447 -> VMExitしてエミュレーションする
449 センシティブ命令を契機として、VMEnterした命令の次に処理が戻ってくる
451 vmx_handle_exitに戻ってくる
452 VMExitの要因になったハンドラを呼び出す
453 どういう理由でExitしたかを格納した構造体がホストOSに渡される
454 今回は EXIT_REASON_IO_INSTRUCTION -> handle_io
456 引数に指定されたポート版を処理するための関数が設定されているかを確認する
457 が、virtio-blk用の関数は設定されていない
458 関数が設定されていて、処理がうまくいけば1、そうでなければ0
461 __vpu_runからも0でreturnする -> kvm_arch_vcpu_ioctl_run
462 kvm_arch_vcpu_ioctl_run: /dev/kvmへのioctlを処理する
464 /dev/kvmに対するioctlがreturnした、ということになる
465 qemu-kvmはioctlがreturnしてきた理由を確認する
468 今回はvirtio-blkのデバイスが見つかる
470 qemu-kvm自体は普通のプロセスなので、ライブラリ関数を呼び出す -> 最終的にはホストOSのシステムコールへ
473 ioctlされたkvmはVM Enterする
474 9. センシティブ命令のエミュレーション完了
478 vt-x/kvmの力を借りて、なるべくエミュレーションしないように改造されたQEMU
483 メモリのコピーやringの切替にCPUをたくさん使う
484 VMX NON-ROOT/VMX ROOTを超えるペナルティが大きい
485 ハードウェアやkvmで処理を行ってコンテキストスイッチを減らしたい
486 vt-d, vhost, 割り込み仮想化、など