Q/A
有名なプロダクト例
日本で市販はされていない
- BluetoothやWiFiとは違い、P2Pが目的なので、コンシューマ向けではない
+ 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