Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

情報処理学会主催 コンピュータシステムシンポジウム 基調講演(2012年12月6日)

Published in: Software
  • Be the first to comment

  • Be the first to like this


  1. 1. ComSys 2012 基調講演 仮想化とシステムソフトウェア研究 加藤 和彦 筑波大学 システム情報工学研究科 2012年12月6日
  2. 2. 概要 仮想化がコンピュータシステムで
 果たした役割を振り返りながら, 仮想化とシステムソフトウェア研究の関係, 理想と現実の関係について考える。
  3. 3. 昭和56年(1981年) 筑波大学 第三学群 情報学類 入学
  4. 4. 筑波大学第3学群情報学類1年次必修科目 情報科学概論IA by 益田隆司 先生 筑波大学電子・情報工学系 助教授(1981年当時)
  5. 5. 先輩曰く「情科IAだけは落とすなよ」 必修,かつ,その授業コマに2年次の 必修科目。 落とすと留年するしかない。
  6. 6. ミニコンHITAC 10II 1ワード16ビット,メモリ4∼32K 紙テープ タイピュータ
  7. 7. HITAC 10IIの磁気コアメモリ 4Kワード 拡大 「人海戦術」メモリ 不揮発性メモリ!
  8. 8. アセンブラ・プラグラミング,一年間。 OSなし。 タイピュータ出力は割り込み処理ルーチン を自分で書く。 割り込み処理が書けないと演習レポートを 提出できない。 システムソフトのスパルタ教育か!?
  9. 9. 「オペレーティングシステム」なる ものの偉大さに薄々気がつく。
  10. 10. 「割り込み待ちをしている間に計算 できるようにすれば,Time Sharing Systemというものが作れ るんだよ」(by 益田先生)
  11. 11. 私:「ニュートン法」というものを 使ってI/O中にsqrt(2)を計算 Before:「速いコンピュータを作っ て計算することそんなにあるの?」 After:「いくらでも仕事をさせら れるんだ」
  12. 12. 12 Go To Statement Considered Harmful (By E. Dijkstra) Go To Statement Considered Harmful Key Words and Phrases: go to statement, jump instruction, branch instruction, conditional clause, alternative clause, repet- itive clause, program intelligibility, program sequencing CR Categories: 4.22, 5.23, 5.24 EDITOR : For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. More recently I discovered why the use of the go to statement has such disastrous effects, and I became convinced that the go to state- ment should be abolished from all "higher level" programming languages (i.e.everything except, perhaps, plain machine Code). At'that time I did not attach too much importance to this dis- covery; I now submit my considerations for publication because in very recent discussions in which the subject turned up, I have been urged to do so. My firstremark is that, although the programmer's activity ends when he has constructed a correct program, the process taking place under control of his program is the true subject matter of his activity,for it is this process that has to accomplish the desired effect;it is this process that in its dynamic behavior has to satisfythe desired specifications.Yet, once the program has been made, the "making" of the corresponding process is dele- gated to the machine. My second remark is that our intellectualpowers are rather geared to master staticrelations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the cor- respondence between the program (spread out in text space) and the process (spread out in time) as trivialas possible. Let us now consider how we can characterize the progress of a process. (You may think about this question in a very concrete manner: suppose that a process, considered as a time succession of actions, is stopped after an arbitrary action, what data do we have to fix in order that we can redo the process until the very same point?) If the program text is a pure concatenation of, say, assignment statements (forthe purpose of thisdiscussion regarded as the descriptions of single actions) it issufficientto point in the program text to a point between two successive action descrip- tions. (In the absence of go to statements I can permit myself the syntactic ambiguity in the last three words of the previous sen- tence: if we parse them as "successive (action descriptions)" we mean successive in text space; if we parse as "(successive action) descriptions" we mean successive in time.) Let us call such a pointer to a suitable place in the text a "textual index." When we include conditional clauses (ifB then A), alternative clauses (if B then AZ else A2), choice clauses as introduced by C. A. R. Hoare (case[i]of(At, A2, ... ,An)), or conditional expres- sions as introduced by J. McCarthy (Bi -~ El, B2 --~E2, ... , Bn ---~En), the fact remains that the progress of the process re- mains characterized by a single textual index. As soon as we include in our language procedures we must admit that a single textual index is no longer sufficient.In the case that a textual index points to the interior of a procedure body the dynamic progress isonly characterized when we alsogive to which call of the procedure we refer.With the inclusion of procedures we can characterize the progress of the process via a sequence of textual indices, the length of this sequence being equal to the dynamic depth of procedure calling. Let us now consider repetitionclauses (like,while B repeat A or repeat A until B). Logically speaking, such clauses are now superfluous, because we can express repetition with the aid of recursive procedures. For reasons of realism I don't wish to ex- clude them: on the one hand, repetition clauses can be imple- mented quite comfortably with present day finite equipment; on the other hand, the reasoning pattern known as "induction" makes us well equipped to retain our intellectual grasp on the processes generated by repetition clauses. With the inclusion of the repetition clauses textual indices are no longer sufficient to describe the dynamic progress of the process. With each entry into a repetition clause, however, we can associate a so-called "dy- namic index," inexorably counting the ordinal number of the corresponding current repetition. As repetition clauses (just as procedure calls) may be applied nestedly, we find that now the progress of the process Can always be uniquely characterized by a (mixed) sequence of textual and/or dynamic indices. The main point is that the values of these indices are outside programmer's control; they are generated (either by the write-up of his program or by the dynamic evolution of the process) whether he wishes or not. They provide independent coordinates in which to describe the progress of the process. Why do we need such independent coordinates? The reason is--and this seems to be inherent to sequentiM processes--that we can interpret the value of a variable only with respect to the progress of the process. If we wish to count the number, n say, of people in an initially empty room, we can achieve this by increas- ing n by one whenever we see Someone entering the room. In the in-between moment that we have observed someone entering the room but have not yet performed the subsequent increase of n, its value equals the number of people in the room minus one! The unbridled use of the go to statement has an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress. Usually, people take into account as well the values of some well chosen variables, but this is out of the question because it is relative to the progress that the meaning of these values is to be understood l With the go to statement one can, of course, still describe the progress uniquely by a counter counting the number of actions performed since program start (viz. a kind of normalized clock). The difficulty is that such a coordinate, although unique, is utterly unhelpful. In such a coordinate system it becomes an extremely complicated affair to define all those points of progress where, say, n equals the number of persons in the room minus onet The go to statement as it stands is just too primitive; it is too much an invitation to make a mess of one's program. One can regard and appreciate the clauses considered as bridling its use. I do not claim that the clauses mentioned are exhaustive in the sense that/hey will satisfy all needs, but whatever clauses are suggested (e.g. abortion clauses) they should satisfy the requirement that a programmer independent coordinate system can be maintained to describe the process in a helpful and manageable way. It is hard to end this with a fair acknowledgment. Am I to Volume 11 / Number 3 / March, 1968 Communieations of the ACM I47 HTMLバージョンあり rubinson/ copyright_violations/ Go_To_Considered_Harmful.html
  13. 13. I/O Statement Considered Harmful (By K. Kato)
  14. 14. 1st ultimate virtualization of memory, file system and I/O Multics (1964-)
  15. 15. 15 Multics implemented a single level store for data access, discarding the clear distinction between files and process memory. . . . To read or write to them, the process simply used normal CPU instructions, and the operating system took care of making sure that all the modifications were saved to disk. Multics Segmentation Wikipedia: Multics
  16. 16. 理想と現実(Multics編) なぜOS研究者しか知らないのか? 「理想的」設計が当時のハードウェア,ソフトウェ ア技術を超えていた。 セグメンテーション技術は本当に必要だったか? mmap()として,部分実装が多くのOSに実装されて いる。共有ライブラリ。 SLSの概念はいずこ? プログラミング言語/DBレイヤで現実的に実現されて いる。 さまざまなpersistent/ORM framework (Hibernate, Ruby on Rails)
  17. 17. 17 File system ≒ I/O ≒ IPC (pipe) Unix (1969-) “Compromised virtualization” 理想より現実
  18. 18. 18 端末仮想化:/etc/termcap さまざまな端末がスクリーンエディタ(vi)に。 プリンタ仮想化:/etc/printcap さまざまなプリンタに清書印刷(nroff/troff)。 Unix自体が仮想マシン 移植可能な実用OS 仮想化とUnix
  19. 19. Task = space Thread = computation Memory object = memory Port = I/O and IPC Message = communication & Microkernel Mach (1985-): 2nd ultimate virtualization
  20. 20. Machの前身:Accent Robert P. Fitzgerald, Richard F. Rashid: The Integration of Virtual Memory Management and Interprocess Communication in Accent. ACM Trans. Comput. Syst. 4(2): 147-177 (1986) ! Robert P. Fitzgerald, Richard F. Rashid: The Integration of Virtual Memory Management and Interprocess Communication in Accent (Abstract). SOSP 1985: 13-14 ! Richard F. Rashid, George G. Robertson: Accent: A Communication Oriented Network Operating System Kernel. SOSP 1981: 64-75
  21. 21. 理想と現実(Mach & Accent編) なぜOS研究者しか知らないのか? another unixとして広まった。(Unix互換が活きた) (Cf. OSF/1 and Mac OS X) 高度なintegrationはOSレベルよりWebレベルで。
 マルチスレッドは今やどのOSでも。(CF. Win, Linux, Java) マイクロカーネル技術の礎となった。 プロセスマイグレーションはどこに行った? VMマイグレーション技術として生きている。
  22. 22. Distributed Shared Repository: A Unified Approach to Distribution and Persistency (Kato et al., ICDCS 1993) 分散環境におけるセグメンテーション。 スレッドまで永続化&マイグレーション可能。
  23. 23. Planet (←DSR) VM-integrated (native) mobile objects 23 K. Kato, et al.: An Approach to Mobile Software Robots for the WWW, IEEE Transactions on Knowledge and Data Engineering, Vol. 11, No. 4, pp. 526−548, 1999 July.
  24. 24. 異機種オブジェクトモビリティ(1/2) Machine architecture A Machine A
 native Compiler
 front-end Canonical-code
 generator Source
 program Machine architecture B Converter Canonical Converter Canonical Converter Unloading ... Object repository
  25. 25. 異機種オブジェクトモビリティ(2/2) Machine architecture A Compiler
 front-end Canonical-code
 generator Source
 program Machine architecture B Converter Canonical Converter Machine B
 native Converter Canonical Loading to B ... Object repository
  26. 26. 理想と現実(Planet編) なぜ多くの人が知らないのか? 高度なintegrationはOSレベルよりWebレベルで。 モバイルオブジェクト/エージェントはどこに行った? モバイルコードで十分であった。   そして,バイトコードよりスクリプトコードで。    Cf. JavaScript   状態はデータベースで保持。 VMマイグレーション技術として生きている。 人材輩出
  27. 27. 27 特許出願中「安全なソフトウェア流通システム」(2001国内,2002国際). SoftwarePotシステム:OS環境の仮想化 ローカル
 リソース アプリケーション 仮想計算環境 仮想ファイルシステム ファイルシステム ローカル
 リソース アプリケーション 仮想計算環境 仮想ファイルシステム ファイルシステム ファイルサーバ Skelton モニタ ソフトウェア作成者サイト ユーザサイト Policy 大山 恵弘,神田 勝規, 加藤 和彦:安全なソフトウエア実行システムSoftwarePotの設 計と実装,コンピュータソフトウエア, 日本ソフトウエア科学会,Vol. 16, No. 6, pp. 2­12, 2002年11月.平成15年度日本ソフトウエア科学会論文賞.
  28. 28. 28 US Patent of SoftwarePot 2002 filed, 2010 issued
  29. 29. 理想と現実(SoftwarePot編) なぜ社会で使われない? 壁1) 特許技術の「フリー」公開を国の某機関は渋った。 壁2) Win,Mac OS,Linux等のOSが採用してくれれば普 及する可能性はある。   …組織内利用からは一つの道か。
  30. 30. Socket Programming Considered Harmful (By K. Kato)
  31. 31. プログラム プログラム
 (サブルーチン) 手続き呼び出し
 (procedure call) 呼び出し側(クライアント側)
 プロセス Call Wait 呼び出され側(サーバ側)
 プロセス Receive Execute the body Call Message Receive Message 遠隔手続き呼び出し
 (remote procedure call) 31 RPC技術
  32. 32. クライアント プログラム インターフェース記述 サーバプログラム スタブ生成器 クライアントスタブ サーバスタブ コンパイラコンパイラ 実行時 ライブラリ リンカ クライアント実行可能コード サーバ実行可能コード リンカ コンパイラ コンパイラ ヘッダ情 報 ヘッダ情 報 呼び出し側(クライアント側)
 プロセス 呼び出され側(サーバ側)
 プロセス Caller Program Caller Stub/Proxy Caller Runtime Callee Program Callee Stub/Skelton Callee Runtime 1 2 3 4 56 7 89 10 RPC実行時機構 RPC言語処理 32
  33. 33. RPCの貢献と限界 OSレベル通信(ソケット通信)をアプリ・プログ ラマに意識させない。 手続き呼び出し,オブジェクトメソッド起動ができ れば,遠隔通信ができる。 透明性(仮想化)の限界: ポインタは?  高階関数(ブロックやクロージャ)は?
  34. 34. 高階関数&多相型RPC import TWICE : ∀t.(t → t) → t → t in let addone = λx.x + 1 in ((TWICE addone) 3) export λf. λx.(f (f x)) as TWICE [Ohori and Kato, POPL93]
  35. 35. 多相的RPCのための変換アルゴリズム(1/2)
  36. 36. 多相的RPCのための変換アルゴリズム(2/2)
  37. 37. 37 Schemeでの実装 (tvar-simplify (dml:tr '(import twice (forall t (-> (-> t t) (-> t t))) (*server* port) (((twice (enc-type "int")) addone) 3)))) ! ! (import twice (forall t (-> (-> t t) (-> t t))) (site port) (let twice (lambda (t) (lambda (?a) (lambda (?b) ((poly-decoder t) (rfc (rfc (rfc twice t) (makeid (lambda (?c) ((poly-encoder t) (?a ((poly-decoder t) ?c)))))) ((poly-encoder t) ?b)))))) (((twice int) addone) 3))) 変換前
 (入力) 変換後
  38. 38. 38 VM-Integrated RPC [Kono, Kato&Masuda, ICDCS 1994, ECOOP 1996]
  39. 39. 39 分散C言語 import ! struct item ! search(remote struct record *, int);! ! struct record table[TABLE_SIZE]! ...! caller ()! {! struct item r;! ...! r = search(table, key) @ CALLEE_ID;! ...! } ! export ! struct item ! search(remote struct record *table,
 int key)! {! struct record temp;! int h;! ! h = hash(key);! temp = table[h]; ! while (temp.key != key){! h = (h + 1) % TABLE_SIZE;! temp = table[h]; ! }! return temp.value;! } Caller (Client) Callee (Server) [加藤,大堀,村上,益田 コンピュータソフトウェア92] ポインタが分散透明に
 受け渡されていることに注意 遠隔参照
  40. 40. 理想と現実(拡張RPC編) なぜ社会で使われない? RPC,分散オブジェクトまでで「十分」であった模様。 分散性を徹底的に仮想化(透明化)したRPCしたニーズは 多くはなかった。   HPC分野ではMPIが未だに主流の模様。   密結合より疎結合。 スタブ生成技術の「形式的記述」には成功(したつもり)。 やればここまで出来るという技術の限界を延ばしたか。 (発表当時)
  41. 41. 41 アカデミアのジレンマ アカデミアは「究極」にやろうとする。  例)Multics, Planet, 拡張RPC,サステーナブルシ ステム。 アカデミアはbeauty/eleganceを好む。 アカデミアは新規性を好む。 ! 実用世界は究極,beauty/eleganceを求めない。 実用世界は安定的な/すぐに使える技術,コードを好 む。 実用世界は皆がやっていること(verified/matured/ 枯れた技術)を好む。
  42. 42. 42 アカデミアと実世界 アカデミアは「究極」を目指す職人だ。  究極の機能,性能,設計,理解   実世界は「社会」だ。 「社会」:生活空間を共有したり,相互に結びついた り,影響を与えあったりしている人々のまとまり。 (スーパー大辞林) !
  43. 43. セキュアVM BitVisor (2006∼)
  44. 44. 背景 ITシステムの脆弱性を突いた,深刻なセキュ リティ上の問題が発生 Webサーバの乗っ取りや停止 深刻な情報漏えい問題 政府・行政機関からの個人情報,機密情報の漏えい 民間企業からの個人情報、産業情報等の漏えい 44
  45. 45. 問題 サーバシステムをターゲットとしたセキュ リティ機能向上が図られてきたが... サーバシステムは,台数が限られ,専門家が集中的に管 理可能. サーバシステムは,セキュアOS機能を駆使した設定が可 能. 最近の問題はむしろクライアント 「事件は会議室(サーバー)で起きているんじゃない, 現場(クライアント)で起きているんだ」 45Thanks to「踊る大捜査線」
  46. 46. 目標 クライアント環境へ高セキュリティ機能を提供 したい. エンドユーザによる設定,操作をできるだけ簡 単にしたい. 共通汎用OS(Windows, Linux等)に適用可能と したい. 46
  47. 47. アプローチ 仮想機械技術に着眼 大型計算機システムにおいては1960年代より知られる技術. 近年,パソコンにおいても利用可能となってきた. 仮想機械をサポートするマイクロプロセッサが登場.
 (インテル社VT技術搭載CPUが2005年11月から発売された.その後,AMD社からも). 仮想機械レベルで可能なセキュリティ機能の導入 47 ハードウェア OS アプリケーション ハードウェア OS アプリケーション 仮想機械
  48. 48. セキュア仮想マシンBitVisor !"#$%&'(! )*+,-.! /01234! 5617*89:!01;*<9:! =>9:! ?@AB9:! CDE!FGH! CII2J.! )*+,-.!"H! • ストレージ管理 ✓ HDD及びUSBメモリの暗号化 • ネットワーク管理 ✓ IPsecによるVPN接続 • ID管理 ✓ ICカードによる鍵管理・認証 • VMMコア ✓ CPU及びメモリの仮想化 48
  49. 49. チャレンジ •限られた時間とマンパワー 実質2年半 •フルスクラッチ •デバイスドライバの取扱い 入出力機器(デバイス)ドライバの仮想化 •ゲストOSとしてLinux & Windows XP/Vista •抑制されたソースコード量とオーバーヘッド 開発の効率化 検証の容易化 49
  50. 50. 準パススルー型アーキテクチャ 基本はI/Oをパススルー ゲストOSがデバイスを制御 最小限のI/Oを監視・変換 制御I/Oの監視 - デバイスの状態把握 - VMMに対するアクセス制御 データI/Oの変換 - ストレージ・ネットワーク暗 号化 VMM: BitVisor ハードウェア ゲストOS デバイス デバイスドライバ 準パススルー! ドライバ 監視 変換 制御I/O データI/O セキュリティ機能
  51. 51. 主要開発メンバー 筑波大学 加藤和彦(教授) 品川高廣(講師) 新城靖(准教授) 榮樂英樹(研究員) 面 和成(研究員,富士通) 谷本 幸一(研究員,日立) 長谷川 晶一(研究員,NEC) 保理江 高志(研究員,NTTデータ) セキュアVM開発室(秋葉原) 大山恵弘(准教授) 電気通信大学 河野健二(准教授) 慶應義塾大学 光来健一(助手) 千葉滋(准教授) 東京工業大学 関浩之(教授) 河合栄治(特任准教授) 八木勲(特任助教) 奈良先端科学技術 大学院大学 資源管理機構 通信管理機構 豊田高専 ID管理機構 セキュリティ 整合性 VM機構 平野学(助手) 全体の統括と開発 内閣官房 情報セキュリティセンター 総務省 NICT 経産省 IPA インテル NTTコミュニケーションズ ソフトイーサ イーゲル 協力組織 •面氏(富士通)が退任し,北陸先端大へ移動 •面氏の後任として宗氏(富士通)着任 •光来氏が九工大准教授へ転任 •千葉氏が教授に昇任 人事異動 51
  52. 52. 運営委員会(半年に1回開催) 加藤 和彦  筑波大学 教授(委員長) 品川 高廣  筑波大学 講師 大山 恵弘  電気通信大学 准教授 河野 健二  慶應義塾大学 准教授 光来 健一  九州工業大学 准教授 千葉 滋   東京工業大学 教授 関 浩之   奈良先端科学技術大学院大学 教授 平野 学   豊田工業高等専門学校 助教 山口 英   内閣官房 情報セキュリティセンター        情報セキュリティ補佐官        奈良先端科学技術大学院大学 教授 大久保 明  内閣府 政策統括官        新井 孝雄  総務省 情報通信政策局        情報セキュリティ対策室長 ! 八尋 俊英  経済産業省 商務情報政策局        情報処理振興課長 ! 篠田 陽一  情報通信研究機構(NICT)        情報通信セキュリティ研究センター長 ! 田代 秀一  情報処理推進機構(IPA)        オープンソースソフトウェアセンター長 ! 坂村 健   YRPユビキタス・ネットワーキング研究所長        東京大学 教授 石川 裕   プログラムオフィサー(研究領域主管)/ 東京大学 教授 田浦 健次郎 プログラムオフィサー(研究領域主管)/ 東京大学 准教授 落合 幸徳  プログラムオフィサー(プログラム主管) 林原 光男  プログラムオフィサー(プログラム主管) 北村 義男  主任調査員 科学技術振興機構(JST) 52
  53. 53. 日経ITpro (09/3/19)
  54. 54. 理想と現実(BitVisor編) 苦労 ブラックボックスなるWindows (XP)を必須で動かす。   (Mr. Intel君という希望) 「(人を)出さないんじゃないんです。本当にいないんで す。」 日本語ドキュメントを探すと1990年代までしかない。 膨大なインテル・ドキュメントのどこを読めばいいか。 米国とは一桁違う開発規模(予算,人員) 使われているか? 大規模政府調達は容易でない。 手が入れられる規模(量,複雑度)のVMM。 国内開発者コミュニティ。
  55. 55. BitVisorの活用 • ゲストOSのシステムファイル保護 • 透過的VPN切り替え • 透明なネットワークブートシステム • ゲストOS起動高速化 • VMM内空き時間利用計算 55
  56. 56. BitVisor as Research Platform • HyperSafe [Wang et al., IEEE S&P ‘10] ✓ Integrity of hypervisor itself, i.e., modification disabled. • “Return-less” VMM [Li et al., EuroSys ‘10] ✓ Against ROR (Return-Oriented Rootkit) • TCVisor [Rezaei et al., ICITST ‘10] ✓ Limited storage area can be seen by each user. 56
  57. 57. 57
  58. 58. 58 BitVisor Summit 2012/12/4
  59. 59. 59 BitVisor Summit 2012/12/4 発表:2件(BitVisor開発者)+7件(活用開発者) ! ドライバ保護,マルウェア解析・検出 ! 動画像著作権保護,広告&メッセージ表示システム ADvisor,Twitter ! その他:ネットワークブート,ボランティアコンピュー ティング
  60. 60. 60 もの作りの心 やりたいから,やる。 ! 止められても,やっぱりやる。 ! やりたいと思う心がエネルギー,持続性を生む。 ! プログラマも人間,霞を食っては生きていけません が? ! 仕事も趣味も,一生懸命にやると道が開けてくるこ とがあるようです。やる気を持続できるかポイント のよう。