_1130520

新宿→市ヶ谷→豊洲経路で。途中、新富町でたくさん降りる人がいたがなにかあるのかな。はじめての豊洲。だだっぴろいところに高層ビルが林立してる感じ。

_1130502_1130504

芝浦工大の教室棟のエスカレータを登って会場へ。すでに講義がはじまってる。ガラス張りなので中はまるみえだ。みんなまじめに聞いてるように見える。さすが朝から勉強するやつらは違うぜ、と自分が学生だったころを思いだしながら。

_1130509

10:00-10:10
[2013-12-06 10:01]_1130511

オープニング

  • 開催趣旨 前回と同じ
  • bitvisorを題材とした低レイヤーの交流をはかる。
  • 一般発表者が筑波に偏ってる?
  • 発表登録にスパムが来たらしい。
  • 企業からの参加が減っている。夏にミニサミットとか土日開催とか。
10:10-10:40

「BitVisorの現状と今後」/ 品川高廣(東京大学)

BitVisor はSingle-VMというユニークな特徴を活かして、通常のハイパー

バイザとは異なる様々な目的を実現するための汎用プラットフォームとし

て活用されることを目指しています。本発表では、まず BitVisor の現在

のアーキテクチャの概要を説明し、次に BitVisor を活用した研究や開発

をいくつか紹介します。また、BitVisor の今後の方向性についてもお話

します。

[2013-12-06 10:07]
  • 去年のスライドをみたけど、あまり変化がない...
  • 2006年開始 もう7年 年1回リリースしてきた 1.4はちょっと遅れてる
  • もともとはSecureVMのためにBitVisorはつくられたが、汎用な方向にむかっている。
  • H22から資金が途絶えたがH25に
    • 総務省から「広域分散ベアメタル・クラウド環境のためのハイパーバイザーの開発」
    • JST A-STEP 「高セキュリティ・高信頼のクラウドコンピューティング環境実現に...」
    • あと3年は続く
  • BitVisorとは -- A Single-VM Lightweight Hypervisor (でもTiniVisor..)
  • BitVisor Tシャツもあるよ (学生さんがつくった)
  • singleのメリット
    • セキュリティ: OSよりもVMの方がシンプルなので破られにくいはず
    • 互換性: ゲストOSをいじらずに機能追加
    • VMMを小さくできる(→セキュリティ・オーバヘッド)
    • でも他のVM(non-single)も最適化をがんばってるので負けるケースもないわけではない...
  • 準パススルー型が特徴
    • 基本はパススルー 部分的に仮想化
    • デバイスメディエータ
      • 中継・フィルタ
      • 準パススルードライバとも
      • デバイスドライバの1/5〜1/10のサイズで実装できるメリット
    • 保護ドメイン(sandbox)で動かすのでアタックされても安心
    • 応用: IDS(侵入検知)とか iMacのスケジュール起動
  • iMacのスケジュール起動問題
    • windowsからシャットダウンすると使えない(windowsの仕様で、BIOS的には未定義)
    • 最後にwindowsでシャットダウンすると機能しない問題。
    • windowsのデバイスドライバでは回避できない
    • BitVisorでIOポートを監視して電源OFFのときにスケジュール起動をつっこむ。VMをつかうのはややオーバースペックなかんじだが。
  • VMMにVMEXITで制御がもどってくる条件のon/offをAPIで簡単にできるようにしたい devirtualization
  • 準パススルーのレベル
    • 監視のみ(IDS,デバッグ(アナライザは高い))
    • 監視+変換(暗号化,RAID,SSDの遅延書込)
    • 多重化[Piggyback](ICカードアクセス、OSのアクセスにのっかってなにかする)
      • DMAシャドウイングとか
  • 世界の研究: TCVisor, HyperSafe, "Return-less"VMM
  • 2012年のrefer: 62件 → 2013年のrefer: 87件
    • われわれの論文はなかなか通らない...
  • BitVisor1.4
    • リリースは技術的ではない理由で遅れていた
    • UEFI対応
    • オーバヘッド削減 (タイマーアクセス・スレッドスケジューリング・外部割り込み)
    • タイマーアクセス
      • IOは遅い ACPI PMTをつかっていた
      • TSCは安定しないものがあって採用してなかった
      • invariant TSCに対応したCPUではこれを使うように
    • スレッドスケジューリング
      • 無条件に動いていた タイマーをつかってなくても
    • 外部割り込み
      • 毎回VMExitしていた
      • 外部割り込みをフックしないと長時間制御がとれないことも
      • preemption timerでCPUクロック単位でVMExitができるようになった
    • netperfでためしてみると効果あり
