2019-10-15 HPCS Lab. SSチーム論文読み会 "POSIX is Dead! Long Live... errr... What Exactly?" (POSIXは死んだ！ 長生き... えー... 一体どういうこと？)

🐧 筑波大学のHPCS研究室での自主勉強会で使った発表スライドです。
Source: https://docs.google.com/presentation/d/1WZJ_zt54EJVMTlT-U4lrrGP9hifZdo5I1fuTgf23eVI/edit?usp=sharing

Transcript

1. "POSIX is Dead! Long Live...
   errr... What Exactly?"
   (POSIXは死んだ！ 長生き... えー... 一体どういうこと？)
   2019-10-24 HPCS Lab. SSチーム論文読み会
   M1 高橋 宗史
   

   View Slide

2. 読んだ論文
   ● "POSIX is Dead! Long Live... errr... What Exactly?"
   ○ 「POSIXは死んだ！ 長生き... えー... 一体どういうこと？」
   (Google翻訳の結果を一部改変)
   ● @ USENIX HotStorage '17
   ● Authors:
   ○ Erez Zadok, Stony Brook University
   ○ Dean Hildebrand, IBM Research - Almaden
   ○ Geoff Kuenning, Harvey Mudd College
   ○ Keith A. Smith, NetApp
   

   View Slide

3. 読んだ論文 / TOC
   ● References
   ○ 3つの参考文献の紹介
   ● The Problem.
   ○ POSIX の問題点
   ● A New Hope.
   ○ 新たな希望
   ● Our Proposal.
   ○ 提案手法
   ● Implementation and Transitioning.
   ○ 実装の進め方と移行の方法
   

   View Slide

4. References / [1:vNFS]
   ● [1] M. Chen, D. Hildebrand, H. Nelson, J. Saluja, A.
   Subramony, and E. Zadok. vNFS: Maximizing NFS performance
   with compounds and vectorized I/O. In USENIX FAST’17,
   pages 301–314, 2017.
   ○ NFS の RPC をベクタ化してまとめることで高速化したお話
   

   View Slide

5. References / [2:Cozy]
   ● [2] A. Purohit, C. Wright, J. Spadavecchia, and E. Zadok.
   Cosy: Develop in user-land, run in kernel mode. In ACM
   HOTOS 2003, pages 109–114, 2003.
   ○ Compound System Calls (Cozy) によって、システムコールの性能
   を改善した
   ○ Cozy-GCC という GCC 拡張を実装して、特殊な追加コードによる
   Compounding の処理を自動化した
   

   View Slide

6. References / [3:TOCTTOU]
   ● [3] J. Wei and C. Pu. TOCTTOU Vulnerabilities in
   UNIX-Style File Systems: An Anatomical Study. In USENIX
   FAST’05, pages 155–167, 2005.
   ○ システムコールの様々な組み合わせを試して TOCTTOU がどの条件で起
   こるのかを検証した
   ○ 静的・動的な検証ツールを実装して動かした結果、マイクロベンチマー
   クではオーバーヘッドが大きかったが、アプリベンチマークでは許容で
   きるほど小さいものがあった
   

   View Slide

7. The Problem.
   ● POSIXシステムコールのインターフェイスは30歳！
   ● 様々な問題がある
   ○ 旧式のインターフェイスの問題
   ○ セキュリティの問題
   ○ 同期アクセスの問題
   

   View Slide

8. The Problem.
   / 旧式のインターフェイスの問題
   ● 昔のコンピュータ
   ○ ストレージへのシリアルアクセス
   ○ シングルCPUのシングルコンピュータ
   ● 現代のコンピュータ
   ○ 高速・複雑・リモートデータへのアクセスが必要
   

   View Slide

9. The Problem.
   / セキュリティの問題
   ● POSIX はセキュリティを十分考慮できていない
   ● 近年、TOCTTOU 攻撃が増加している[3:TOCTTOU]
   ● POSIX がセキュアなデザインなら防げたはず
   

   View Slide

10. The Problem.
    / Note: TOCTTOU 攻撃とは？
    ● Note1: TOCTTOU 攻撃とは？
    ○ TOCTTOU (トックトゥー)
    = Time of check to time of use
    ○ 「ある条件（セキュリティ認証など）をチェック (check) したあと、
    その結果を行使 (use) するまでに変更が発生することで引き起こされ
    るバグの一種である。」
    ○ 出典: Time of check to time of use - Wikipedia
    ● Note2: 対策はあるが実装が複雑になってしまう
    ○ 参考: IPA ISEC　セキュア・プログラミング講座：C/C++言語編　第
    9章 ファイル対策：ファイルレースコンディション対策
    

    View Slide

11. The Problem.
    / 同期アクセスの問題
    ● 1回に1つの同期POSIXコールを発行するのが前提
    ● 結果が返ってくるまで待機が必要
    ● 特に、現代のリモート・クラウドのオブジェクトへのアクセスと相性が悪い
    ● → 高レイテンシにより待機時間が支配的となってしまう
    

    View Slide

