sw

いってきた: DNS温泉 番外編(2019年2月)

前日に予習資料に目をとおしておこうとしたのだが、まにあわず。

_1220358x_1220360x

DNS温泉とは

  • DNS温泉: 鈴木先生主催 呑むついでに話す
  • DNS補講: 温泉参加者限定
  • DNS番外編: だれでも

IMG_20190216_114700

[2019-02-16 12:01]

基礎講座 / 鈴木常彦_1220361x

DNS温泉5の資料にもとづいて
  • http://www.e-ontap.com/dns/onsen5
  • DNSの学び方
    • JPRSの本がいちばん正確だが、それでも首をかしげるところも..
    • RFC違反の実装もある
    • RFCもあやしい
    • 自分で考えるしかない
  • RFC1034,1035,2181,2308,8020(3308の訂正),1912(よくあるまちがい集)
  • 自律分散といいつつICANNを頂点とする階層構造
  • DNSにいろんなものをつめこめる → DNS camel
  • ラベルは any binary string (rfc2181) ホスト名は英数とか限定だがドメイン名はなんでもよい
  • ドメイン名は内部表現上で255オクテットまで。
  • RRs=Resource Record set (複数のsじゃなくてsetのs)
  • TTL: how long a RR can be cached. should be discarded.
  • RDATA: owner,type,class
  • QNAME minimizationない伝統的なやりかたならroot zone serverにFQDNで問合せる。
  • stub resolverからfull resolverのあいだは多段になる可能性がある。
  • 誤解するので 再帰問い合わせ→再帰検索要求と大学の授業ではいっている (RD flag=1)
  • full resolver: iterative searchをする。個々の問い合わせは非再帰問い合わせ.(RD=0)
  • 最終回答にはAA bitがたっている。ただし自称AAでしかない。委任されているかどうかが重要。
  • アプリがDNS RRをキャッシュするのはTTLがわからないので危険。でも攻撃を避けるのにdns rebinding攻撃を避けるためにキャッシュすることもある。
  • zoneとはなにか? むつかしい。
  • サブドメインとゾーンのちがい。
    • chukyo-u.ac.jpゾーンの親としてのac.jpゾーンはない(昔はあった)。ac.jpがあってもjと管理者が同じなので意味がない。
  • グルーのはなしは難しいので後半でやるかも。
  • ゾーンの構成物
    • 自分が権威をもつRR
    • 頂点 SOA NS
    • サブゾーン NS
    • サブゾーンNSのA
  • 内部名=下部名 in-bailwick
  • sibling glue
  • recursiveはもともとサーバーのモードのことだった 昔はcache serverとcontents serverが混在してた
  • DNS応答5種類 (djbの分類)
    • CNAME (別名)
    • NXDOMAIN (名前がない)
    • NOERROR (成功)
    • referral (委任)
    • NODATA=(NOERROR+SOA) (名前はあるけどそのタイプはない)

_1220364x

[2019-02-16 13:00]

  • sibling glueとは
    • zone jp.
    • zone example.ne.jp.
      • NS ns.example.ad.jp
    • zone example.ad.jp.
      • NS ns.example.ad.jp
      • ns A 192.0.2.1
  • jpサーバに xx.example.ne.jp の問い合わせがあったときにns.example.ad.jp Aを返すことができる=sibling glue。(jpからみたら内部名。sibling domain)
  • sibling glue <-> strict glue
  • BINDとNSDはsibling glueを返す実装になっている。
  • sibling glue: エセグルーとよんでいる。
  • 例:
    • www.ctc.co.jp. NS ns1.hs.ctc.jp. 外部名 (a.dns.jpが知らない)
    • www.ctc.co.jp. NS ns2.dc.ctc.ad.jp. sibling

[2019-02-16 13:16]

休憩

わざわざ外部名をつかうのはレンタルサーバのIPアドレスが変更になってもだいじょうぶだから、というのがきこえてきた。

[2019-02-16 13:26]

DNS温泉4教材
  • http://www.e-ontap.com/dns/onsen4/
  • 否定応答
  • RFC2308は古い 問題を引き起している
  • QNAMEがCNAMEの指す先まで含むことになっている。BINDの実装を追認するRFCになっている?
  • FORWARDER: もともとfull resolverのこと。proxyのことだけだとおもいがちだが。
  • NXDOMAINなのにanswerにCNAMEがはいっているのはなぜか? contentsとcacheが混在しているか2つのゾーンをもっているか。
  • このRFCにはそもそも正しい(典型的な)NXDOMAINの例が載ってない。
  • NODATA:疑似応答コード. RCODE=NOERRORでanswerに適切なレコードがないことで示す。
  • SOAのMINIMUMフィールドとSOA自身のTTLの小さい方がネガティブキャッシュのTTLになる。
  • dig soa iij.ad.jp.
    • iij.ad.jp. 86500 SOA ... 3600
  • dig wwwwwww.iij.ad.jp @dns0.iij.ad.jp +norec
  • 否定応答ではSOAのTTLはSOAのTTLとminttlの小さい方にセットされるべき。
  • もし小さい値にセットしない実装があった場合、クライアント側が小さい方を選ばないといけない。
  • 古い実装でNXDOMAINのときに上位のNSを返してくるものがある。example.jp.がjp. NSを返してくるとか。そんなものは信用でいない。簡単に毒入れできてしまう。
  • server failure: 設定がおかしいときはだまりこむのがいいとおもう(鈴木)。
  • server failureはTTLが提供されないにもかかわらずネガティブキャッシュしてよいと書いてある。このRFCおかしい。
  • キャッシュサーバはSOAをちゃんと返す。
  • RFC2308のおかしいところがRFC8020でやっと訂正された。
  • タイトル: NXDOMAIN: There Really Is Nothing Underneath
  • nom.のしたにsub.example.nom.があるけどexample.nom.がない、という場合がある(最近はかなり減った)
  • pseudoの発音は「スド」
  • NXDOMAINがかえってきたら、その下はすべて存在しないと扱ってよい。RFC2308を訂正して、もともとRFC1034にもどった。
  • 利益: QNAME minimizationのときに役だつ。
  • dig ns aws.amazon.com
  • dig aws.amazon.com @...amazon.com +norec
  • CNAMEがかえってくる
  • キャッシュサーバにきくとCNAMEチェインをたどってAまでかえしてくれる。
  • RFC的にはかえすのはおかしい。
  • dig com.cdn.amazon.com は権威サーバにといあわせるとNXDOMAINがかえってくるけど、その下にドメインはある。amazonはがんばって撲滅しようとしていらしいが... お客さん向けのはなおしたが、自分達用のはまだ残っている。
  • unboundでqname-minimisation: yes + qname-minimisation-strict:yes にしてみると、ひけなくなる。
  • www.chuko-u.ac.jpのNSがxxx.elb.amazonawx.com.になっているのでこまった。
  • elb.amazonawx.com. TXT を置くようにした。実装はいじらずに。