[2013-12-06 10:40]
  • Q: iMacスケジュール起動問題でmacのときは?
  • A: windowsのときだけbitvisorを起動する
  • Q: preemption timerはVMMの中でつかえる?
  • A: ゲストから戻るためのタイマーなので保護ドメインのプロセスをプリエンプトするのにはつかえない
[2013-12-06 10:43]
10:40-10:50

休憩(10分)

10:50-11:50

【招待講演】「TinyVisorの開発と設計」/ 渡辺祐一_1130516_1130517

TinyVisorは、OSを二個動作させることが可能な、BitVisorベースのハイ

パーバイザです。CPU、メモリ、I/Oなどのリソースを各OSに割り当て、OS

が直接制御することで、ホストOSなしで各OSが独立動作します。割り当て

られたリソースのみをOSに認識させ、かつ、割り当てられていないリソー

スへのアクセスを制限することが設計のポイントです。開発の経緯や今後

の目標、具体的な設計について説明します。

[2013-12-06 10:51]
  • 数年年から趣味で開発 去年公開
  • ホストOSなしに各OSが独立動作
  • ゲストBIOSは seaBIOS(GPL)を使用
  • 使い方: display,keyboard,mouse,video,hdd,hbaカード,nicは二組用意する。それぞれのHDDにOSをインストール。USBメモリにVMMとゲストBIOSをインストール。
  • ここまでは去年にできていた。今年はVM1(2つめの方)をリブートできるように。
  • VM0の再起動はホストのBIOSを再起動する必要があって難しい。
  • VMの独立性向上: 片方がパニックしてもまきこまれないようにしたい。
  • VMMの部分アップデート: 片方づつVMMを更新できるようにしたい
  • 夫婦でパソコンを共用? 喧嘩しても隣あわせ
  • 重複するCPU,memory,IO:
    • CPUはマルチコア・ハイパースレッディング
    • メモリたっぷり
    • IOはチップセットのAHCIとマザーボード、USB3とUSB2、PITとHPET
    • けっこう二重にもってる
    • root port (PCI-exのスロット単位)で資源割り当て
  • APIC IDでプロセッサ識別
  • MADTテーブル書き換え: VM0はVM1の論理プロセッサストラクチャを無効化
  • IPI: 指定ならパススルー、ブロードキャストなら割り当てたプロセッサに変換
  • 論理ディスティネーションモード(local APIC ID)・物理ディスティネーションモード(APIC ID)
    • VM1は物理〜しかつかえないようにする。ACPI FADTのフラグで指定。local apic idが重複してしまうため。
  • メモリは4KB単位で物理アドレス範囲指定。
  • VM0の物理はホストとおなじ reservedで
  • IOはバス・デバイス・ファンクションIDで指定
    • 他のVMへのアクセスは、readはall FF、writeは無効化
    • rootから先はOSがスキャンする
  • MMIO領域 重複してる
  • マルチファンクションデバイス
    • OSはファンクション0がないと1以降を検出してくれない 0があれば歯抜けでもok。
  • IOデバイスからメモリは VT-d のIOMMUで。
  • 割り込み: VM0はINTとMSI、VM1はMSIのみ。 PCではIOAPICは1個しかないので。
  • PITはVM0に、HPETはVM1に。VM1でレガシーを要求したらエミュレート
  • USBメモリのVMMをロード→INT 18Hでブート失敗したことに→VM0がロードされる(ホストBIOSの挙動) 他の方法もあるが
  • VMMロード時にゲストBIOSをロードする
  • SeaBIOS: C言語 VMMにあわせてカスタマイズしている BIOSの中に問題があってもソースがみれるメリットがある
  • シリアルをポーリング 。。。 sttyプロセス 。。。
  • 設計のポイント
    • 割り当てあられたリソースのみをOSに認識させる
    • 割り当てられてないリソースへのアクセスを制限する
    • ホストBIOSでVM0、ゲストBIOSでVM1
