豊岡拓 ftrace snapshotを作った、Kernel 3.9で利用可能になる トレースとは この発表においては、プログラムの実行を理解する上で有益なデータをバッファ等に記録すること 用途 デバッグ 障害解析 常時トレースを動かしておき、システムが停止した時にダンプを用いて理由を解析する 性能解析 どこが時間を食っているのか ボトルネック解析 ftrace カーネルに組み込まれているトレース機構 元々はRTツリーのFunction tracerから始まった (なのでftrace) 現在では様々なトレース機能が統合されている Events Latency 最大の割り込み禁止期間を知りたい Stack Block, mmio Dynamic events 好きなところにbreakpointを設置 Trace Events あらかじめ埋め込まれたトレースポイントを踏んだ時にイベントを記録 現在のLinux Kernelでは500以上が設定されている syscallを含めるともっと Kernelの中のTrace bufferに記録される 記録されるデータ PID CPUID タイムスタンプ イベント名 イベント毎の引数 Kernelsharkというツールで可視化出来る Fedoraには標準である Function Tracer カーネル内の全ての関数呼び出し・リターンを記録出来る コールグラフ、処理時間が分かる Irqsoff Tracer 最大の割り込み禁止区間を検出 「最大で8013us発生したよ」 RTOSだとかなり大きい遅延 ftraceの全体像 hook mechanisms mcount tracepoint kprobes (uprobes) plugin tracers function irqsoff wakeup stack trace trace event common components debugfs I/F ring buffer debugfs経由で操作 /procの様なもの 疑似ファイルをecho, catする trace-cmd /sys/kernel/debug/tracing/ 以下にファイルが出来る current_tracer どのpluginを使うか指定する トレースバッファ ロックレスリングバッファ 記録を読み出しを並行して行える # cat trace するだけでバッファを読み出せる テキスト形式 バッファ内のデータは消費されない 書き込み可能、かつO_TRUNCでopenするとクリア # echo > trace trace_pipe traceに似ている バッファ内のデータを読んだ際に消費する trace_pipe_raw バイナリ形式で生の情報を出力する splice(2)でゼロコピー転送が可能 cpu毎のI/Fしかない 一度に全部のCPUを読み込むことは出来ない options/ options/overwrite バッファが満杯になった時に上書きするか、記録をやめるか 1 -> 古いイベントを捨てる (デフォルト) 0 -> 記録停止 events/ イベントの有効・無効を制御 filter 特定の条件を満たすイベントだけを記録出来る trace_marker ユーザ空間からトレースバッファにイベントを記録する write(2)で好きな文字列を書き込むだけで記録出来る アプリケーションの動作チェックなどに有用 最近入った・入る予定の機能 Kprobes event(2.6.33～) 動いているカーネルに動的に好きな場所にイベントを埋め込める カーネルの改造不要 Uprobes event (2.6.35～) Kprobesのユーザ空間番 アプリケーションの改造不要 Ojbdumpなどでアドレスを持ってくる必要がある Snapshot(3.9～) トレースを止めずに、ある瞬間のバッファのスナップショットを取る機能 予備のトレースバッファを用意しておいて、好きなタイミングで切り替える # echo 1 > snapshot これだけでスナップショットが取られる この際に予備のバッファも割り当てられる バッファの割り当て時間が気になる場合は、あらかじめ1を書いてバッファを確保しておくと良い Multi-buffer(3.10～？) トレースバッファを用途別に複数個使い分ける機能 今までは一つのグローバルバッファしかなかった(せいぜいCPU毎) バッファの個数はmkdir/rmdirで動的に変更可能 # cd instances/; mkdir buf_1 今のところ、Trace Eventsのみ利用可能 Function-trigger 特定の関数が呼ばれた時にアクションを起こす トーレス全体のOn/Off 特定のイベントが呼ばれたらトレースイベントをOn/Off スナップショットを取る スタックトレースを取る # echo 'vfs_read:snapshot:1' > set_ftrace_filter trace_clock タイムスタンプの種類を変更出来る 基本的にはTSCベース local -> CPU間で同期を取らない global -> ロックを取って同期させる counter -> 順番だけを見たい時 x86-tsc (3.8～) -> 生のTSC local/globalはTSCをマイクロ秒などに変更している uptime -> jiffersだけなので軽い perf -> perfと同じタイムスタンプをつける Q/A オーバーヘッドはどれくらいか どれくらいのイベントをOnにするかによる 取りたいイベントをあらかじめOnにして、その後負荷の具合を見ながら調整する 記録する際にロックを取るなどによりメモリ帯域を食ってしまうことはないか 基本的にCPU間でロックを取ることはない(ロックレス) @Fantom_JAC いまさら聞けないZigBee ZigBeeは日本では名前しか知られてない というか、まともな日本語の本も出ていない ZigBeeの特徴 日本で流行っていない 802.15.4と混同される BluetoothやWiFiに押され気味 年会費高い etc... ZigBeeの歴史 ZigBee 2004とZigBee 2006は互換性がない 今年 ZigBee IPが出た ZigBee三大要素 IEEEで決まっているのはPHYとMACで決まっている (802シリーズ) それより上はアライアンスで決めた NWK この層がZigBeeとしてもっともよく知られた層 APL この層が全然理解されていない (後方互換性が無いのはここ) APS, ZDO, ZCL 802.15.4とは IEEEが策定したPAN標準 802.15.1 -> Bluetooth 802.15ワーキンググループ (WPAN) 別名Low Rate WPAN 速度を犠牲にして消費電力を減らす 2.4GHz NWK Layer メッシュを実現している層 ルーティング・ネットワークの管理 どのようなネットワークトポロジーになっているかはあまり重要ではない 世の中に出回っているのはほとんどZigBee Pro 毎回ルーティングを探す NLDE ふつうのData Entity フレーム作ってセキュリティ掛けたり NLME ネットワークの開始・参加・離脱 PAN IDの管理 ルート探索 ルーティング ZigBee Network Coordinator Router EndDevice -> 電気を食わない Coordinator ネットワークに常に一台しか居ない 802.11におけるAPのようなもの 常にOn -> スリープ出来ない 基本的にPCだったりして、ゲートウェイ的働きをする Router ネットワークを作成出来ない他はCoordinatorと同じ EndDevice ネットワークを作成出来ない 子ノードを持つことが出来ない ルーティング出来ない 通常はスリープ状態 普段はメッセージを受信することが出来ない Coordinator/RouterからEndDeviceにメッセージを投げると、直接届いているように見える 実はメッセージは親を経由する EndDeviceはスリープから復帰した時、自分で取りに行く メールチェックのような仕組み 宛先のEndDeviceが取りに来なかったら、無慈悲に削除される デフォルトタイムアウトは7680ms 何とかしてすぐに送りたい たぶんWakeupボタンみたいなのがあるはず Wakeupボタンを押すと… DoSのように何度も読みに行くだけ FAQ 消費電力について Coordinator/Routerは常にRXはON 電池がどんどん減る 極力スリープ状態を長くすることでしか解決出来ない Wakeupを5分毎くらいにすると、半年くらいは電池が持つようになる PANIDが2つ(?) 16-bit PANID MACアドレスで使われるネットワーク識別ID アドレスが二つ？ IEEE adressとNetwork address IEEE -> いわゆるMAC adress (64bit) Network adress IPスタックにおけるIPアドレスのようなもの APL Layer アプリケーション層 ZigBee最大の特徴 APS、Application Framework (ZDO/ZCL)の二つに分かれている アプリケーションフレームワークがプロトコルレベルで決まっている ZigBeeは単なる「通信方式の一つ」ではない ビジネスに直結する仕様が策定されている アライアンスの存在意義 モダンな設計 オブジェクト指向の概念がふんだんに取り入れられている APS Layer 上位のフレームワーク層と直接やりとりする層 Binding, Group Management, etc... Endpoint毎にユーザのアプリケーションが格納される Binding あるApplication Objectと別のそれをリンクする 単一方向 多重バインディング Binding Table Group Addressing 複数のApplication Objectに対して一括送信したい 基本的にブロードキャスト、受信側が責任を持ってフィルタする Group Table APS ACK 信頼性を高める ACKタイムアウト時に再送 Fragmentation 名の通りデータのフラグメント化 実装されていないこともある ウィンドウサイズがあったりと、TCPに似ている Security これだけで仕様書別になっているので、今回は省略 Application Framework Cluster 「機能」を指し示すような概念 Application Objectが外部にどのような機能を提供するか Application Objectには必ずClusterが一つ以上ある ZCLにおいては「クラス」に近い概念 Profile Clusterの集まりを定義 クラスに対するパッケージに近い概念 APSメッセージはCluster IDとProfile IDを指定する必要がある ZigBee Device Object USBのEndpoint0と似ている Application Objectの実装 ZDOとZDPは違う概念 ユーザが作成するApplication Objectは通常APSDE以外触れることが出来ない サンドボックスの様な仕組み 別途ZDOを経由する ZigBee Cluster Library ユーザが作成するApplication Objectの実質的な仕様、枠組み 必ずサーバとクライアントが対になって通信しなければいけない Profile固有のClusterと共通のClusterが存在する ZigBee IP つまらないので省略 Pure Java ZigBee Application Framework: Bekko (LGPL) アライアンス入会とは？ ZigBeeを名乗るプロダクトを開発する権利 HAやSE等PAPプロダクトを開発する権利 ただし、非営利目的であれば入会不要 営利目的であっても既に認定を受けたプロダクトを利用するだけなら入会不要 XBeeは入会不要 Q/A 有名なプロダクト例 日本で市販はされていない BluetoothやWiFiとは違い、B2Bが目的なので、コンシューマ向けではない アメリカにおいては、Control4Cが、「一戸建て建てる時にZigBee組み込みませんか」みたいなキャンペーンはしている 蛍光管をLEDに代える際に、ZigBee組込みで、配線無しでOn/Off出来る製品とか 日本では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, 割り込み仮想化、など