[2019-02-16 14:30]

  • cache-min-ttl おおきくしすぎると浸透しなくなる
  • cache-max-ttl メモリ使用量とのかねあいか?
  • TTL 0はキャッシュするなという意味。
  • TTLみじかすぎるとcache poisoningによわい。
  • TTLの推奨値はRFCにはない。
  • kantei.go.jp. はTTL 300 にしている(たぶんDoSくらったときに逃げられるように)がjpのサーバは86400をかえしてくる。
  • DNS温泉番外編2016でくわしくやった。
  • cache serverはcontents serverのTTLを減算していった値をSOAでstubに返すが、maxできりつめた値を返すかどうかは実装しだい。RFCにはそこまでかいてない。
  • BINDで孫ゾーンをつくれば子ゾーンをNXDOMAINにできるかも。ゾーン共存サーバの場合。

[2019-02-16 14:51]

休憩

IMG_20190216_145301IMG_20190216_170815

[2019-02-16 15:05]

RFC5155補足資料 / こやね @xkoyane_1220366x

  • DNSSEC: RFC4033,4034,4035で規定、キャッシュポイズニング対策
  • レコード: RRSIG(RRのsign),DNSKEY(pubkey),DS(KSK pubkey hash;上位ゾーンに登録する),NSEC3(ゾーンに存在するレコードをしめすもの)
  • ZSK: zone signing key, RRを署名するもの
  • KSK: key signning key, ZSKを署名するもの
  • ZSKだけで構築すると、鍵長を長くすると応答が大きくなってよくない。鍵を更新するときの手間がかかる。
  • KSKは鍵長をながくして、ZSKは小さくする。
  • ルートの公開鍵はcache serverからもってくるか、公開されているものをもってくる。
  • (KSKロールオーバのはなしは省略)
  • rfc5155: ゾーン列挙をむつかしくする。
  • NSECレコードをつかった場合はNSECチェーンをたどってゾーンの名前を列挙できてしまう。
  • NSEC3レコード: 名前をハッシュ化する
  • secure delegation: NSのほかにDSもある移譲
  • insecure delegation: NSだけ。
  • ENT: empty non-terminal. レコードがないけどサブドメインがあるもの.
  • .example. IN NSEC3 1 MX RRSIG
  • flag=1はOpt-Outを意味する。
  • hash = base32_rfc4648((sha1**iterations)(domain_nameの内部表現 + salt))
  • ハッシュをもとめるツール: nsec3hash(ISC), ldns-nsec3-hash(NLnet Labs)
  • ハッシュ整列順: ハッシュ値でソート
  • 不存在証明
  • dig a.c.x.wexample. @example.koyane.net +norec
  • closerXXXX name
  • dig a.c.x.w.example. @example.koyane.net +norec
  • next closerXXXX name
  • ワイルドカード
  • 最近接名 closest encloser
  • Q: dns cookieとかqnameのhashをつかわずにnsec3のようなふくざつなものをつかうりゆうは?
  • A: 動的に署名するのを避けた(パフォーマンス)。キャッシュサーバの容量節約(範囲でネガティブキャッシュできるとうれしい)。 CDNで肯定応答を動的に署名しているものがあるらしい。
  • Q: ラベルはany binaryということだったが、正規化はどうしてる?
  • A: たぶんそのまま。英字は小文字にするとおもう。
  • Q: cloud flareでrfc4470 NSECをかえしてきたが、なにかわかる?
  • A: わからん。
  • opt-out: insecure delegationのやつはNSEC3の生成を省略する。
  • opt-out=1だとNSEC3で署名されてないかもしれないことを示す。
  • ENTは省略
  • Q: sha1なのはなぜ?
  • A: rfc5155に書いてあるから。長いのはいやだ。NSEC3のフィールドにアルゴリズムは書いてある。あまり強くする必要もない。saltもiterationsも公開されてるし。辞書をつくりにくくするだけ。djbが辞書ツールを公開している。

[2019-02-16 15:56]

第一フラグメント便乗攻撃(アイコラ攻撃) / こやね @xkoyane

  • http://www.convivial.ne.jp/dns/extra2019/aikora.pdf
  • IPフラグメントのリアセンブル処理を悪用したもの。
  • IDがでた。藤原さん https://tools.ietf.org/html/draft-fujiwara-dnsop-fragment-attack-00
  • 権威サーバに偽装した2ndフラグメントをリゾルバおくりつけておく。
  • EDNSでメッセージサイズが大きくできるようになった。
  • EDNSはDNSSECとIPv6では必須
  • unboundはDOビットをつねにセットして要求してくる。(RRSIGかえってきても検証しないならむだになるのに)
  • フラグメントされると: source port random, ID random,が無効になる
  • UDPチェックサム
    • チェックサムは毎回変化するが、応答内容とフラグメントする位置が固定なら事前に偽造2ndフラグメントをつくっておける。
    • 2バイトあればチェックサムは調整できる。4バイトのTTLがつかいやすい。パディングオプションもつかえる。
  • あんがいフラグメントするほどメッセージを大きくするのはむつかしい。
  • 権威サーバに対して Path MTU discoveryをつっこむのが簡単。ICMP echoをおくりつけたあとICMPをおくる。
  • PMTUDのキャッシュ時間はlinuxだと10分。
  • 2ndフラグメントのチェックサムがあわないようにして権威サーバをつかえなくさせる攻撃もありえる。
  • RRSIGをNSに差し替える攻撃: 否定応答を差し替える攻撃になる。
  • オープンレゾルバ 9.9.9.9 はこの攻撃に脆弱
  • (ついてくのつらい)
  • record rankkingが高いのを偽装できるとよりよい。

[2019-02-16 16:25]

ドメインハイジャックのデモ (公開不可)

[2019-02-16 16:36]

  • 対策
    • EDNSを512バイトにする
    • TCPフォールバック
    • 検証しないときはDO=0で
    • xxx
    • フラグメントUDPはうけとらない。
    • xxxx

[2019-02-16 16:39]

  • Q: path mtu discoveryをブロックする対策は実際にはむつかしいのでは? 他のUDPをつかうアプリへの影響があるので。
  • A: 権威サーバで対策するだけなので、権威サーバとアプリサーバを兼用しなければok
  • Q: TCPだと?
  • A: UDPよりは困難になるがMITMの可能性もあるし。
  • 藤原さんのI-DだとMTU 1220(IPv6のmin)を推奨している。1220より短かいMTUは攻撃だとみなすということで。

[2019-02-16 16:44]

Fuzzing DNS Full-Resolvers. / 坂口俊文 @siskrn_1220367x

  • fuzzing: へんなデータをおくって挙動をみる
  • 権威サーバを自作+改造して応答をランダムに変える。
  • データを書き換えたり、メッセージをエンコードしたあとに書き換えたり。
  • スタブリゾルバも自作 ランダムな問い合わせをする。

[2019-02-16 17:00]

[2019-02-16 17:03]

Route53で親子同居 / @otsuka0752_1220368x_1220369x

  • リモートLTはうまくいかなかったので代行で
  • aws
  • route53
  • publichostedzone
  • 親子同居ゾーンはみつからなかった

[2019-02-16 17:07]

終了