[2013-12-06 11:41]
  • Q: bitvisor意外で参考にしたものは?
  • A: ない (Q:岡山大のMINTで似たようなこと(リソース分割)をやってたので)
  • Q: デバッグツール
  • A: printfデバッグのみ
  • Q: 2個用意しなくても簡単に多重化できるものはないか?
  • A: IOデバイスの仮想化はたいへんなのでやるつもりない。現状35k lineで、あまりおおきくしたくない。
  • Q: 本業は?
  • A: ふつうのソフトウェア開発(もうちょっと上のレイヤ)。
  • Q: 3つ以上に増やすにはハードを用意するしかない?
  • A: OS間で共有できる機能があるハードもあるし、まだ数に余裕があるデバイスもあるし。
  • VM1でwindowsを動かすのはたぶんたいへん。BIOSまでしか対応してない。VM0はなんとかなるかもしれない。
  • Q: 性能は?
  • A: VM0とVM1で体感では性能差はないかんじ。ビデオゲームとか片方が他方にひっぱられるかもしれないが、マウスが動いたら満足しちゃうので。
  • Q: どうやって勉強したか?
  • A: 仕様書を読んで。BIOSはネットで。すいすい読めるようになった。
  • Q: bitvisorの改造しやすさは?
  • A: globalをつかって読むには困らなかった。
[2013-12-06 11:54]

11:50-13:00 昼休み

生協食堂でランチ。チキンおろしだれ(290)、麦飯?ライス中200g(90)、豆腐とわかめの味噌汁(30)、ほうれん草のゴマあえ(50)。suicaで支払い。以外とICカード払いのレーンは空いてるようにみえた。

_1130519

生協購買でコーヒー買って時間まで外でのんびり。

_1130521

13:00-13:30 デモ・セッション

_1130530

  • スリープするとbitvisorが検出してOSを切り替える。
  • XPを動かしておきたい需要はあるがセキュリティを考えると社内ネットワークには繋ぎたくないとか、XPでしか使えないデバイスがあるとか。
  • 1つ目のOSを立ち上げてスリープするとイメージをディスクに書き出してから2つ目のOSを立ち上げる。2つ目のOSをスリープすると1つ目のOSがディスクから読み込まれ、そのあとはメモリに常駐して切り替えが行われる。
  • 切り替え時のデバイスリセットはOSまかせなのでbitvisorは何もする必要がない。

_1130531

  • OSvのようなコンテナ仮想化とは途中のレイヤを抜いて軽くするという点は同じだが、目的が違うので共存できる。逆にKVMとかは廃れるのではないか?
  • 転送はUDP。

_1130532

13:30-14:30

【招待講演】「BitVisorのUEFI対応」/ 榮樂英樹(株式会社イーゲル)_1130526

BitVisorはバージョン1.3までUEFIに対応していませんでした。しかし、

UEFI対応PCは増加しており、近年はプリインストールされたオペレーティ

ングシステムもUEFIで起動するのが一般的になってきました。そこで、

UEFIでBitVisorを起動できるようにする対応を行いました。UEFI対応にあ

たり、ファームウェアの実装の違いによって発生する多くの問題が見つか

りました。特に、PCのファームウェアは通常ブラックボックスであり、原

因調査が簡単ではありません。そのような問題と対応方法について紹介し

ます。

