取りたいイベントをあらかじめOnにして、その後負荷の具合を見ながら調整する
記録する際にロックを取るなどによりメモリ帯域を食ってしまうことはないか
基本的にCPU間でロックを取ることはない(ロックレス)
-
\ No newline at end of file
+
+
+@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はソースルーティングするパケットを作れる
projects / lab.git / blobdiff