懇親会

  • 味仙(あじせん;みせん、ではない)にて。
  • 食べ放題・飲み放題 会費4000円
  • 8.8.8.8からの問い合わせをブロック方法: 自分で8.8.8.8に問い合わせして、アドレスを収集してフィルタに登録しているとのこと。
  • 研究室に名前をつけろということで、じょうだんで「インターネット崩壊研究室」で出したら通ってしまった、とのこと。

IMG_20190216_172740IMG_20190216_180058IMG_20190216_182925IMG_20190216_183012IMG_20190216_184338

_1220373x

IIJlabセミナー: 進化するロギング: デバッグのための古くて新しい技術

IMG_20190122_173812

ロギングはバグを特定するための古典的な手法である.ログとして記録してお
くイベントの品質が,そのままデバッグの効率に直結する.それにもかかわら
ず,従来のロギングでは開発者の経験と勘に基づいて
1) ログを出力するコード上の場所(where to log) と
2) 記録しておくべき情報 (what to log)
をアドホックに決定している.そのため,デバッグ時に必要十分な情報が得ら
れるとは限らず,デバッグを困難なものとする一因となっている.
本発表では,ログの品質を改善する「ロギングコード自動挿入」に関する最近
の研究成果を紹介する.ログの自動挿入はここ数年にわたって活発に研究され
ており,システムソフトウェア研究のトピックのひとつとなっている.既存研
究を概観したのち,発表者等が研究・開発を進めているロギング・ツールK9
について紹介する.K9 はマルチスレッド環境におけるエラー伝播を対象とし
ており,共有データを介したスレッド間でのエラー伝播の追跡を可能とする.
共有データを介したエラー伝播が発生すると,障害を起こしたスレッドのコン
トロールフローを遡っても,障害の原因となったバグにたどり着けるとは限ら
ない.K9 ではそのようなエラー伝播の追跡を支援する.実際に,K9 をLinux
カーネルに適用し,既知のカーネル・バグ 3 種の追跡が可能であることを確
認した.さらに,Linux のファイルシステム保守中に遭遇した未知の障害にも
適用し,バグの特定に有益であることを確認した.

IMG_20190122_174848IMG_20190122_175121