[2013-12-06 13:32]
  • UEFI: OSとファームウェアのあいだのインタフェースを埋める仕様 元EFI IA64でつかわれていた。
    • ページ単位のalloc/freeeもある。
    • 不揮発メモリ(setup)へのアクセスも提供される。
    • ファイルシステム(FAT)もある。
    • UEFIアプリケーション: フォーマットはPE。サブシステムはちがって0x0A。relocatableにしておくべし。ABIはMS Windows。
    • エントリポイント: EFI_IMAGE_ENTRY_POINT(ImageHandle, *SystemTable) SystemTableにいろいろサービスが書いてある。
      • Boot Service, Runttime Service, Protocolなどが用意されている。
    • 開発環境:
      • gnu-efi(rEFIでつかわれている) ホストのgccでコンパイル(ELF)して、最後にobjcopyでPEに変換。関数呼出規約が違うので差異はじぶんで吸収する。
      • EDK
      • EDK2: bitvisorではこれをつかったほうがよかったかも。
  • BIOSでの起動方法: gnu gubかvmmローダ(bitvisor同梱のbootloader)。
  • UEFIでの起動:
    • GRUBはExitBootService()を呼ぶ → boot serviceがつかえない → GRUBはつかえない
    • bitvisorをUEFIアプリケーション化: リロケータブルにしないといけないなど、おおがかり
    • VMMローダをつくることに
  • VMMローダ: 最初にVMM(ELF)をロードして起動、そしたらローダは終了、次のOSが起動される。
    • 2 stageに分けた。1stはUEFIappで2ndをロード。2ndは1GB未満のところにロードされる。1GB未満の領域はVMMからみえるメリット。
  • UEFIではグラフィックモードになっていてpanicログをだせない。シルアルはUEFIがついてるマシンは限定される。etherはuefiのと衝突する可能性がある。text output protocolをつかう方法はブートにつかうCPUからしか呼べない。しかもブート中のみ。あとはVRAM直書き。
  • 32bitUEFIには対応してない。あまり環境がおおくないとか、windowsは64bitのみだし、intelのはVMX有効のままページングoffにできないとか。
  • ファームウェアはゲストOS上で実行される。
[2013-12-06 14:21]
  • Q: Windowsがうごかないときの対応は?
  • A: printf。VRAMらしいアドレスのところに書き込んで表示。
  • Q: boot loaderを起動するだけでよいのにUEFIは高機能すぎないか?
  • A: UEFIは16bitをきりしててシンプルになってるメリットはあるが、PEバイナリをつくらないといけないのは敷居が高い。
  • Q: TPM対応は?
  • A: UEFIでは対応してない。たぶんプロトコルが定義されているのではないか?(未調査)
  • Q: bitvisor自体には変更はない?
  • A: フックなど変更はない。
  • Q: MacとWindowsでブートに違いは?
  • A: どちらもおなじ感じ。(1年前、igelはMacのブート部分は知財にしようと思ってたが...あてがはずれた...)
  • Q: Macは低レイヤーはそう違いがないが、高レイヤのプロトコル部分は、Macは古いのを独自拡張しているから、苦労するかも。
  • A: 暗号化ディスクでどうなるか試してない。
  • Q: 1.4リリース予定は?
  • A: 大人の事情で遅れている... クリスマス... どうかなあぁ...
[2013-12-06 14:36]

14:30-14:40 休憩(10分)

14:40-15:10

「BitVisorにおけるゲストOS・保護ドメイン・USB ドングル間の遠隔手続き呼び出し」/ 新城靖、松下正吾(筑波大学)_1130533

BitVisorの保護ドメインは、耐タンパ性のある USB ドングルと同様に、

ゲストOS から隔離されており、機密性が高いコードを実行できる。この

発表では、ゲスト OS から保護ドメインと USB ドングルを利用するため

のメッセージ交換について述べる。

