豊岡拓 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, 割り込み仮想化、など @katsyoshi ZFSでNASやってはまったこと FreeBSD+ZFSでファイルサーバ ZFS root/ ZFS + Samba ZFSの内部構造とかはしない ZFSとは Sunが開発した次世代ファイルシステム 128bitアドレッシング RAID5, RAID6, Triple Parity 重複排除 暗号化 とりあえず動くOS Solaris FreeBSD 7.0- Linux Native/FUSE ZFS Root壊れたサーバ Memory 512MB * 4 -> 足りない 運用中のサーバ 2GB * 4 -> 原因不明で停止したことがある メモリ足りない場合は loader.confに設定してメモリを節約する それでも落ちる時は落ちる 16GB/32GBくらいは欲しい wiki.freebsd.org/RootOnZFS 構成する全てのdiskにルートパーティションを入れておくと、後で楽 ディスクが壊れたら zfs replace old-disk new-disk 後は寝て待つ @d_kami 自作x86エミュレータの終焉 何が終わるのか x86エミュレータ 何が学べたのか x86の命令セット 世の中にはOSがたくさんある 命令セットを覚えると？ ソースコードを紛失した、仕方ないので続きはバイナリで作ろう バイナリエディタならあるぞ ソースコードは残したくない、バイナリで書くしかない つまり 役に立たない どこではまるのか 同じような命令を作っていて、ちょっとした違いにはまる 命令長 条件分岐に失敗して無限ループ Intelのマニュアルに騙される 3年間で10000行くらい バグが多すぎる 勘違い、Intelの罠 もうやめます それじゃあいつやめるのか、今でしょ いきなりx86はやめるべき 作る前に調べるべき @boronology CD/DVDのエラー計測 DVD -> プリンタブルの糊でメディア同士がくっついてしまう 今回扱う内容 読み込みエラーの計測 ハードウェア的なエラーはまた今度 SANYOチップのPlextorドライブがBEST 前提 ECCというブロックの連続 182*208の2次元配列 20万行くらいエラーが出るのは普通 NGだと1600万くらいになったりする 色素を新規開発したのに、Media IDを使い回したせいで、おかしなことになった 経年劣化 あまり変わらない(5年) DVD焼く時に埃が付いていると、その部分だけエラーの山になるが、特に問題はない 規格的には許容される 多くのドライブは、書き込み中に速度を落として様子をみたりしている DVDなら三菱化学メディアの8倍速 CDなら太陽誘電 そんなことよりバックアップ多重化したほうがいい プレス版のDVD-ROMでも10万くらいエラーは出る TDKの超硬は5年保存でも4万くらいだった @sirrow EMC Style 2013 の解説 EMCという会社 EMC Style 2013 EMCによるGangnam Styleのパロディ 2013/01に公開 で、何が言いたいの？ Now everybody scale out down the row! 2013 -> 来年は違う？ スケールアウトが大切だ、というのは今だけ？ @Talos208 フォントとカーネル／VMのあやしい関係 フォントって何？ 文字をデバイスに表示する時に表示するデータ 文字コードとグリフの対応表 一対一対応とは限らない 縦書きと横書き 合字 グリフ 図形としての文字 本来アプリケーション層のもののはず CFFのフォントに脆弱性があってJailbreakとか CFFの「命令コード」 OpenTypeフォント AdobeとMicrosoftが策定したフォント形式 基本的にはTrueType、内部テーブルの種類が追加されている CFFテーブル CFFフォントが丸ごと入っている 他のテーブルと情報が重複している PDFにCFFグリフのOpenTypeを埋め込むと、CFFの部分だけ使われたりする CFFフォントの構造 CharaStringINDEX .notdefCharString, A CharString CharString命令表 callsubr return escape dup each index rollといった命令 まっとうな2スタックのスタックマシン もうVMだよね VM相当とはいえかなり制限されている メモリアクセス、IO操作などは出来ない Windows OSごと落ちるフォントを作ろうとしたが、詳細を忘れてしまって、次の機会 @hktechno 自作コンピューターでなんかする(仮) 発表をFPGAボードで行います！ ハードウェア担当は@cpu_labs 自作コンピュータ != 自作PC 命令セット MMU IOコントローラ 全部作る mist32アーキテクチャ アウトオブオーダー実行 独自の命令セット ハードウェアとソフトウェアの強調動作 MIST1032ISA / MIST1032SA ソフトウェア gccはやめた方が良い -> llvm binutilsは仕方ない mrubyを載せたい UART(シリアル)ついてる とりあえずコンパイル出来れば動くらしい これから Out of Orderコアを動かす MMUや割り込み・IO周りのテスト ベンチマークを取る SDカード対応 DMA対応 @mhiramat Intel SDMのopcode mapから作るディスアセンブラ in kernel kprobes/ftrace/perftoolsとかのメンテナの一人 # cat debug/x86/disassembly 現在走っているカーネルのメモリを指定した関数名でダンプして、逆アセンブルする 背景 kprobesのデバッグ -> 自己書換コードの様子が知りたい 簡単にメモリ上のバイナリをデコードしたい 既存のものはどれもオレオレフォーマットで出力するものばかり SDMのAppendix A Opcode Map Intel Officialなinstructionのエンコード表記 -> arch/x86/lib/x86-opcode-map.txt 実装したもの x86命令デコーダ x64, AVXにも対応 Intel形式と、AT&T形式の両対応 debugfs, kdb, toolsの三つの使い方が可能 Kconfig CONFIG_X86_DISASSEMBLE Oopsでcodeの欄が既にdisassemble済で出てくる @naota344 野良ビルドからみたGentoo build process unpack patch ./configure make (make test) make install unpack 特に注目するようなところはない Gentooにはunpackというコマンドが用意されている ./configure econfを打つだけで、様々なオプションをつけてconfigureしてくれる --disable-dependency-tracking automakeの機能であるコードの依存チェックを無効化する --disable-silent-rules CC fooとかLD fooとかに省略されてしまうのを無効化 デバッグに不便なので patch /etc/portage/patches で管理される パッチの紛失を防げる makeの落とし穴 Makefileがおかしい "cd hoge; make"とか書いてある CFLAGS, LDFLAGSが反映されない gccを直接読んでいる リンクがおかしい こっそり出ているエラー command not found file does not exist make対策 ビルドログの監視 frecord-gcc-switches .GCC.command.line section CFLAGSなどのチェック --hash-style=gnu ld.goldを使う build log監視 command not found以外にも gccの警告 strict aliasing int X; float *Y; X = 1; *Y = 3.14; printf("%ld\n", X); underlinking 1/2 --as-neededをつけるとリンクが通らなくなる underlinking 2/2 make installの落とし穴 rootで実行される 突然 rm -r /usrされたり インストールしたバイナリがやばいかも RUNPATH, TEXTREL, EXECSTACKが変な値になっている DT_NEEDED SONAMEが抜けてる world writableにsetuid debug情報が付いたまま 他にも 容量がとても必要があるもの /usrとか/varとかがあふれる メモリ不足 gccのバージョン・カーネルの設定チェック ブラウザでGentoo体験 bit.ly/9VG7xz @iorivur DragonFly BSD's Hypervisor vkernel What's DragonFly BSD HAMMER file system だけじゃない！ vkernelのはなし カーネルをユーザランドで動かす機構 カーネルのデバッグが主眼 make pkg-create git gc --agressiveが後ろで走って壊れる vkernel専用のカーネルをmakeする必要がある make worldなどなど ホストからは一つのプロセスに見える 通常のプロセスと同じように、gdbでアタッチしてbreakpointとか設置出来る valgrindが動くと嬉しい @syuu1228 MMIO ON VT-X エミュレーションの種類 ゲストOSの全命令をソフトウェアエミュレーション -> 遅い vt-x以前: 実行されると困る命令だけを動的に置き換えて、ネイティブに実行 Binary Translation vt-x後: CPUをゲストモードへ切り替え、ゲストOSのプログラムをネイティブに実行 置き換える必要がない 本来は、ハイパーバイザーはCPU命令の置き換えはしないはずなのに……？ 命令エミュレーションをしている部分がある！ VT-xなハイパーバイザーのライフサイクル ホストOSのカーネルからゲストモードへ (VMEntry) ハードウェアへのアクセスなど、ハイパーバイザーの介入が必要になったら、ゲストモードを停止し、ホストOSへ戻る (VMExit) 終わったら再開する IO命令によるVMExit Exit Qualification アクセスサイズ In/Outの方向 String命令か？ REP prefix etc... Exit Qualificationの情報に用いてIO命令をエミュレーション出来る Exit Qualificationを見ればどうすればいいか分かる MMIOによるVMExit MMIOは通常のメモリアクセスと同じ命令を用いる IO命令と違って命令で判別してVMExit出来ない アクセスしたアドレスで判別可能 MMIO領域に相当するページにアクセスした時にVMExit(EPT violation)が起きるようにEPTを設定 read/writeともに拒否 MMIOでのVMExit時に得られる情報 どの種類のアクセス権違反か ページに設定された権限 ゲストOSがアクセスしたアドレス(論理・物理) アクセスがread/writeどちらかは分かる 書き込み元・読み込み先の情報(アドレス・レジスタ)と、アクセス幅が分からない どんな命令が実行されたのか分からない メモリアクセスする命令はx86だとかなりある 情報が足りない状態でMMIOするには ゲストEIPの指すアドレスの命令をデコードして、opcode/oprandを取得 オペコード通りの動作をエミュレーション これって命令エミュレーション！ なんでこうなっているのか x86にはメモリアクセスする命令がとても多い そもそもEPT violationはページのアクセス権限エラーを知らせるVMExitであって、MMIOを知らせるものではない 頻繁にMMIOされるとパフォーマンス的に不利 Local APIC仮想化支援 Local APICは割り込み周りで頻繁にアクセスされるが、MMIOを使っており準仮想化にもなじみづらいデバイス この領域のMMIOだけはVT-xが特別扱いされている レジスタ・条件によってはVMExit自体省略 Coaleseed MMIO MMIO領域には、読み書きによる副作用が無く、単純なメモリの読み書きに置き換えられる部分が存在 VGAボードのピクセルデータの領域とか VMExitしたらカーネル内で命令エミュレーションを実行、メモリ読み書き ユーザランドでのデバイスエミュレーションを省略 e1000のパフォーマンスが9.7%向上 まとめ ハードウェア仮想化支援機構であっても、全部やってくれるわけではない 出来ない部分はソフトウェアでやらないといけない Q/A Exit Qualificationで得られるアドレスは実は正確ではない 例えば、ページフォルトの例では、境界をまたいでアクセスした際に、 実際にアクセスを開始したアドレスではなくて、禁止されているアドレスのみが 渡されるので、それを使ってエミュレーションするのは危険 @yogata TELNETの話 telnet ネットワークエンジニアの基本コマンド 「telnetも知らないんですかー？」 TELNETは暗号化出来る(結論) TELNETとは？ RFC854 Network Virtual Terminalを作ること コードセットは7bit USASCII, 標準制御機構 セッション確立時にオプション交換をする ターミナルとプロセスで表示内容を同期させること TELNETネゴシエーション もしかしてネゴシエーションで暗号化出来るのでは？ RFC2946で定義されている TELNETコマンドコード 38 TELNETのキャプチャを見る 結論 TELNETでも暗号化出来る telnetはソースルーティングするパケットを作れる