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, 割り込み仮想化、など
491 ZFS root/ ZFS + Samba
496 RAID5, RAID6, Triple Parity
504 Memory 512MB * 4 -> 足りない
506 2GB * 4 -> 原因不明で停止したことがある
508 loader.confに設定してメモリを節約する
511 wiki.freebsd.org/RootOnZFS
512 構成する全てのdiskにルートパーティションを入れておくと、後で楽
514 zfs replace old-disk new-disk
525 ソースコードを紛失した、仕方ないので続きはバイナリで作ろう
527 ソースコードは残したくない、バイナリで書くしかない
531 同じような命令を作っていて、ちょっとした違いにはまる
545 DVD -> プリンタブルの糊でメディア同士がくっついてしまう
549 SANYOチップのPlextorドライブがBEST
555 色素を新規開発したのに、Media IDを使い回したせいで、おかしなことになった
558 DVD焼く時に埃が付いていると、その部分だけエラーの山になるが、特に問題はない
560 多くのドライブは、書き込み中に速度を落として様子をみたりしている
563 そんなことよりバックアップ多重化したほうがいい
564 プレス版のDVD-ROMでも10万くらいエラーは出る
565 TDKの超硬は5年保存でも4万くらいだった
571 EMCによるGangnam Styleのパロディ
574 Now everybody scale out down the row!
576 スケールアウトが大切だ、というのは今だけ?
581 文字をデバイスに表示する時に表示するデータ
589 CFFのフォントに脆弱性があってJailbreakとか
592 AdobeとMicrosoftが策定したフォント形式
593 基本的にはTrueType、内部テーブルの種類が追加されている
597 PDFにCFFグリフのOpenTypeを埋め込むと、CFFの部分だけ使われたりする
600 .notdefCharString, A CharString
606 each index rollといった命令
611 Windows OSごと落ちるフォントを作ろうとしたが、詳細を忘れてしまって、次の機会
626 MIST1032ISA / MIST1032SA
641 Intel SDMのopcode mapから作るディスアセンブラ in kernel
642 kprobes/ftrace/perftoolsとかのメンテナの一人
643 # cat debug/x86/disassembly
644 現在走っているカーネルのメモリを指定した関数名でダンプして、逆アセンブルする
646 kprobesのデバッグ -> 自己書換コードの様子が知りたい
648 既存のものはどれもオレオレフォーマットで出力するものばかり
651 Intel Officialなinstructionのエンコード表記
652 -> arch/x86/lib/x86-opcode-map.txt
657 debugfs, kdb, toolsの三つの使い方が可能
659 CONFIG_X86_DISASSEMBLE
660 Oopsでcodeの欄が既にdisassemble済で出てくる
673 Gentooにはunpackというコマンドが用意されている
675 econfを打つだけで、様々なオプションをつけてconfigureしてくれる
676 --disable-dependency-tracking
677 automakeの機能であるコードの依存チェックを無効化する
678 --disable-silent-rules
679 CC fooとかLD fooとかに省略されてしまうのを無効化
682 /etc/portage/patches で管理される
686 "cd hoge; make"とか書いてある
687 CFLAGS, LDFLAGSが反映されない
696 .GCC.command.line section
701 command not found以外にも
709 --as-neededをつけるとリンクが通らなくなる
715 RUNPATH, TEXTREL, EXECSTACKが変な値になっている
718 world writableにsetuid
724 gccのバージョン・カーネルの設定チェック
729 DragonFly BSD's Hypervisor vkernel
737 git gc --agressiveが後ろで走って壊れる
738 vkernel専用のカーネルをmakeする必要がある
741 通常のプロセスと同じように、gdbでアタッチしてbreakpointとか設置出来る
747 ゲストOSの全命令をソフトウェアエミュレーション -> 遅い
748 vt-x以前: 実行されると困る命令だけを動的に置き換えて、ネイティブに実行
750 vt-x後: CPUをゲストモードへ切り替え、ゲストOSのプログラムをネイティブに実行
752 本来は、ハイパーバイザーはCPU命令の置き換えはしないはずなのに……?
753 命令エミュレーションをしている部分がある!
754 VT-xなハイパーバイザーのライフサイクル
755 ホストOSのカーネルからゲストモードへ (VMEntry)
756 ハードウェアへのアクセスなど、ハイパーバイザーの介入が必要になったら、ゲストモードを停止し、ホストOSへ戻る (VMExit)
765 Exit Qualificationの情報に用いてIO命令をエミュレーション出来る
766 Exit Qualificationを見ればどうすればいいか分かる
768 MMIOは通常のメモリアクセスと同じ命令を用いる
769 IO命令と違って命令で判別してVMExit出来ない
771 MMIO領域に相当するページにアクセスした時にVMExit(EPT violation)が起きるようにEPTを設定
776 ゲストOSがアクセスしたアドレス(論理・物理)
777 アクセスがread/writeどちらかは分かる
778 書き込み元・読み込み先の情報(アドレス・レジスタ)と、アクセス幅が分からない
780 メモリアクセスする命令はx86だとかなりある
782 ゲストEIPの指すアドレスの命令をデコードして、opcode/oprandを取得
786 x86にはメモリアクセスする命令がとても多い
787 そもそもEPT violationはページのアクセス権限エラーを知らせるVMExitであって、MMIOを知らせるものではない
788 頻繁にMMIOされるとパフォーマンス的に不利
790 Local APICは割り込み周りで頻繁にアクセスされるが、MMIOを使っており準仮想化にもなじみづらいデバイス
791 この領域のMMIOだけはVT-xが特別扱いされている
792 レジスタ・条件によってはVMExit自体省略
794 MMIO領域には、読み書きによる副作用が無く、単純なメモリの読み書きに置き換えられる部分が存在
796 VMExitしたらカーネル内で命令エミュレーションを実行、メモリ読み書き
797 ユーザランドでのデバイスエミュレーションを省略
800 ハードウェア仮想化支援機構であっても、全部やってくれるわけではない
801 出来ない部分はソフトウェアでやらないといけない
804 Exit Qualificationで得られるアドレスは実は正確ではない
805 例えば、ページフォルトの例では、境界をまたいでアクセスした際に、
806 実際にアクセスを開始したアドレスではなくて、禁止されているアドレスのみが
807 渡されるので、それを使ってエミュレーションするのは危険
817 Network Virtual Terminalを作ること
818 コードセットは7bit USASCII, 標準制御機構
820 ターミナルとプロセスで表示内容を同期させること
822 もしかしてネゴシエーションで暗号化出来るのでは?
828 telnetはソースルーティングするパケットを作れる