[2013-12-06 14:45]
  • 耐タンパデバイス Rockey6
  • 機密環境 と 通常環境
    • デジタル署名・著作権保護・コード隠しなど
  • 実現レイヤ: マイクロカーネル、VMM、intel SGX(software guard extensions)とか。
    • SGX: 暗号化されたままで実行できる。VMMよりも下のレイヤでやる。
  • 耐タンパデバイスは遅いのでアクセラレータとして機密プログラムを実装。
  • 環境間通信はどうすべきか? → RPCと逆RPC
    • 機密環境・耐タンパデバイスはサーバが普通だがたまにクライアントになりたい。
      • 暗号の委託計算 server-aided computation
      • ストレージとかUIとか
      • でもスリープできない問題。
  • 保護ドメインRPC: int vmmcall_rpc(desc,request,result);
  • msgsendbuf(): allocate_buffer()を毎回呼んでてムダ?
  • 保護ドメインはデバイスIO付きの機密環境としてユニークで耐タンパデバイスと組み合わせるとおもしろい。
[2013-12-06 15:06]
  • Q: 逆RPCはポーリング?
  • A: ポーリングだがRPCのつづきで逆RPCを出すなら無駄なループはない。
  • Q: nestしたら?
  • A: 保護ドメインのプログラムがシングルスレッドならnestしない。
[2013-12-06 15:09]
15:10-15:40

「ケーススタディ:BitVisorにおけるバイナリBLOB USBドライバの利用」/ 北村朋宏(株式会社イーゲル)_1130543

USBドングル製品Rockey6をBitVisorから利用可能にした事例について紹介

します。Rockey6のUSBドライバは、libusbの上で動作するユーザランドプ

ログラムであり、そのライブラリは、ソースコード未公開でした。しかし

、BitVisorはlibusb互換APIを備えており、バイナリBLOBとしてライブラ

リを利用できる可能性がありました。そのため、BitVisorにRockey6ドラ

イバを取り込む実装を試みましたが、その過程において幾つかの問題が生

じ、それらを解決する必要がありました。その内容について解説します。

[2013-12-06 15:10]
  • Rockey6のライブラリはソースコードが公開されていない。
  • Rockey6内部にCPUをもっていて乱数生成などができる。USB1.1のインタラプト転送。
  • API: DIC_File, DIC_Open, DIC_Command DIC_Set, DIC_Close
  • Rockey6の未定義シンボルを解決できればbitvisorにとりこめるはず。
  • bitvisorのlibusb互換実装はある。元はICカードをつかうために実装された。
    • 構造体の定義がちがっていてpagefaultとか。つかってないフィールドは削っていたため。
    • stack guardのカナリアが設定されてないためpagefault。32bit環境だとgsレジスタをつかって干渉するのでライブラリをstackguardなしで提供してもらって解決。n
    • GOT: リンカスクリプトにGOT,PLTが書いてなかった。-fPICなしでライブラリを提供してもらって解決。
    • usb_busses: リンクリストの先頭ポインタ。ライブラリがusb_get_busses()をつかってくれてなかった。
  • usb_device構造体の差異があってpagefault。
  • DIC_Openのデバッグ
    • 関数入口でスタックダンプ
    • あやしい関数をnopでおきかえ (strcpyをnopにしたら動いた)
[2013-12-06 15:34]
  • Q: libusbの実行速度の差異は問題になった?
  • A: ない。ゲストOSがUSBのわりこみを吸い込んでしまう問題があった。bitvisorはUSBのwriteを同期で処理するためにbusy waitしているので、linuxの実装よりも速いかも。
  • Q: バイナリのオプション抜きは?
  • A: メーカにたのんだらあっさりとやってもらえた。
[2013-12-06 15:38]

15:40-15:50 休憩(10分)

15:50-16:20

「BitVisorのためのOSの状態復元機能」/ 河崎雄大(電気通信大学)_1130544

BitVisorのためのOSの状態復元機能を提案する.OSの状態として保存,復

元するものはディスク内にあるデータとメモリ上にあるデータである.ま