12. A New Hope.
    ● Compounding API (複合 API) の導入
    ○ 複数のリクエストを1つのメッセージにパッキングするテクニック
    ○ 高価なコンテキストスイッチとデータコピーを削減できる
    ○ ユーザー空間＆カーネル空間の両方で有効であることを示した
    [2:Cozy]
    ● 適用例
    ○ WAN 上の NFS で10倍以上 (orders of magnitude) のレイテンシ
    の低下[1:vNFS]
    ○ remote/cloud のオブジェクトストアも恩恵を受けられる
    ● TOTTTOU 攻撃の脆弱性が低下
    ○ fstat()やopenat()で同じファイルディスクリプタの使用を保証
    

    View Slide

13. Our Proposal.
    ● POSIX を廃止し、高並列＆高レイテンシに最適化された新しい API で
    POSIX を置き換えることを提案する
    ● これ以降、提案手法の新しいAPIについて、6つの特徴を説明する
    

    View Slide

14. Our Proposal. / 特徴1
    ● 特徴1
    ○ Compounding は (NFSv4 と同様に) 任意のシステムコールの集合を
    まとめることができる
    ○ → コストの掛かる多数のラウンドトリップを削減できる
    ○ 例: NFSv4では1つのcallの結果は次のcallに渡される
    ■ open(), read(), close() のシステムコールが１つの
    compoundにまとめられる
    ■ まとまったシステムコール間では同じファイルディスクリプタが使
    用される
    ■ → TOCTTOU 攻撃を防御
    

    View Slide

15. Our Proposal. / 特徴2
    ● 特徴2
    ○ POSIXのファイルと名前空間の抽象化は、ユーザーには非常に使いやす
    いが、ファイルではなくよりシンプルなオブジェクトへのアクセスを提
    供するクラウドサービスの人気が高まっている
    ○ → オブジェクトに対するread, write, create, rename, delete
    などの操作が、複数のオブジェクトに対する複数の操作についても、ま
    とめて1つのリクエストで可能であるべきである
    

    View Slide

16. Our Proposal. / 特徴3
    ● 特徴3
    ○ こうした新しいすべてのAPIはデフォルトで 「非同期」であるべきであ
    る (あるいは、非同期のAPIのみを提供する可能性さえある)
    ○ → ユーザーが効率の良いコードを書きやすくなる (あるいは、書くこと
    を強制される)
    

    View Slide

17. Our Proposal. / 特徴4
    ● 特徴4
    ○ Compounds のトランザクションのセマンティクスを明示的に定義する
    ○ → POSIX API 由来の TOCTTOU の多くを排除できる
    ■ クライアントとデータホルダ(クラウドなど)間の end-to-end の
    信頼性が向上する
    

    View Slide

18. Our Proposal. / 特徴5
    ● 特徴5
    ○ ユーザーが Compound のエラーハンドリングのセマンティクスを定義
    できる
    ○ → 1つのリクエストが途中で失敗した場合に次のどれかを選べる
    ■ 実行を途中で止め、一部の成功した結果だけを返す
    ■ 最後まで実行し、成功結果を true/false の配列で返す
    ■ NFSv4のnverify()と同じようにif-then-else条件文をサポー
    トする
    

    View Slide

19. Our Proposal. / 特徴6
    ● 特徴6
    ○ まとめたシステムコールの部分に対して、並列化可能な実行部分とシー
    ケンシャルな実行部分をユーザーが指定できる
    ○ → end-to-endの並列性を保証し、ストレージデバイスに対して操作が
    シリアル化されるのを最小限に抑えられる
    

    View Slide

20. Implementation and Transitioning.
    ● 新しいAPIへの移行には時間がかかる
    ● そこで、4つのステップでの移行を提案する
    

    View Slide

21. Implementation and Transitioning.
    / ステップ 1-2
    ● ステップ1
    ○ 最も一般的/役に立つAPI(例:copy-file/object)から実装を始める
    ○ 必要に応じて、より人気なAPIを追加してゆく[1:vNFS]
    ● ステップ2
    ○ 新しいAPIのセマンティクスは library wrappers として提供する
    ○ すべてのユーザーに「低レベル」なAPIの使用を強制しないようにする
    

    View Slide

22. Implementation and Transitioning.
    / ステップ 3-4
    ● ステップ3
    ○ begin/end API
    ■ Compoundsなセクションを明示的に指定できるようにする
    ○ start/commit/abort
    ■ トランザクションのセマンティクスが必要な場合にはこちらを使う
    ○ R&Dをコンパイラ＆静的解析ベースの技術に導入する必要がある
    ● ステップ4
    ○ 低レベルの compounding API を公開し、任意の多数のオペレーショ
    ンを1つの compound call にまとめられるようにする
    ■ エラーハンドリング、トランザクション、平行性のセマンティクス
    を導入して
    

    View Slide