Commentary/kernelvm/20130413.log

   1 豊岡拓
   2
   3         ftrace snapshotを作った、Kernel 3.9で利用可能になる
   4
   5         トレースとは
   6                 この発表においては、プログラムの実行を理解する上で有益なデータをバッファ等に記録すること
   7         用途
   8                 デバッグ
   9                 障害解析
  10                         常時トレースを動かしておき、システムが停止した時にダンプを用いて理由を解析する
  11                 性能解析
  12                         どこが時間を食っているのか
  13                         ボトルネック解析
  14         ftrace
  15                 カーネルに組み込まれているトレース機構
  16                 元々はRTツリーのFunction tracerから始まった (なのでftrace)
  17                 現在では様々なトレース機能が統合されている
  18                         Events
  19                         Latency
  20                                 最大の割り込み禁止期間を知りたい
  21                         Stack
  22                         Block, mmio
  23                         Dynamic events
  24                                 好きなところにbreakpointを設置
  25         Trace Events
  26                 あらかじめ埋め込まれたトレースポイントを踏んだ時にイベントを記録
  27                 現在のLinux Kernelでは500以上が設定されている
  28                         syscallを含めるともっと
  29                 Kernelの中のTrace bufferに記録される
  30                 記録されるデータ
  31                         PID
  32                         CPUID
  33                         タイムスタンプ
  34                         イベント名
  35                         イベント毎の引数
  36                 Kernelsharkというツールで可視化出来る
  37                         Fedoraには標準である
  38         Function Tracer
  39                 カーネル内の全ての関数呼び出し・リターンを記録出来る
  40                 コールグラフ、処理時間が分かる
  41         Irqsoff Tracer
  42                 最大の割り込み禁止区間を検出
  43                 「最大で8013us発生したよ」
  44                         RTOSだとかなり大きい遅延
  45         ftraceの全体像
  46                 hook mechanisms
  47                         mcount
  48                         tracepoint
  49                         kprobes
  50                         (uprobes)
  51                 plugin tracers
  52                         function
  53                         irqsoff
  54                         wakeup
  55                 stack trace
  56                 trace event
  57                 common components
  58                         debugfs I/F
  59                         ring buffer
  60         debugfs経由で操作
  61                 /procの様なもの
  62                 疑似ファイルをecho, catする
  63                 trace-cmd
  64         /sys/kernel/debug/tracing/ 以下にファイルが出来る
  65         current_tracer
  66                 どのpluginを使うか指定する
  67         トレースバッファ
  68                 ロックレスリングバッファ
  69                 記録を読み出しを並行して行える
  70         # cat trace するだけでバッファを読み出せる
  71                 テキスト形式
  72                 バッファ内のデータは消費されない
  73                 書き込み可能、かつO_TRUNCでopenするとクリア
  74                         # echo > trace
  75         trace_pipe
  76                 traceに似ている
  77                 バッファ内のデータを読んだ際に消費する
  78         trace_pipe_raw
  79                 バイナリ形式で生の情報を出力する
  80                 splice(2)でゼロコピー転送が可能
  81                 cpu毎のI/Fしかない
  82                         一度に全部のCPUを読み込むことは出来ない
  83         options/
  84                 options/overwrite
  85                         バッファが満杯になった時に上書きするか、記録をやめるか
  86                         1 -> 古いイベントを捨てる (デフォルト)
  87                         0 -> 記録停止
  88         events/
  89                 イベントの有効・無効を制御
  90         filter
  91                 特定の条件を満たすイベントだけを記録出来る
  92         trace_marker
  93                 ユーザ空間からトレースバッファにイベントを記録する
  94                 write(2)で好きな文字列を書き込むだけで記録出来る
  95                 アプリケーションの動作チェックなどに有用
  96         最近入った・入る予定の機能
  97         Kprobes event(2.6.33～)
  98                 動いているカーネルに動的に好きな場所にイベントを埋め込める
  99                 カーネルの改造不要
 100         Uprobes event (2.6.35～)
 101                 Kprobesのユーザ空間番
 102                 アプリケーションの改造不要
 103                 Ojbdumpなどでアドレスを持ってくる必要がある
 104         Snapshot(3.9～)
 105                 トレースを止めずに、ある瞬間のバッファのスナップショットを取る機能
 106                 予備のトレースバッファを用意しておいて、好きなタイミングで切り替える
 107         # echo 1 > snapshot
 108                 これだけでスナップショットが取られる
 109                 この際に予備のバッファも割り当てられる
 110                 バッファの割り当て時間が気になる場合は、あらかじめ1を書いてバッファを確保しておくと良い
 111         Multi-buffer(3.10～？)
 112                 トレースバッファを用途別に複数個使い分ける機能
 113                 今までは一つのグローバルバッファしかなかった(せいぜいCPU毎)
 114                 バッファの個数はmkdir/rmdirで動的に変更可能
 115                 # cd instances/; mkdir buf_1
 116                 今のところ、Trace Eventsのみ利用可能
 117         Function-trigger
 118                 特定の関数が呼ばれた時にアクションを起こす
 119                 トーレス全体のOn/Off
 120                 特定のイベントが呼ばれたらトレースイベントをOn/Off
 121                 スナップショットを取る
 122                 スタックトレースを取る
 123                 # echo 'vfs_read:snapshot:1' > set_ftrace_filter
 124         trace_clock
 125                 タイムスタンプの種類を変更出来る
 126                 基本的にはTSCベース
 127                 local -> CPU間で同期を取らない
 128                 global -> ロックを取って同期させる
 129                 counter -> 順番だけを見たい時
 130                 x86-tsc (3.8～) -> 生のTSC
 131                         local/globalはTSCをマイクロ秒などに変更している
 132                 uptime -> jiffersだけなので軽い
 133                 perf -> perfと同じタイムスタンプをつける
 134         Q/A
 135                 オーバーヘッドはどれくらいか
 136                         どれくらいのイベントをOnにするかによる
 137                         取りたいイベントをあらかじめOnにして、その後負荷の具合を見ながら調整する
 138                 記録する際にロックを取るなどによりメモリ帯域を食ってしまうことはないか
 139                         基本的にCPU間でロックを取ることはない(ロックレス)
 140
 141
 142 @Fantom_JAC
 143 いまさら聞けないZigBee
 144         ZigBeeは日本では名前しか知られてない
 145         というか、まともな日本語の本も出ていない
 146
 147         ZigBeeの特徴
 148                 日本で流行っていない
 149                 802.15.4と混同される
 150                 BluetoothやWiFiに押され気味
 151                 年会費高い
 152                 etc...
 153         ZigBeeの歴史
 154                 ZigBee 2004とZigBee 2006は互換性がない
 155                 今年 ZigBee IPが出た
 156         ZigBee三大要素
 157                 IEEEで決まっているのはPHYとMACで決まっている (802シリーズ)
 158                 それより上はアライアンスで決めた
 159                 NWK
 160                         この層がZigBeeとしてもっともよく知られた層
 161                 APL
 162                         この層が全然理解されていない (後方互換性が無いのはここ)
 163                         APS, ZDO, ZCL
 164         802.15.4とは
 165                 IEEEが策定したPAN標準
 166                 802.15.1 -> Bluetooth
 167                 802.15ワーキンググループ (WPAN)
 168                 別名Low Rate WPAN
 169                         速度を犠牲にして消費電力を減らす
 170                 2.4GHz
 171         NWK Layer
 172                 メッシュを実現している層
 173                 ルーティング・ネットワークの管理
 174                 どのようなネットワークトポロジーになっているかはあまり重要ではない
 175                 世の中に出回っているのはほとんどZigBee Pro
 176                         毎回ルーティングを探す
 177                 NLDE
 178                         ふつうのData Entity
 179                         フレーム作ってセキュリティ掛けたり
 180                 NLME
 181                         ネットワークの開始・参加・離脱
 182                         PAN IDの管理
 183                         ルート探索
 184                         ルーティング
 185         ZigBee Network
 186                 Coordinator
 187                 Router
 188                 EndDevice -> 電気を食わない
 189         Coordinator
 190                 ネットワークに常に一台しか居ない
 191                 802.11におけるAPのようなもの
 192                 常にOn -> スリープ出来ない
 193                 基本的にPCだったりして、ゲートウェイ的働きをする
 194         Router
 195                 ネットワークを作成出来ない他はCoordinatorと同じ
 196         EndDevice
 197                 ネットワークを作成出来ない
 198                 子ノードを持つことが出来ない
 199                 ルーティング出来ない
 200                 通常はスリープ状態
 201                 普段はメッセージを受信することが出来ない
 202         Coordinator/RouterからEndDeviceにメッセージを投げると、直接届いているように見える
 203                 実はメッセージは親を経由する
 204                 EndDeviceはスリープから復帰した時、自分で取りに行く
 205                         メールチェックのような仕組み
 206         宛先のEndDeviceが取りに来なかったら、無慈悲に削除される
 207         デフォルトタイムアウトは7680ms
 208         何とかしてすぐに送りたい
 209                 たぶんWakeupボタンみたいなのがあるはず
 210                 Wakeupボタンを押すと…
 211                         DoSのように何度も読みに行くだけ
 212         FAQ
 213                 消費電力について
 214                         Coordinator/Routerは常にRXはON
 215                         電池がどんどん減る
 216                         極力スリープ状態を長くすることでしか解決出来ない
 217                         Wakeupを5分毎くらいにすると、半年くらいは電池が持つようになる
 218                 PANIDが2つ(?)
 219                         16-bit PANID
 220                         MACアドレスで使われるネットワーク識別ID
 221                 アドレスが二つ？
 222                         IEEE adressとNetwork address
 223                         IEEE -> いわゆるMAC adress (64bit)
 224                         Network adress IPスタックにおけるIPアドレスのようなもの
 225         APL Layer
 226                 アプリケーション層
 227                 ZigBee最大の特徴
 228                 APS、Application Framework (ZDO/ZCL)の二つに分かれている
 229                 アプリケーションフレームワークがプロトコルレベルで決まっている
 230                         ZigBeeは単なる「通信方式の一つ」ではない
 231                 ビジネスに直結する仕様が策定されている
 232                         アライアンスの存在意義
 233                 モダンな設計
 234                         オブジェクト指向の概念がふんだんに取り入れられている
 235         APS Layer
 236                 上位のフレームワーク層と直接やりとりする層
 237                 Binding, Group Management, etc...
 238                 Endpoint毎にユーザのアプリケーションが格納される
 239                 Binding
 240                         あるApplication Objectと別のそれをリンクする
 241                         単一方向
 242                         多重バインディング
 243                 Binding Table
 244         Group Addressing
 245                 複数のApplication Objectに対して一括送信したい
 246                 基本的にブロードキャスト、受信側が責任を持ってフィルタする
 247                 Group Table
 248         APS ACK
 249                 信頼性を高める
 250                 ACKタイムアウト時に再送
 251         Fragmentation
 252                 名の通りデータのフラグメント化
 253                 実装されていないこともある
 254                 ウィンドウサイズがあったりと、TCPに似ている
 255         Security
 256                 これだけで仕様書別になっているので、今回は省略
 257         Application Framework
 258                 Cluster
 259                         「機能」を指し示すような概念
 260                         Application Objectが外部にどのような機能を提供するか
 261                         Application Objectには必ずClusterが一つ以上ある
 262                         ZCLにおいては「クラス」に近い概念
 263                 Profile
 264                         Clusterの集まりを定義
 265                         クラスに対するパッケージに近い概念
 266                         APSメッセージはCluster IDとProfile IDを指定する必要がある
 267         ZigBee Device Object
 268                 USBのEndpoint0と似ている
 269                 Application Objectの実装
 270                 ZDOとZDPは違う概念
 271                 ユーザが作成するApplication Objectは通常APSDE以外触れることが出来ない
 272                         サンドボックスの様な仕組み
 273                         別途ZDOを経由する
 274         ZigBee Cluster Library
 275                 ユーザが作成するApplication Objectの実質的な仕様、枠組み
 276                 必ずサーバとクライアントが対になって通信しなければいけない
 277                 Profile固有のClusterと共通のClusterが存在する
 278         ZigBee IP
 279                 つまらないので省略
 280         Pure Java ZigBee Application Framework: Bekko (LGPL)
 281         アライアンス入会とは？
 282                 ZigBeeを名乗るプロダクトを開発する権利
 283                 HAやSE等PAPプロダクトを開発する権利
 284                 ただし、非営利目的であれば入会不要
 285                 営利目的であっても既に認定を受けたプロダクトを利用するだけなら入会不要
 286                         XBeeは入会不要
 287         Q/A
 288                 有名なプロダクト例
 289                         日本で市販はされていない
 290                         BluetoothやWiFiとは違い、B2Bが目的なので、コンシューマ向けではない
 291                         アメリカにおいては、Control4Cが、「一戸建て建てる時にZigBee組み込みませんか」みたいなキャンペーンはしている
 292                         蛍光管をLEDに代える際に、ZigBee組込みで、配線無しでOn/Off出来る製品とか
 293                         日本ではMAKEというイベントに行けば見れるかも
 294
 295
 296 @fusioniojp
 297 FUSION-IO関連の楽しいお話
 298         IOMEMORY SDKとNVMインターフェース
 299                 Non Volatile Memory
 300         NANDフラッシュメモリとDMAコントローラを一体にしたもの
 301
 302         現行
 303                 NANDとメインメモリの間にI/Fのコントローラが挟まっていて、遅い
 304                         SASコントローラなど
 305         これから (カットスルーアーキテクチャ)
 306                 FPGAで実装されているデータバスコントローラを使う
 307                 メインメモリに直接コピーされる
 308         512byte -> 10usで書ける
 309         HPCではデータをHDD上に置かない
 310         SSDが出てきた時、「NANDはメモリなんだから、メモリのようにI/O出来るようにすべきだ」
 311         不揮発メモリであれば、BlockI/Oでは実現出来ないような操作が可能
 312                 BlockI/Oは回転型メディアにあわせて設計されている
 313                 テープ
 314                         open/read/write/rewind
 315                 ディスク
 316                         open/read/write/seek
 317                 SSD
 318                         ディスクと同じ様にあえてしている
 319                         Trimとかは一応あるが……
 320                 ioMemory NVM
 321                         不揮発メモリの特性を生かした追加機能
 322                         通常のライト＋アトミックライト・条件付きライト
 323                                 ジャーナル要らなくね？
 324                         通常のライト＋TTLライト(のちに自動消去)
 325                                 このデータは自動的に消滅する
 326                         mmap＋クラッシュセーフ・バージョニング
 327                                 先ほどのftraceの様にどんどんログを書き込む
 328         SSDの登場により、フラッシュメモリを使ったアプリケーションが実現した
 329                 フラッシュメモリをメモリとして利用すると、ソフトウェア開発のあり方が変化する
 330         現行
 331                 アプリケーション -> BlockI/O、ネットワークファイル
 332         これから
 333                 アトミックI/O
 334                 トランザクション
 335                 ユーザ定義のオブジェクトによりトランザクション
 336                 Key-Valueトランザクション
 337                         memcached
 338         将来
 339                 高速なロギング
 340                 チェックポイントメモリ
 341                 メモリトランザクション
 342                 CPUからメモリに書き込むように、フラッシュメモリに書き込める
 343         100万IOPSのカードは既に実現している
 344                 CPUのコンテキストスイッチの方が問題になってくる
 345                 -> mmaped I/Oすれば良いのでは
 346         64byte/1thread -> 960万回
 347         スパースアドレス空間
 348         デバイスI/Fのオープン化と、OSS
 349                 directFS
 350                 NVM APIライブラリ
 351                 Atomic writeはSCSI標準化に向けてプロポーザルを出した
 352         ハードウェア側で書き込みを保証出来るので、アプリケーションとしては単に「書き込む」だけで良い
 353                 MySQLのダブルバッファーのようなことは必要なくなる
 354                 書き込み量が減るので、製品の寿命も長くなって良い
 355         書き込みの粒度を512byteから小さくすれば、一回の書き込みに掛かる時間は短くなる
 356         directFS
 357         swap -> Extended memory
 358
 359         Q/A
 360                 ウェアレベリングなどはどこで行われているか
 361                         CPU側で行っている
 362                         SSDのような小さなデバイス上に実装されているマイコンで行われるのを待ってCPUが
 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