た,データの保存,復元のトリガーはユーザが任意のタイミングでゲスト

OS上の特別なプログラムを実行させることによって引かれる.

[2013-12-06 15:50]
  • 暗号化・マルウェア検出・OS復元をOSの外でやる。
  • livewire,VMwatcher, BitVisor
  • 使用例: ゲストOS上でマルウェアを実行して挙動を観察したあと、チェックポイントを復元する。
  • 復元トリガーは VMCALL を呼ぶだけ。
  • チェックポイントではメモリとディスクを保存するがbitvisorでは簡単ではない。
    • メモリは別パーティションに保存。
    • ディスクはメインパーティションと差分パーティションを用意して復元では差分パーティションをすてる。
  • bonnie++
    • まばら状態だと性能が低下している。
  • BitVisor1.3のビルドベンチ
    • 2%程度のオーバヘッド
  • 類似
    • VMware,Hyper-V,KVMにも復元機能があるが、マルウェアがホストOSを検出して動作を止めてしまうかも。
    • BareBox
[2013-12-06 16:13]
  • Q: レジスタは
  • A: VMCSでやる予定
  • Q: バッファキャッシュは?
  • A: メモリごと保存しているのでフラッシュしなくてもok。
  • Q: VMCSをそのままコピペは動かなかったがだいじょうぶか?
  • A: まだ動いてない。(Q:VMCSにはホストの状態もはいっているため動かない)
  • Q: メインと差分と両方のreadのときにどうしてる?
  • A: 今は差分の方はbusy waitして完了をまっている。
  • Q: 2回目にチェックポイントをとったらどうする?
  • A: チェックポイントは1つだけなので。(Q:差分で記録すると差分を捨てるコストは安くなるが、チェックポイントを連続して取るコストは上がってしまう)
[2013-12-06 16:22]
16:20-16:40

「Live Migration on BitVisor」/ 深井貴明,表祐志(筑波大学システム情報工学研究科), 品川高廣(東京大学)_1130545

OS のライブマイグレーションは仮想マシンモニタ(VMM)が提供する機能の

一つであり,ハードウェアの障害対応や負荷分散などに有効な技術である

.しかし,ライブマイグレーション機能を提供するVMMはデバイスを仮想

化し,性能劣化を生む.そこで,デバイスを仮想化しない準パススルー型

VMMであるBitVisorによる,OSのライブマイグレーションを目指し,実装

している.現在,RamDisk上で動作し,一部デバイスのみを用いるLinuxを

マイグレーションすることに成功している.本発表では,ライブマイグレ

ーション機能のうち実装が完了している部分について述べる.

[2013-12-06 16:23]
  • メンテナンス性向上
  • bitvisorでやるメリット: OSに依存しない。オーバヘッドがすくない。
  • ハードウェア構成は同じでないと動かず。
  • メモリとCPUはふつうにコピーすればok
  • デバイスの状態は書き込み専用レジスタがあるためbitvisorで監視する。(めんどくさい)
    • 宛先ポート・IOタイプ・書き込みデータ(ビット) をみて判断。デバイスの状態や直近のIOによっても読み書きがかわる。
    • デバイスごとに状態取得コードを書かないといけない。
  • 応用: チェックポイント・クローン
  • 脱仮想化と再仮想化
    • マイグレーションのときだけ再仮想化してマイグレーションがおわった脱仮想化できたらよい。
[2013-12-06 16:37]
  • Q: すでにライブマイグレーションの実装はあるが?
  • A: bare-metalに近いところでやりたい。checkpointingは需要があるはず。
  • Q: DMAはどうする? (NICとか)
  • A: タイミングをえらんでやるが、bitvisorは割り込みをフックしてないし。
  • Q: デバイスをエミュレートするのは大変なので、いちどデバイスが抜けた(スリープ)ように見せかけるのはだめか?
  • A: OSに気づかれないようにしたい。(Q:ユースケースがほしい)
[2013-12-06 16:43]

16:40-16:50 休憩(10分)