[2019-01-22 18:00]

  • 障害が発生したら(教科書的には): 再現→調査→対策
  • しかし:
    • そもそも再現がむつかしい。
    • 同じ実行環境が手にはいらない。
    • プライバシの観点からデータが手に入らない。
  • かわりのログを送ってもらいログを調査する。
  • しかし:
    • ログが膨大すぎて解析できない。
    • 肝心の手掛かりとなる情報がログにない。
  • 経験と勘に基づいたロギングが原因。
    • システムコールのエラー。
    • 例外的な処理。
    • 気分で入れてるだけ。
    • windows SOSP 2009
    • printf, log4j, syslog event tracing for windows (ETW)
  • 適切なログイングは難しい。
  • 専門用語:
    • logging too little: ログが少なすぎる
    • logging too much (redundant&trivial): 冗長だったり、あたりまえの内容だったり。オーバヘッド・ストレージ使用量が問題になる。
  • ロギングが研究テーマになったのは数年前から
    • 手動から自動へ
    • where to log?: どこに入れるか?
    • what to log?: どんな値を記録すればよいか?
    • what happend?: ログから障害発生の様子を自動抽出して障害の実行パスを類推する。
  • Errlog [Yuan+ OSDI'12]
    • どこでログを入れるか、入れわすれたところに自動でログを入れる。
    • 例外処理:
      • 実際にはログを取り忘れるケースが多い。250件の障害事例を調査。
    • error()を呼んでたらエラー処理というような判定をする。error()を呼ぶ条件式を集めて、ログを入れ忘れているところに追加する。プログラマは無能ではない前提。
  • SherLog [ASPLOS'10]
    • what happend? ログから実行パスを類推する。Sharはシャーロックホームズから。
  • LogEnhancer[ASPLOS'11]
    • 実行パスが類推できるように変数の値をロギングする。
  • K9ではLinuxをターゲットにした。
    • Linux as Infrastructure
    • Linuxは実用的・巨大・複雑なので、Linuxでつかえれば他のソフトでも使える。
  • 用語:
    • fault: =bug 誤りのこと バグがあっても踏まないと発症しない
    • error: バグをふんでおかしくなった状態
    • error propagation: おかしな状態は伝搬する
    • failure: 障害発生(クラッシュ・ハングアップ)
  • Palix:
    • Null: nullチェックもれ
    • Inull(Inconsistent null check): ポインタ参照(deref)したあとにnullチェック(意味がない)
    • Block: ブロックしてはいけないコンテキストでブロックする関数をよぶ
  • linuxにはだいたいいつでも700個くらいバグが残っている。
    • バグをつぶしても同じくらいバグが入ってくる。
    • 1行あたりのバグは減っている。
  • 簡単なバグだけではない
    • 関数にまたいだ問題
    • 割り込み(非同期)
  • Inter-thread error propagation
      • Btrfsでworker threadが例外時にdirtyフラグを落すのを忘れて
      • sync threadがBUG()を踏む
    • direct propagation: スレッド1が共有データを更新して、スレッド2が読む。
    • indirect propagation: スレッド1が共有データを更新して、スレッド2が読んで別の共有データを更新して、スレッド3が読む。
  • K9ではエラー伝搬を解析できるようにログを入れるが、linux規模のソフトでは正攻法は無理。
    • オーバヘッドを押える
    • 静的解析はしない
    • ポインタ解析はしない (やっても正確には分からないことが証明されている)
    • coding traditionを仮定して共有データをさがす。
      • 共有データはヒープに置かれる。
      • 共有データは構造体になっている。
        • そのなかのポインタ配列やリスト構造をみる。
        • リンクリストなどのデータ構造用のライブラリにも対応(対応しないとデータ構造を操作するだけの関数がログに出て呼び出し元が分からない)
    • indirect propagationはデータフローは追い掛けずに型レベルで推測する。
  • ファイルシステムにはバグが多いという論文がある and Btrfsは新しいファイルシステムなのでバグが多く残っているのでは? and 研究室の学生がBtrfsのメンテナ
  • Btrfsで未知のバグをK9で追い掛けた原因をつきとめられた (実証)
  • K9のオーバヘッドは、スループットで1.83%(平均)、CPU利用率で0.32%(平均)。
  • たまにスループットのオーバヘッドが少ないという論文があってもCPU使用率が高いケースがある。その場合はCPUに余裕がないとスループットが悪くなる。

[2019-01-22 19:16]

QA

  • Q: ログを入れたのはファイルシステムだけ?
  • A: yes。だがファイルシステムのコードから呼ばれている関数にもログが入っている。スケジューラとかメモリ管理とか。これら(sched,mem)にはバグが少ないという研究報告がある。クリティカルセクション内でログを吐かないようにすることで、よりオーバヘッドを減らせる余地がある。
  • Q: ロックには注目しないのか?
  • A: ロックの範囲を調べるのが簡単ではないのと、ロックが保護している変数を見つけるのも難しい。ロックもれがあった場合に困る。やってみたが良くなかった。
  • Q: K9の論文は公開されているか?
  • A: 投稿中。
  • Q: オープンソースにするのか? それとも企業に買収されるのを期待しているのか?
  • A: 日立との共同研究なので日立が買う可能性はあるが、オープンソースにする予定になっている。
  • Q: C以外の言語でもつかえるか?
  • A: LLVMの中間言語で解析しているので、言語に特化したものでなければいけるはず。

[2019-01-22 19:24]

IMG_20190122_194128

関連資料?

いってきた: BitVisor Summit 7

IMG_20181128_100201IMG_20181128_100344bitvisorsummit7

[2018-11-28 10:30]

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

  • スライド
  • 録画
  • BitVisor Summit を議論の場として提供していく。
  • 昨年は盛況だった。内輪じゃない人がおおかった。
  • 今年は招待講演がない。ちょっとネタ切れ。宣伝不足だった?
  • 今年10周年(2018/03)。
  • vThriiの近況
    • ネットブートとネットインスールのハイブリッド。
    • うれしいのはユーザじゃなくて管理者。
    • 大学中心にけっこう売れてる。合計5690台。
    • あまり競合製品がないので市場規模がわからないけど。
    • Macの方がデバイスドライバで問題がおきにくい。Winはつらい。
    • となるとお金をもってる大学しか入れられない?
    • 海外展開: MacのAdmin会議で宣伝するとか?
    • 東大の機器が2020年にあたらしくなるがMac miniに対応できるかな?
    • ARM対応はいつかやらないといけない。
  • 研究室
    • 査読付き論文 5本
      • Live Migration in Bare-metal Clouds
      • がんばって物理デバイスの状態を取得する。
      • CPUは簡単だけどIOがたいへん。
    • Unified Hardware Abstraction Layer with Device Masquerade
      • bitvisorがハードウェア抽象化することでOSのデバイスドライバを共通化できる。
      • たとえば物理デバイスをvirtioにみせる。
    • Distributed Denial of Service Attack Prevention at Source Machines
      • BitVisorのなかでBPFをうごかしてDoSを防ぐ。
      • 外からBPFで書かれたポリシーを送り込みたい。
      • 攻撃側のPCにポリシーを送り込んで攻撃を止めたい。
      • BPFなら安全。
    • FaultVisor2: Testing Hypervisor Device Drivers against Real Hardware Failures
      • デバイスドライバのバグをみつけるために、デバイスの故障をエミュレーション。
      • VMware ESXiのデバドラバグを発見した。
      • Nested VMに対応したのでHyperVisorのデバッグができるようになった。
    • 進行中 研究3件
    • 論文 VEE09の参照数が200件を越えた。
  • 普及活動
    • コミュニティを活性化したいが、
    • ちょっと敷居がたかい。(一般ユーザ向ではないので)
    • ひきつづき考えていく。
    • ML, slack がある。

[2018-11-28 10:53]

[2018-11-28 10:54]

BitVisor 2018年の主な変更点 / 榮樂 英樹(株式会社イーゲル)

  • スライド
  • 録画
  • NMI関連の問題の修正
    • VMMの処理のなかでNMIが来てるかチェックしてからVMRUNでゲストに戻るまでにNMIをくらった場合、NMIがインジェクトされず、次回VMMに制御が移ったときにインジェクトされる(遅れる)問題。
      • 一見、次のVMEXITのときにインジェクトできるので問題なさそうだが、
      • Windowsの再起動のときにCPU0がNMIを送信して、CPUnは割り込み禁止にしてMWAITしてNMIをまっていて、(VMEXITが発生せず)ハング。
      • 直前にチェックするようにして回避した。
      • AMD SVM: CLGI命令でNMIをマスクできる!のでVMRUNでゲストに戻った瞬間にVMEXITできてNMIチェックをすりぬける隙間が空かない。
      • Intel VT-x: スタックのリターンアドレスをみる。
    • 割り込みでVMEXITしたときにVMMの処理のなかでNMIくらったばあい、両方の割り込みをインジェクトすることができず、次回までNMIインジェクトが待たされる問題。
      • 一旦通常割り込みをインジェクトしてすぐにVMEXITさせることで解決する。
    • NMIハンドラ実行中からIRETまでのNMIはブロックされるが正しく処理できない問題があった。

(以降、話題についてゆけず orz)

[2018-11-28 11:28]

  • Q: Nested VMのときはNMIはどうなる?
  • A: guest vmmがNMIをハンドルしてくれるはず。
  • Q: VMCS shadowingはもっと簡単な方法があるのでは?
  • A: 昨年深井さんからもらったコードはクリアするだけのコードになってたが、いろいろ不具合がありそうだったのでコピーする実装にした。その方が速かった。
  • Q: 不具合対応は榮樂さん以外でもできる体制になってる?
  • A: 調査くらいなら他の人でもできている。
  • Q: AMD対応をがんばっているのはなぜ?
  • A: いまのところ製品としてはAMDには採用されたことはないが、サポートするといっているので、やらないわけにはいかない。
  • Q: 割り込み(NMI)のテストはどうやっている?
  • A: bitvisorのコードwo流用してNMIを起こすようにしてテストした。
  • Q: DPDKとかVT-dとかRDMAとかをつかうアプリ対応は? (マイグレーションのときとかどうする) (virtioをつかうものはbitvisorのvirtioのできしだい)
  • A: 考えてなかった。MacでファームウェアでVT-dを設定しているものがあり、bitvisorが立ち上がったときにはすでにVT-dが設定されている(おそらくfirewireのメモリ転送を止めるため)。 VT-dを無効にしている。
  • Q: 今回のバグを修正したものはつかえるか?
  • A: bitbucketのは反映されている。リリースはまだ予定はない。

[2018-11-28 11:42]

昼休み

IMG_20181128_115514

30分くらい寝た。

[2018-11-28 13:00]

Interesting Issues During NVMe Driver Development / Ake Koomsin(IGEL Co.,Ltd.)

(中学レベルの英語力しかないので理解できず orz)

  • なんとなく:
    • completion queueのエントリをコピーするときにsfenceいれないといけなかった。
    • appleのNVMeんUEFIファームウェアにクセがある。ファームウェアのコードがgithubにあったので参考にした。
    • NVMe各社のコントローラにクセがある。

[2018-11-28 13:20]

QA

[2018-11-28 13:23]

[2018-11-28 13:24]

BitVisorによるOSの見かけ上10倍速実行 / 大山 恵弘(筑波大学)

  • スライド
  • 録画
  • ここ数年は時間を操ることをやっている。
  • 筑波大学には端末室が20もある。端末は1000台以上。
  • vThriiがよくおちる 運用の問題もあるかも
  • ゲストOSの時間を速くする → TSCを増やして返す。
  • あるキーを押すと10倍になるようにした。
  • デモ: xclock, worldclock, amazon, youtube, top, wget, ping が速くなる。
    • youtubeは処理がおいつかなくなってコマ落ちしている。
  • 60倍にしても資源バウンドとか待ち時間バウンドでその速度で動かない。
  • なにのやくにたつ?
    • ソフトウェアの開発で短時間で確認する。
    • 低速にして動作確認(シューティングゲームとか)。
    • 長い時間経過がトリガになる処理の確認。
  • RDTSCでVMEXITして偽装する。
  • RDTSCはwindows,linuxでHPETやPITよりも優先してつかわれる。
  • TSC deadline: linuxが計時につかっているが、めんどうなのでまだ実装してない。linuxがつかっている。
  • RDTSCP: out-of-order実行されないRDTSCは実装してない。
  • ブート時のTSC calibrationのときには1倍速にしておくのが重要。
  • マルチコア対応: コアごとに時刻をおぼえている。
  • 修正は230行。
  • NTPは切っておく。
  • linux tsc=reliableをつけておかないとHPETにきりかわってしまう。watchdogが常にPITでTSCを監視している。
  • windowsはまだうごいてない。画面が真っ黒になってしまう。原因不明。
  • キー入力はキーリピートが10倍速になって操作が難しくなる。
  • コンテキストスイッチも10倍になってオーバヘッドがめだつ。
  • 関連:
    • CPUエミュレータの加速/減速機能ににている。
    • HyperSlow(仮想時間を速くしてマルウェアを動かなくする)
    • うさみみハリケーンの加速減速機能

[2018-11-28 13:50]

  • Q: linux fundationでカーネルをいじって速くするという話があった。jiffiesがあふれる瞬間をみれたり。デバイス周りのタイマとの整合性。USB1だとCPU依存。タイムアウトはあるかも。
  • Q: TCPのタイムスタンプとか。無駄に再送されてる?
  • Q: プロセスごとに時間切り替えはCR3でできる?
  • A: OSの時間管理をいじらないとむつかしそう。
  • Q: マルウェアの解析にはどうつかう?
  • A: 未来にならないと発症しないもの、sleepはスキップするとダメなものがあるのでsleepをスキップせずに早く終わらせたり。
  • Q: タイマー割り込みは?
  • A: 頻度は変えてない。
  • Q: DOSは?
  • A: DOSはだめかも。
  • Q: youtube: ビデオとオーディオの同期はどうなってる? ふつうはオーディオにあわせようとして速くならないのでは?
  • A: 音はミュートしていたのでわからない。
  • Q: 止められる? 逆まわしとか。
  • A: やってない

[2018-11-28 14:03]

[2018-11-28 14:04]

CTFVisor: BitVisorによるCTF作問・出題支援 / 松原 克弥(公立はこだて未来大学)

  • スライド
  • 録画
  • 背景:
    • プロジェクト学習(PBL)
    • CTF(Catch The Flag)
      • attack & defence: 脆弱性のあるシステムの攻防
      • Jeopardy: フラグ(隠されたデータ)を読み出す早さを競うクイズ
  • CTFは作問がむつかしい。
  • ログやダンプを渡して解析させることがおおい(キャプチャはやらない)
    • Network,Forensics,Stego
  • bitvisorが入ったUSBメモリを参加者に渡してパケットキャプチャをするところからやらせる。実環境での体験を提供する。
    • たとえば、CTFVisorの上でパケットを送信するとTCPヘッダのreserved領域にフラグを埋め込まれて、wiresharkでキャプチャして発見させる、など。
    • たとえば、ブートセクタを読むとフラグが埋め込まれたデータが返ってくるとか。
  • windowsだとVRAMを書き換えても画面キャプチャできない。
    • linuxならframebufferをキャプチャすればいける。
  • mrubyで作問できるようにしたい。
  • USBの通信も作文につかわれているので対応したい。

[2018-11-28 14:20]

  • Q: CTFはセキュリティがメインだが、そもそもUSBを挿すのは抵抗があるのでは?しかもハイパーバイザーが立ち上がるし。
  • A: 本格的なCTFよりは易ししCTFとか期末試験につかうとか、CTF初心者に向け。ログをみるよりは実際にキャプチャすることを体験させる。
  • Q: CTFやってるひとからするとUSBを解析されてしまう?
  • A: たぶんbitvisorを解析されてしまう。
  • Q: 画面に表示することでbitvisorが動いていることを示す電子透かしにできないか?
  • A: できるとおもうが、VRAMの書き換えは難易度が高い。
  • Q: デモで毎回リブートしていたのはなぜ?
  • A: intel graphicのドライバの関係。
  • Q: デバイスがいろいろだとbitvisorがうごかないのでは?
  • A: いろんなOSが動くが、いろんなマシンでは動かないというのがbitvisorの欠点...
  • 環境の流通としてのbitvisor: bitvisorでハードウェア環境をわたして、OSはユーザのものを使える。

[2018-11-28 14:32]

休憩

P1210681x

[2018-11-28 14:46]

TinyVisorによるVM間H/Wリソース動的譲渡 / 安岡 亮輔

  • スライド
  • 録画
  • tinyvisorとはVMが2つ(メインVMとサブVM)動くようにしたもの。ハードウェア分割してしまう。
  • タイマとか分割できないものは仮想化しているものもある。
  • 起動時にリソース分割して2つのVMが同時に起動してしまっていた。
  • 起動後にHWリソース分割できるようにした。
  • hotplug/unplugで資源譲渡する。
  • hotunplugするとHALT状態になるのでNMIを送ってvmexitさせる。
  • メモリはhotplugできるけどunplugできないのでhot-offlineをつかう。
    • hot-unplugは物理的に抜ける。
    • hot-offlineは使わないようにするだけ。
  • デモ(ひさしぶりに動かしたので手順ミスって失敗...)
  • サブVMの起動は1回のみ。サブVMのブートシーケンスを改良する必要がある。
  • 実行中に資源を譲渡するのは実装してない(サブVM起動時のみ)。

[2018-11-28 15:08]

  • Q: どういうときに使うとうれしい?
  • A: 先生にいわれたから。。。 VMM再起動で若返りさせるのにつかえる?
  • Q: DPDKではremoveではなくunbindだったような。
  • Q: 非連続物理メモリでもだいじょうぶか? hugepageがつかえない。
  • A: サブVMの方はアドレス変換しているのでだいじょうぶ。hugepageでもだいじょうぶ。
  • Q: 128MiB単位でしかonline/offlineできなかったような。

[2018-11-28 15:17]

[2018-11-28 15:18]

bitvisor.ko : BitVisor as a module / 味曽野 雅史(東京大学)

  • スライド
  • 録画
  • モチベーション:
    • 開発速度を上げたい
    • 仮想化によるオーバヘッドを下げたい
  • bitvisorは常に必要ではないかもしれない → 必要になったときだけ使う
  • デバイスの暗号化では最初から仮想化が必要だが、
  • オンデマンド仮想化: 必要なときだけVMMを挟む。
  • オンデマンド仮想化ネタは新しいものではない。
  • 関連研究:
    • VMX rootkit
    • Late launch (Intel TXT) コードサインの関係で生OSでブートしてからVMMをはさむものらしい。
    • カーネルモジュールでhypervisor: (ksm),bareflank,ShadowBox,HyperPlatform
  • やりかた:
    • (a) bitvisorをカーネルモジュールにする。
    • (b) カーネルモジュールからbitvisor.elfを読む。 (今回はこっちで)
  • bitvisorのUEFIのブートシーケンス:
    • firmware -> loadvmm.elf -> 2nd-loader -> init +start VMM -(VMENTRY)-> トランポリン -> loader.elf,firmwareにもどる
  • 関係しそうなところがたくさんありすぎるので、問題になりそうなところから順番に対応していく方針で。
    • UEFI func call
    • ACPIはいったん実装保留.. (どうせサスペンドさせたりしないし...)
  • - どうやって連続メモリを確保するか? いまはlinuxのブートオプションで特定のメモリ領域をつかわないようにしてbitvisor用の領域を確保する。
  • Application Processor(AP)
    • マルチプロセッサ環境でブートでつかわないCPUの方
    • cf BSP(bootstrap processor)
    • bitvisorは最初BSPしか仮想化してなくて、guest OSがstartup IPIで初期化しようとしたときに初めて仮想化する。
  • bitvisorがサポートしてない命令が実行されたらどうする? (隠蔽できないので)
  • ユーザ空間でどうやって実行するか? SMEP/XD bit のためカーネルモードからユーザ空間のコードを実行できない。
  • de-vitualization: ゲストがvmcallしてきて、vmentryしないで状態を復元してjmpでもどる。
  • 実装はまにあわず。
  • 余談: 開発では ubuntu on bitvisor on VMware workstation on Host の環境でやっているが、linux RAIDのコードがAVX512命令をつかっていて、そこでlinuxがpanicする問題がおきている。

[2018-11-28 15:44]

  • Q: (榮樂)ページ切り替え: 1ページにきりかえコードをおしこむコードがすでにある
  • A: (味曽野)参考にします。
  • Q: (味曽野)APで頻繁に同期してるのは?
  • A: (榮樂)キャッシュをさわるときは同期をとるようにマニュアルに書いてあるので。

[2018-11-28 15:47]

ベアメタルクラウドにおけるハードウェア保護に関する研究 & Advent Calendar について / 深井 貴明(元 筑波大学)

  • スライド
  • 録画
  • BMCArmor: A Hardware Protection Scheme for Bare-Metal Clouds
  • 実は去年のネタ。社会人になって手を動かす時間がとれなくなった。。。
  • 発表6回目。
  • bitvisorはseedsベースの話が多いが、今回はneedsベース。
  • ベアメタルクラウド=物理マシンを提供するIaaSクラウド
    • マシンの最大性能・物理ハードウェアを提供できるが、
    • OS非依存のスナップショットとか資源の多重化は不可。
  • ベアメタルクラウドだとfirmwareをさわれてしまう問題。
  • 起動しなくなったりファームウェアにrootkitを入れられてしまったり。
  • マシンのオーナーとOSの管理者が別なのはPCアーキテクチャでは考えてなった。
  • Permanent DoS,データ盗難・破壊。
  • ハードウェアの保護機構: 有効になってなかったり、脆弱性があったり、そもそも保護機構がなかったり。問題があったときの対応が難しい。
  • ファームウェアの書き戻しがうまくいくとはかぎらない。(すでの壊れてたり、rootkitが入っていたり)
  • 既存研究には検知はあるが防止はない。
  • 不揮発データへのアクアセス: メモリ, IO, コマンドキュー.
  • これをbitvisorでアクセス制限したり、有効になってない保護機能を有効化したり。
  • メモリはwriteだけ止める。readはパススルー。
  • IOはポート単位でread/writeをフックしてwriteは止めるreadはエミュレートする。
  • コメンドキューは止めたいコマンドをダミーコマンド(エラーになるような)に入れかえてしまう。completeキューにはエラーが返ってくる。実装が楽。
  • Intel CHIPSEC(検査ツール)で保護機構が有効かどうかチェックできる。
  • netperfでの性能測定では、オーバヘッドは少なかった。
  • 不要なVMEXITが多発。おなじページに保護したいデータと通常機能があるため。
    • intelは細粒度で保護かけられるようにするらしい。
    • 最近のデバイス(x540とか)だと1つのページにまざらないようになっている。
  • 研究の経緯:
    • 後輩が実験で全てのIOをランダムに改変する実験(デバイスドライバのfuzzing)をしてたらハードが壊れた(ノートPC 3台)。EEPROMを書き換えられてしまった?
BitVisor Advent Calendar 振り返り & 宣伝 & お願い

[2018-11-28 16:16]

  • Q: 不揮発データへのアクセス方法は、この3つだけか? 抜けはないか? (CPUを介さないファーム更新があるかもしれない?)
  • A: 単純なMMIOじゃなくてポインタをつかうようなものはあるかも。
  • Q: 毎回ファームウェアをロードするようなデバイスだと困るのでは? (スマホのカメラの画像プロセッサとか)
  • A: サーバがターゲットだったのでカメラとかはかんがえてなった。NICとNVMeを考えていた。GPUは考えてなかった。
  • Q: UEFI boot menuは対象か? だとするとインストーラが動かないのでは?
  • A: boot menuはBIOS ROMに保持しているので、たぶんだめ。ホワイトリスト形式で制御できるようにしたい。
  • ベアメタルクラウドはPCアーキテクチャベースだがIPMIとかRedfishとかである程度マシンの制御はできるはずだが周辺デバイスまでは管理できない。
  • 究極にはPCIやMMUにポリシーを書けるようにしないといけないだろう。

[2018-11-28 16:30]

[2018-11-28 16:31]

LT: Bitvisor will be dead / Kuniyasu Suzaki

  • 録画
  • T2 secure chip in Mac mini.
  • secure bootを強化したようなもの。linuxがブートしない(セキュリティをoffにすればブートするらしい)。
  • Apple_T2_Security_Chip_Overview.pdf
  • パスワードを27回まちがえると1時間待たされる。さらに間違えるとリカバリーモードになって、さらに間違えると消去される。
  • T2はマイクの電源は切るけどカメラを切らないのは裏がありそう。
  • bitivisorがMacに依存していると、これからたいへんそう。

[2018-11-28 16:36]

閉会

[2018-11-28 16:43]

P1210693x

Gfarmシンポジウム 2018

IMG_20181026_130956IMG_20181026_131153

[2018-10-26 13:30]

Gfarmファイルシステムの最新機能
国立大学法人 筑波大学 教授 建部 修見

  • https://www.youtube.com/watch?v=d2Ijv7PG3m4
  • 外部配信中
  • 他と違うところ:データアクセスの局所性を重視、サイレントデータ損傷に対応
  • 利用(共用): JLDG(10.7PB,8site),HPCI(100PB,2site),NICT,クオリティアactive! world。
  • 利用(解析): すばる望遠鏡のデータ解析,メタゲノム解析
  • 2.7.10が最新リリース
  • 2.6.8で書き込み後ベリファイ(数時間後にベリファイ)
  • バーストバッファ: ノードローカルなNVMeをつかって分散ファイルシステムを構築する
    • NVMeはジョブが割り当てられたときしか使えない
    • 永続性はすてて性能を重視 メタデータはメモリに載せる (postgresqlをやめる)
    • 196s → 20s
    • 0.3sで構成をつくれる
  • データ移行支援: 運用を止めずに10PB→100PBに拡張するときに必要な機能を実装した
    • 書き込み禁止: ファイルに書けないけどファイルは作れるとか
  • gfmdレスポンス改善: JLDG 数10PB/日 のアクセス linuxのスレッドの実装の問題だっ たが
  • IB RDMA
    • クライアントのユーザバッファをpin-downして直接サーバから転送できるようになっ た。
    • 1.8倍性能向上
    • posix apiだと1.2倍
  • quota
    • グループクォータとディレクトリ単位のクォータを併用できる (xfsはできない)
  • データ完全性
    • 書き込み時にダイジェスト(SHA1とか)を計算
    • 読み込み時にチェック 異なっていたら lost+found に移動 修復
    • JLDG 9.9PB 111Mfiles 書き込み後ベリファイで5ファイル検出

分散深層学習を支えるストレージ技術〜AI橋渡しクラウド ABCIの事例と将来課題
産業技術総合研究所人工知能研究センター 主任研究員 佐藤 仁

  • https://www.youtube.com/watch?v=CnfjLiaEaWc
  • 東大柏に 0.550EFlops 37.2PFlops(DP) 19.88 PFlops(peak) 国内最速スパコン
  • gfarmも動く (サポートはしてないが検証はした)
  • 建物から設計した
  • 1node = tesla V100 x4 + Xeon Gold 6148 + 384GiB + NVMe 1.6TB + EDR IB HCA x2
  • 1rack = 34 nodes + full-bisection BW fat-tree ; 70kW
  • inter-rack = 1/3 BWで接続されている
  • storage
    • local: 1.6TB NVMe BeeOnd(like burst-buffer)でまとめることもできる
    • parallel filesystem: GPFS (DDN SFA14K) x3
    • object storage: GPFSの領域の一部でopenstack swiftをうごかしてS3 like APIを提供。グローバルからアクセスできる。暗号化も。
  • 分散深層学習
    • データ並列
      • 同期型 パラメータを正確に更新できるので精度が高い デファクトスタンダード
      • 非同期型 はやい
    • モデル並列
  • GPU+CuDDN(演算), NCCL2(ネットワーク通信), MPI(プロセスの起動)
  • Chainer: forward->backword->optimize
  • ChainerMN: forward->backword->allreduce->optimize
  • 汎化性能: 局所最適化を避けて全体最適化したい
  • ABCI Grand Challenge
  • いまどき: linear scaling rule, gradual warmup, LARS
  • IOのスループットだけでなくメタデータ性能も重要 データセットが小さい 1画像70kB 弱程度
  • 学習時にランダムネスを上げるようにする 汎化性能のため
  • chainerだと配列のようにアクセスするのでopen+read+closeが大量発生してしまう。
  • フレームワークによってはDBをつかうものもある。
  • ファイルキャッシュを入れると1時間のものが30分くらいになる。
  • 将来課題
    • マルチテナントとセキュリティ
    • 企業や医療データ
    • 資源を動的にユーザグループ毎に棚貸し

[2018-10-26 14:32]

  • Q: キャッシュが有効なのはなぜ? 何度も同じファイルを読んでいる?
  • A: もっと上のレイヤーでのAPIがあるといいかも。

次世代スーパーコンピュータ向けファイルシステムについて
富士通株式会社 次世代TC開発本部 ソフトウェア開発統括部
シニアアーキテクト 住元 真司

  • https://www.youtube.com/watch?v=Mf1AocSM1uA
  • A64FX
    • 1chip = (12core+1core) x4
    • 1世代前のsparc chipに比べて2倍の性能
    • Tofu2 -> TofuD
      • そのままもっていくとコスト(シリコンと電力)をくう
      • laneを半分に減らして数を増やした
  • FEFS for K computer
    • 8万ノード 100PB 1TB/s 当時luster1.8
    • 性能か信頼性かはユーザが選べる
    • stage-in → 計算 → stage-outの3段階 3倍の容量が必要になってしまう
    • ファイルの指定が手間
    • 計算時間が短かいとデータの移動がムダ(利用効率が落ちる)
  • ローカルはよりアプリ寄のストレージ → luster-based → アーカイブ
  • データのライフタイム、アクセスパターン
  • 1プロセスが1ファイルを読み書きするパターン、ファイルをつかってプロセス間のデータ通信するパターンが多い。
  • SSDの寿命の問題 アプリが1日にどのくらい書き込むか重要
  • intel optaneは性能はいいけど書き込み信頼性はnandと変らず。素子自体は信頼性が上がっているが回路の部分がいまいち。
  • How SSD based storage shoud be used?
    • lifetime, application's access pattern, data sharing in a job, data shareing among multiple jobs, ssd lifetime issue
  • LLIO (prototype) burst buffer nodeを用意する

[2018-10-26 15:06]

  • Q :メタデータは2nd storageをつかう?
  • A: キャッシュとしてつかうときだけ。ローカルなら

[2018-10-26 15:07]

休憩

[2018-10-26 15:16]

オブジェクトストレージ、AI+IoT+映像における利用事例
クラウディアン株式会社 取締役COO 本橋 信也

  • https://www.youtube.com/watch?v=sZCT-W_xFCo
  • 日本発だが海外の方が大きくなった。
  • オブジェクトストレージ
    • 大手の通信事業者のメールシステム NOSQL
    • amazon S3 とおなじものをつくった -> HYPERSTORE
    • ベンチャー企業として賭けに勝った
  • クラウド事業者向けに販売
  • P2P 3ノードから
  • 日本だとPBを要求する客は少ない。
  • 容量はEBくらいまでは拡張できるのを確認している。
  • replication + erasure-coding
  • バスにカメラ5台をインターネット経由で保存。
  • AI向け: メタデータとblobをまとめて扱える。
  • 実証実験: 高速道路を走る自動車をリアルタイムで識別してデジタルサイネージを出す。
  • →駐車場・ショッピングモールでつかいたいという客が。
  • GPUどうする?クラウドだとレイテンシが → AI BOXをつくった。
  • 4Kカメラ 圧縮すると意味がない エッジの処理が必要
  • 交通量の測定をAIで
  • 画角は手動で設定
  • 自動で車線を認識 車をカウント 速度 直進 右左折 CSVでデータを送る。
  • エッジで学習用の画像を切り出してクラウドに貯める。
  • 車の車種はロングテールで自動でタグ付けする必要がある。

Scalityと大規模オブジェクトストレージの運用の実際のご紹介
スキャリティ・ジャパン株式会社 セールスエンジニア 仁戸 潤一郎

  • 創業はフランス 2009
  • メールサービスのストレージからはじまった
  • 製品: RING ZENNKO
  • データはつかって価値が出る。
  • データはオンプレに置いてワークロードはクラウド。
  • object storageは容量重視、flashは速度重視、NASはあまり市場はない。
  • NASは人間のスケール。flashはオブジェクトストレージはアプリが相手。
  • RING 汎用x86 linuxで動く。ソフトのみ提供。NFS,SMBでもオブジェクトにアクセスで きる。
  • P2P CHORD
  • アプリケーション RINGコネクタサーバ ストレージサーバ スーパーバイザー
  • コネクターはブートストラップノードリストをもっていてリクエストをなげる。
  • メンテナンスタスク
    • balance ノードのつけはずしのときにデータを移動する
    • proxy
    • rebuild 最新のバージョンをもっているか定期的にチェックする
    • repair ディスク障害時にインデックス情報から再レプリカをつくる
    • purge 古いバージョンの物理削除
      • オブジェクトはコンテナファイルに保存しているのでinodeを消費しない
    • relocation
      • デフラグ
  • バックグラウンドタスクの負荷調整
  • 国内事例: KDDI iphone mailでつかっている
  • キースペースの設計が必要でシミュレーションで確認する。障害時に負荷が分散するように配置しないといけない。サポート体制が重要。
  • オジェクトストレージはアプリケーションの関する知識が必要。

[2018-10-26 16:16]

  • Q: 物理的な配置は?
  • A: データセンターをまたいでも構成できる。スプリットブレインになってもデータは アクセスできるように複製している。ラック単位・シャーシ単位でも考慮できる。

HPCI共用ストレージにおけるディザスタリカバリ、
データ二重化運用による高可用性 と災害対策の実現
国立研究開発法人理化学研究所 開発研究員 原田 浩

  • https://www.youtube.com/watch?v=9i76p_njrOc
  • 8/23 台風20号 電源障害
  • 8/31 落雷で停電
  • HPCI共用ストレージ そろそろ運用もおわるけど
    • 補足:運用が終わるのは京でHPCIは続くらしい。認証基盤だし。
  • 通信はGSI(grid security infrastructure)で暗号化している
  • 物理的には100PBくらい、二重化しているので使えるのは50PBくらい。
  • SINET5
  • メタデータサーバは東大と理研で二重化
  • フェイルオーバは自動化されてないのがつらい
  • データ破損があっても1営業日くらいで通知できる体制になっている。ユーザにはデー タは1週間くらい保存するようにいってるけど。
  • スパコンでつくるデータはお金がかかるのでデータ消失は防ぎたい。
  • 理研台風
    • 受電設備に水が入って止まった
    • 京コンピュータが止まったがストレージは止まらなかったのは幸運だった。
    • 仮復旧で停電する可能性があるので全マシンを止める必要があったのでマスターを理研から東大にフェイルオーバー。readonlyに。
  • 柏落雷
    • 東大にマスターがなかったのでたすかった。
  • 重度障害報告はしなくてすんだ。
  • IPアドレス変更・ドメイン変更のときはさすがに止めた。
  • 次の増強時は容量に余裕があるのでサイト内で二重化できそう。
  • 計算機センターに設置できるのはキャッシュメモリだけになって、ストレージは外部に、ということになりそう。場所の問題。
  • セキュリティレベルは民間レベルはむつかしいのではないか。お金の問題だとおもうけど。

[2018-10-26 17:01]

休憩

IMG_20181026_170246

[2018-10-26 17:07]

パネル:ポストムーア時代のストレージシステム

建部
  1. ポストムーア時代に想定されるストレージへの要求と問題点
  2. その問題点を解決するために必要な技術、デバイス
  3. ストレージの向かうべき方向
佐藤
  • スパコン業界からは「ストレージなんでどうでもいい」とおもわれているのではないか。
  • 高速なメモリ(HBM)をどう生かすか
  • NVDIMMをチェックポイントにどうつかうか
  • HPCコンテナ -- オールフラッシュストレージ -- オブジェトストレージ オンプレ・クラウド
  • トラディショナルなストレージだとユーザ・グループ単位の認証になるが、APIキーの ようなものも必要。
住元
  • 電力vs性能が重要
  • アメリカでは many-core と gpgpu の二種類
  • さまざまなarch
    • ノイマン型
    • アナログ型
    • ニューロ関係
    • 量子
  • こういうコンピュータとストレージをどうつなぐ?
  • なにがひつよう?
    • 移動データを抑制する
    • 主記憶の電力を抑制しながら大量データ処理
    • 蓄積型からストリーミング型のデータ処理に
本橋
  • flash hdd tape が連携
  • NBC テープアーカイブをHDD化した。トランプの若いころの映像を探すのに手間どった 。
  • メタデータ データの中身の情報のこと タグ付け 自動で
仁戸
  • ムーアの法則が終わって何がこまるのか?
  • クラウドに資本が集中する
  • データはまだサービスにくっついている
  • 個人にデータのものになるとよいのではないか。(おくすり手帳のような)
原田
  • 地理的な壁を越えたい。
  • 軽いストレージがほしい。床の耐荷重が問題になる。半分くらいしか積めない。
建部
  • まとめ
質問
  • Q: コンピューティングのためのストレージとストレージとしてのストレージ ポストムーアで分散になってストレージのブレークスルーはなに?
  • A:
    • 佐藤 スパコン屋はデータの使い方を考えてないのが問題 データの整理を自動化する 方向に。
    • 住元 ストリーミングで計算 蓄積しない方向へ
    • 本橋 GPUもストレージもひとつの箱で客に提供したい
    • 仁戸 ひとつの箱にはおさまらないのでネットワークの中にストレージがふくまれる 融合する
    • 原田 スパコンセンターはバッチスケジューラだけでいいのか? データの場所で処理 する方向に。

[2018-10-26 17:53]

懇親会は鳥元。

IMG_20181026_180251IMG_20181026_183327IMG_20181026_200219

そのあと曽田さん・白水さんとエクセルシーオルへ。

IMG_20181026_203020

tmux: cut&paste

tmuxのコピペは便利につかえるが、ひと工夫することでより便利に。

bind-key        [       copy-mode
bind-key        C-[     copy-mode
bind-key        C-]     choose-buffer "paste-buffer -p -b %%" 
bind-key        ]       choose-buffer

choose-bufferをつかうことでペーストしたいバッファをインタラクティブに選べて、不要になったバッファを消すこともできる。

paste-buffer -pオプションで(アプリがサポートしていれば)bracketed paste modeをつかって、エディタに直接ペーストできるので、たとえば普通にペーストするとインデントがずれてしまうところ、braceted paste modeをつかうとエディタが(キー入力じゃなくて)ペーストだと認識できるのでインデントがずれないし、ペーストをUNDOできる(キー入力扱いだと一発でUNDOできない)、巨大なテキストを貼り付けた場合には処理時間が短くて済む利点も。

tmux-logo-small

記事検索
月別アーカイブ
アクセスカウンター

    タグ絞り込み検索
    ギャラリー
    • 今日の練習 2019-03-18
    • 今日の練習 2019-03-18
    • 今日の練習 2019-03-18
    • FINA/CNSG Diving World Series 2019 Sagamihara,JPN
    • FINA/CNSG Diving World Series 2019 Sagamihara,JPN
    • FINA/CNSG Diving World Series 2019 Sagamihara,JPN
    Amazon
    楽天市場
    adby google
    LINE読者登録QRコード
    LINE読者登録QRコード
    • ライブドアブログ