取りたいイベントをあらかじめ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, 割り込み仮想化、など
+
projects / lab.git / blobdiff