source: lab.git/Commentary/kernelvm/20130413.log

Last change on this file was aa2cedc, checked in by mitty <mitty@…>, 12 years ago
  • memo for 8th Kernel/VM expedition
  • add LT sessions

git-svn-id: https://lab.mitty.jp/svn/lab/trunk@210 7d2118f6-f56c-43e7-95a2-4bb3031d96e7

  • Property mode set to 100644
File size: 32.8 KB
Line 
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
297FUSION-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林佳寛
419QEMUと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
488@katsyoshi
489ZFSでNASやってはまったこと
490    FreeBSD+ZFSでファイルサーバ
491        ZFS root/ ZFS + Samba
492        ZFSの内部構造とかはしない
493    ZFSとは
494        Sunが開発した次世代ファイルシステム
495        128bitアドレッシング
496        RAID5, RAID6, Triple Parity
497        重複排除
498        暗号化
499    とりあえず動くOS
500        Solaris
501        FreeBSD 7.0-
502        Linux Native/FUSE
503    ZFS Root壊れたサーバ
504        Memory 512MB * 4 -> 足りない
505    運用中のサーバ
506        2GB * 4 -> 原因不明で停止したことがある
507    メモリ足りない場合は
508        loader.confに設定してメモリを節約する
509        それでも落ちる時は落ちる
510        16GB/32GBくらいは欲しい
511    wiki.freebsd.org/RootOnZFS
512        構成する全てのdiskにルートパーティションを入れておくと、後で楽
513    ディスクが壊れたら
514        zfs replace old-disk new-disk
515        後は寝て待つ
516
517@d_kami
518自作x86エミュレータの終焉
519    何が終わるのか
520        x86エミュレータ
521    何が学べたのか
522        x86の命令セット
523        世の中にはOSがたくさんある
524    命令セットを覚えると?
525        ソースコードを紛失した、仕方ないので続きはバイナリで作ろう
526        バイナリエディタならあるぞ
527        ソースコードは残したくない、バイナリで書くしかない
528    つまり
529        役に立たない
530    どこではまるのか
531        同じような命令を作っていて、ちょっとした違いにはまる
532            命令長
533        条件分岐に失敗して無限ループ
534        Intelのマニュアルに騙される
535    3年間で10000行くらい
536    バグが多すぎる
537        勘違い、Intelの罠
538    もうやめます
539        それじゃあいつやめるのか、今でしょ
540    いきなりx86はやめるべき
541    作る前に調べるべき
542
543@boronology
544CD/DVDのエラー計測
545    DVD -> プリンタブルの糊でメディア同士がくっついてしまう
546    今回扱う内容
547        読み込みエラーの計測
548        ハードウェア的なエラーはまた今度
549    SANYOチップのPlextorドライブがBEST
550    前提
551        ECCというブロックの連続
552        182*208の2次元配列
553    20万行くらいエラーが出るのは普通
554    NGだと1600万くらいになったりする
555        色素を新規開発したのに、Media IDを使い回したせいで、おかしなことになった
556    経年劣化
557        あまり変わらない(5年)
558    DVD焼く時に埃が付いていると、その部分だけエラーの山になるが、特に問題はない
559        規格的には許容される
560    多くのドライブは、書き込み中に速度を落として様子をみたりしている
561    DVDなら三菱化学メディアの8倍速
562    CDなら太陽誘電
563    そんなことよりバックアップ多重化したほうがいい
564    プレス版のDVD-ROMでも10万くらいエラーは出る
565    TDKの超硬は5年保存でも4万くらいだった
566
567@sirrow
568EMC Style 2013 の解説
569    EMCという会社
570    EMC Style 2013
571        EMCによるGangnam Styleのパロディ
572        2013/01に公開
573    で、何が言いたいの?
574        Now everybody scale out down the row!
575        2013 -> 来年は違う?
576        スケールアウトが大切だ、というのは今だけ?
577
578@Talos208
579フォントとカーネル/VMのあやしい関係
580    フォントって何?
581        文字をデバイスに表示する時に表示するデータ
582        文字コードとグリフの対応表
583        一対一対応とは限らない
584            縦書きと横書き
585            合字
586        グリフ
587            図形としての文字
588    本来アプリケーション層のもののはず
589    CFFのフォントに脆弱性があってJailbreakとか
590        CFFの「命令コード」
591    OpenTypeフォント
592        AdobeとMicrosoftが策定したフォント形式
593        基本的にはTrueType、内部テーブルの種類が追加されている
594    CFFテーブル
595        CFFフォントが丸ごと入っている
596        他のテーブルと情報が重複している
597        PDFにCFFグリフのOpenTypeを埋め込むと、CFFの部分だけ使われたりする
598    CFFフォントの構造
599    CharaStringINDEX
600        .notdefCharString, A CharString
601    CharString命令表
602        callsubr
603        return
604        escape
605        dup
606        each index rollといった命令
607        まっとうな2スタックのスタックマシン
608        もうVMだよね
609    VM相当とはいえかなり制限されている
610        メモリアクセス、IO操作などは出来ない
611    Windows OSごと落ちるフォントを作ろうとしたが、詳細を忘れてしまって、次の機会
612
613@hktechno
614自作コンピューターでなんかする(仮)
615    発表をFPGAボードで行います!
616    ハードウェア担当は@cpu_labs
617    自作コンピュータ != 自作PC
618        命令セット
619        MMU
620        IOコントローラ
621        全部作る
622    mist32アーキテクチャ
623        アウトオブオーダー実行
624        独自の命令セット
625        ハードウェアとソフトウェアの強調動作
626    MIST1032ISA / MIST1032SA
627    ソフトウェア
628        gccはやめた方が良い -> llvm
629        binutilsは仕方ない
630    mrubyを載せたい
631    UART(シリアル)ついてる
632    とりあえずコンパイル出来れば動くらしい
633    これから
634        Out of Orderコアを動かす
635        MMUや割り込み・IO周りのテスト
636        ベンチマークを取る
637        SDカード対応
638        DMA対応
639
640@mhiramat
641Intel SDMのopcode mapから作るディスアセンブラ in kernel
642    kprobes/ftrace/perftoolsとかのメンテナの一人
643    # cat debug/x86/disassembly
644        現在走っているカーネルのメモリを指定した関数名でダンプして、逆アセンブルする
645    背景
646        kprobesのデバッグ -> 自己書換コードの様子が知りたい
647        簡単にメモリ上のバイナリをデコードしたい
648        既存のものはどれもオレオレフォーマットで出力するものばかり
649    SDMのAppendix A
650        Opcode Map
651        Intel Officialなinstructionのエンコード表記
652        -> arch/x86/lib/x86-opcode-map.txt
653    実装したもの
654        x86命令デコーダ
655            x64, AVXにも対応
656            Intel形式と、AT&T形式の両対応
657            debugfs, kdb, toolsの三つの使い方が可能
658        Kconfig
659            CONFIG_X86_DISASSEMBLE
660    Oopsでcodeの欄が既にdisassemble済で出てくる
661
662@naota344
663野良ビルドからみたGentoo
664    build process
665        unpack
666        patch
667        ./configure
668        make
669        (make test)
670        make install
671    unpack
672        特に注目するようなところはない
673        Gentooにはunpackというコマンドが用意されている
674    ./configure
675        econfを打つだけで、様々なオプションをつけてconfigureしてくれる
676    --disable-dependency-tracking
677        automakeの機能であるコードの依存チェックを無効化する
678    --disable-silent-rules
679        CC fooとかLD fooとかに省略されてしまうのを無効化
680        デバッグに不便なので
681    patch
682        /etc/portage/patches で管理される
683        パッチの紛失を防げる
684    makeの落とし穴
685        Makefileがおかしい
686            "cd hoge; make"とか書いてある
687            CFLAGS, LDFLAGSが反映されない
688            gccを直接読んでいる
689            リンクがおかしい
690        こっそり出ているエラー
691            command not found
692            file does not exist
693    make対策
694        ビルドログの監視
695        frecord-gcc-switches
696            .GCC.command.line section
697            CFLAGSなどのチェック
698        --hash-style=gnu
699        ld.goldを使う
700    build log監視
701        command not found以外にも
702        gccの警告
703    strict aliasing
704        int X; float *Y;
705        X = 1;
706        *Y = 3.14;
707        printf("%ld\n", X);
708    underlinking 1/2
709        --as-neededをつけるとリンクが通らなくなる
710    underlinking 2/2
711    make installの落とし穴
712        rootで実行される
713            突然 rm -r /usrされたり
714        インストールしたバイナリがやばいかも
715            RUNPATH, TEXTREL, EXECSTACKが変な値になっている
716            DT_NEEDED
717            SONAMEが抜けてる
718            world writableにsetuid
719            debug情報が付いたまま
720    他にも
721        容量がとても必要があるもの
722        /usrとか/varとかがあふれる
723        メモリ不足
724        gccのバージョン・カーネルの設定チェック
725    ブラウザでGentoo体験
726        bit.ly/9VG7xz
727
728@iorivur
729DragonFly BSD's Hypervisor vkernel
730    What's DragonFly BSD
731        HAMMER file system
732        だけじゃない!
733    vkernelのはなし
734        カーネルをユーザランドで動かす機構
735        カーネルのデバッグが主眼
736    make pkg-create
737        git gc --agressiveが後ろで走って壊れる
738    vkernel専用のカーネルをmakeする必要がある
739    make worldなどなど
740    ホストからは一つのプロセスに見える
741        通常のプロセスと同じように、gdbでアタッチしてbreakpointとか設置出来る
742    valgrindが動くと嬉しい
743
744@syuu1228
745MMIO ON VT-X
746    エミュレーションの種類
747        ゲストOSの全命令をソフトウェアエミュレーション -> 遅い
748        vt-x以前: 実行されると困る命令だけを動的に置き換えて、ネイティブに実行
749            Binary Translation
750        vt-x後: CPUをゲストモードへ切り替え、ゲストOSのプログラムをネイティブに実行
751            置き換える必要がない
752    本来は、ハイパーバイザーはCPU命令の置き換えはしないはずなのに……?
753        命令エミュレーションをしている部分がある!
754    VT-xなハイパーバイザーのライフサイクル
755        ホストOSのカーネルからゲストモードへ (VMEntry)
756        ハードウェアへのアクセスなど、ハイパーバイザーの介入が必要になったら、ゲストモードを停止し、ホストOSへ戻る (VMExit)
757        終わったら再開する
758    IO命令によるVMExit
759        Exit Qualification
760        アクセスサイズ
761        In/Outの方向
762        String命令か?
763        REP prefix
764        etc...
765    Exit Qualificationの情報に用いてIO命令をエミュレーション出来る
766        Exit Qualificationを見ればどうすればいいか分かる
767    MMIOによるVMExit
768        MMIOは通常のメモリアクセスと同じ命令を用いる
769        IO命令と違って命令で判別してVMExit出来ない
770        アクセスしたアドレスで判別可能
771        MMIO領域に相当するページにアクセスした時にVMExit(EPT violation)が起きるようにEPTを設定
772            read/writeともに拒否
773    MMIOでのVMExit時に得られる情報
774        どの種類のアクセス権違反か
775        ページに設定された権限
776        ゲストOSがアクセスしたアドレス(論理・物理)
777        アクセスがread/writeどちらかは分かる
778        書き込み元・読み込み先の情報(アドレス・レジスタ)と、アクセス幅が分からない
779        どんな命令が実行されたのか分からない
780        メモリアクセスする命令はx86だとかなりある
781    情報が足りない状態でMMIOするには
782        ゲストEIPの指すアドレスの命令をデコードして、opcode/oprandを取得
783        オペコード通りの動作をエミュレーション
784    これって命令エミュレーション!
785    なんでこうなっているのか
786        x86にはメモリアクセスする命令がとても多い
787        そもそもEPT violationはページのアクセス権限エラーを知らせるVMExitであって、MMIOを知らせるものではない
788    頻繁にMMIOされるとパフォーマンス的に不利
789        Local APIC仮想化支援
790            Local APICは割り込み周りで頻繁にアクセスされるが、MMIOを使っており準仮想化にもなじみづらいデバイス
791        この領域のMMIOだけはVT-xが特別扱いされている
792        レジスタ・条件によってはVMExit自体省略
793    Coaleseed MMIO
794        MMIO領域には、読み書きによる副作用が無く、単純なメモリの読み書きに置き換えられる部分が存在
795        VGAボードのピクセルデータの領域とか
796        VMExitしたらカーネル内で命令エミュレーションを実行、メモリ読み書き
797        ユーザランドでのデバイスエミュレーションを省略
798        e1000のパフォーマンスが9.7%向上
799    まとめ
800        ハードウェア仮想化支援機構であっても、全部やってくれるわけではない
801        出来ない部分はソフトウェアでやらないといけない
802   
803    Q/A
804        Exit Qualificationで得られるアドレスは実は正確ではない
805        例えば、ページフォルトの例では、境界をまたいでアクセスした際に、
806        実際にアクセスを開始したアドレスではなくて、禁止されているアドレスのみが
807        渡されるので、それを使ってエミュレーションするのは危険
808
809@yogata
810TELNETの話
811    telnet
812        ネットワークエンジニアの基本コマンド
813    「telnetも知らないんですかー?」
814    TELNETは暗号化出来る(結論)
815    TELNETとは?
816    RFC854
817        Network Virtual Terminalを作ること
818            コードセットは7bit USASCII, 標準制御機構
819        セッション確立時にオプション交換をする
820        ターミナルとプロセスで表示内容を同期させること
821    TELNETネゴシエーション
822    もしかしてネゴシエーションで暗号化出来るのでは?
823        RFC2946で定義されている
824        TELNETコマンドコード 38
825    TELNETのキャプチャを見る
826    結論
827        TELNETでも暗号化出来る
828    telnetはソースルーティングするパケットを作れる
Note: See TracBrowser for help on using the repository browser.