sw

MewでISO-2022-JPなのに丸数字つかってるメールを読む方法

Mewcp5022x.el をダウンロードしてパスがとおったところにおいて、

.mewに

(require 'cp5022x)
(add-to-list 'mew-cs-database-for-decoding '("iso-2022-jp" cp50220-unix))

と書いたらok.

追記

SCRAM: Salted Challenge Response Authentication Mechanism

passwd salt iteration                                            nonce
    |   |    |                                                     |________________________________________,
    V   V    V                                                     |                                        |
Hi( *,  *,   * ) = SaltedPassword ---------------------------------)----------,                             |
                          |                                        |          |                             |
                          V                                        |          V                             |
                    HMAC(key, "Client Key") = ClientKey            |    HMAC(key, "Server Key") = ServerKey |
                                               |    |              |                                   |    |
                                               |    V              |                                   |    |
                                               |  H(*) = StoredKey |                                   |    |
                                               |              |    |                                   |    |
                                               |              V    V                                   V    V
                                               |        HMAC(key, str) = ClientSignature         HMAC(key, str) = ServerSignature
                                               |                           |
                                               V___________________________V
                                              XOR
                                               |
                                               V
                                          ClientProof

Server:
  exchange nonce
  recv ClientProof
  StoredKey = authDB[username]
  ClientSignature = HMAC(StoredKey, nonce)
  ClientKey = ClientProof XOR ClientSignature
  if H(ClientKey) == StoredKey then
      OK // the client knows the correct ClientKey.
  else
      NG



HMAC(key, str): Apply the HMAC keyed hash algorithm
H(str): Apply the cryptographic hash function
Hi(str, salt, i):

 U1   := HMAC(str, salt + INT(1))
 U2   := HMAC(str, U1)
 ...
 Ui-1 := HMAC(str, Ui-2)
 Ui   := HMAC(str, Ui-1)

 Hi := U1 XOR U2 XOR ... XOR Ui

jambow

いってきた: 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

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

    タグ絞り込み検索
    ギャラリー
    • 今日の練習 2019-05-19
    • 今日の練習 2019-05-19
    • 今日の練習 2019-05-18
    • 今日の練習 2019-05-18
    • 今日の練習 2019-05-18
    • 今日の練習 2019-05-11
    Amazon
    楽天市場
    adby google
    LINE読者登録QRコード
    LINE読者登録QRコード
    • ライブドアブログ