16:50-17:10

「ネットワークによるADvisor機能の拡張」/ 山本航洋(電気通信大学大山研究室)_1130546

現在のBitVisorにはグラフィックハードウェアのメモリを書き換える事に

よりデスクトップ上に画表示させるADvisor機能が実装されている。

ADvisorで表示する画像データはBitVisorのバイナリに埋め込まれている

。そのため表示画像の変更を行うためにはビルドしなおす必要がある。そ

こでBitVisorとサーバで通信する機能を実装し、ADvisorで表示可能な画

像を動的に更新する拡張を行った。

[2013-12-06 16:51]
  • ADvisor: VMMが画像をむりやり表示する。
  • 利用例: 組織内における情報表示、広告表示。
  • 問題点: 画像データはVMMソースコードに埋め込み。 → 動的に変更できるようにした。
  • サーバからUDPで送られてきたデータを捕捉。
    • サーバは送るデータの大きさを伝えてから画像を分割して送信。
  • サーバ側でMTUを考慮して小さく送る。
  • CR3レジスタの更新をタイミングで画像がそろっているか確認(あんまりよくない)
  • 表示タイミング: ディスクやネットワーク中の文字列マッチングなど
  • テキストをサーバで画像化して表示など(マルチバイトもいける)
[2013-12-06 17:07]
  • Q: 認証とか?
  • A: UDPで送りつけると表示。表示中はパケット破棄している。
  • Q: HTTPパケットすべてをスキャンするコストは?
  • A: ポート80に制限しているが、性能測定はしてない。フラグメントして文字列が切れたら検出できない。
  • Q: パケットドロップしたら?
  • A: 表示されない。
  • Q: ちらついていたが?
  • A: 録画のつごうではないか?
[2013-12-06 17:11]
17:10:17:30

「TCP/IP on BitVisor」 / 表祐志,島田恭平,芹川大地,深井貴明(筑波大学システム情報工学研究科)_1130550

現在のBitVisorには汎用的なTCP通信機能は実装されていない.そこでオ

ープンソースの軽量 TCP/IP スタックであるlwIP (Lightweight TCP/IP

Stack)をBitVisorに移植し,TCP及び一部の上位層プロトコルによる汎用

的な通信機能を実装した.本発表では今回実装した通信機能を利用するた

めの基本的なAPIの使い方と,BitVisorサーバやクラウドサービスとの連

携といった応用例を,デモを交えながら説明する.

[2013-12-06 17:12]
  • 設定をリモートから変更したい・情報をつかわせたい・クラウドサービスと連携したい
  • フルスクラッチで書くか・移植するか?
  • フルスクラッチでCで4000行?
  • stackoverflowできくとlwIP(lightweight IP)がいいらしい。品川先生もおすすめ。
    • 3項BSDライセンス
    • プラットホーム側ですべて用意しなくても、それなりに動く。
    • ドキュメントが整備されてない、Makefileもない。
    • Raw API: もっとも低級。イベントドリブン。
  • サーバ: BitVisor HTTP Serverを実装してみた。
  • クライアント: cURL Visorを実装してみた。
  • TwitVisor改: クラウドサービスと連携できた。大きなタイムラインでもok。
  • FlickVisor: screenshotをとってflickrに送りつける。大きな画像でもok。
  • bitbucketで公開中
[2013-12-06 17:25]
  • Q: SSLは?
  • A: Raw APIでつなげられれば。
  • Q: bitvisor1.4にいれてもよい?
  • A: welcome!
  • Q: UDPのコードとは?
  • A: まったく共有してない。
  • Q: より便利なAPIをつかえるようにするには?
  • A: mutex,thread,timerが必要。再送はAPIを呼ぶ側が時間コントロールしてる。
[2013-12-06 17:29]

_1130551

帰り際に榮樂さんと松原さんに挨拶して帰社。そとはまっくら。豊洲駅までイルミネーションと月がきれいだったので写真をとりながら。

_1130552_1130559_1130572_1130585