仮想化とシステムソフトウェア研究
?
0 likes?2,343 views
情報処理学会主催 コンピュータシステムシンポジウム 基調講演（2012年12月6日） http://www.ipsj.or.jp/kenkyukai/event/ComSys2012.html
![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バージョンあり ?
http://www.u.arizona.edu/ rubinson/
copyright_violations/
Go_To_Considered_Harmful.html](https://image.slidesharecdn.com/121206-comsys2012-140812011505-phpapp01/85/-12-320.jpg)
![高階関数＆多相型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]](https://image.slidesharecdn.com/121206-comsys2012-140812011505-phpapp01/85/-34-320.jpg)
![38
VM-Integrated RPC
[Kono, Kato&Masuda, ICDCS 1994, ECOOP 1996]](https://image.slidesharecdn.com/121206-comsys2012-140812011505-phpapp01/85/-38-320.jpg)
![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]
ポインタが分散透明に?
受け渡されていることに注意
遠隔参照](https://image.slidesharecdn.com/121206-comsys2012-140812011505-phpapp01/85/-39-320.jpg)
![BitVisor as Research Platform
? HyperSafe [Wang et al., IEEE S&P ‘10]
? Integrity of hypervisor itself, i.e., modi?cation
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](https://image.slidesharecdn.com/121206-comsys2012-140812011505-phpapp01/85/-56-320.jpg)
仮想化とシステムソフトウェア研究
- 1. ComSys 2012 基調講演 仮想化とシステムソフトウェア研究 加藤 和彦 筑波大学 システム情報工学研究科 2012年12月6日
- 4. 筑波大学第3学群情報学類1年次必修科目 情報科学概論IA by 益田隆司 先生 筑波大学電子?情報工学系 助教授（1981年当时）
- 8. アセンブラ?プラグラミング，一年間。 OSなし。 タイピュータ出力は割り込み処理ルーチン を自分で書く。 割り込み処理が書けないと演習レポートを 提出できない。 システムソフトのスパルタ教育か！？
- 11. 私：「ニュートン法」というものを 使ってI/O中にsqrt(2)を計算 Before：「速いコンピュータを作っ て計算することそんなにあるの？」 After：「いくらでも仕事をさせら れるんだ」
- 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バージョンあり ? http://www.u.arizona.edu/ rubinson/ copyright_violations/ Go_To_Considered_Harmful.html
- 13. I/O Statement Considered Harmful (By K. Kato)
- 14. 1st ultimate virtualization of memory, ?le system and I/O Multics (1964-)
- 15. 15 Multics implemented a single level store for data access, discarding the clear distinction between ?les 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 modi?cations were saved to disk. Multics Segmentation Wikipedia: Multics
- 17. 17 File system ≒ I/O ≒ IPC (pipe) Unix (1969-) “Compromised virtualization” 理想より現実
- 19. Task = space Thread = computation Memory object = memory Port = I/O and IPC Message = communication & Microkernel Mach (1985-): 2nd ultimate virtualization
- 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. 理想と現実(Mach & Accent編) なぜOS研究者しか知らないのか？ another unixとして広まった。(Unix互換が活きた) （Cf. OSF/1 and Mac OS X） 高度なintegrationはOSレベルよりWebレベルで。? マルチスレッドは今やどのOSでも。(CF. Win, Linux, Java) マイクロカーネル技術の礎となった。 プロセスマイグレーションはどこに行った？ VMマイグレーション技術として生きている。
- 22. Distributed Shared Repository: A Uni?ed Approach to Distribution and Persistency (Kato et al., ICDCS 1993) 分散環境におけるセグメンテーション。 スレッドまで永続化＆マイグレーション可能。
- 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. 異機種オブジェクトモビリティ(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. 異機種オブジェクトモビリティ(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
- 27. 27 特許出願中「安全なソフトウェア流通システム」(2001国内，2002国際)． SoftwarePotシステム：OS環境の仮想化 ローカル? リソース アプリケーション 仮想計算環境 仮想ファイルシステム ファイルシステム ローカル? リソース アプリケーション 仮想計算環境 仮想ファイルシステム ファイルシステム ファイルサーバ Skelton モニタ ソフトウェア作成者サイト ユーザサイト Policy 大山 恵弘,神田 勝規, 加藤 和彦：安全なソフトウエア実行システムSoftwarePotの設 計と実装，コンピュータソフトウエア, 日本ソフトウエア科学会，Vol. 16, No. 6, pp. 2?12, 2002年11月．平成15年度日本ソフトウエア科学会論文賞．
- 28. 28 US Patent of SoftwarePot 2002 ?led, 2010 issued
- 29. 理想と現実(SoftwarePot編) なぜ社会で使われない？ 壁1) 特許技術の「フリー」公開を国の某機関は渋った。 壁2) Win，Mac OS，Linux等のOSが採用してくれれば普 及する可能性はある。 ??…組織内利用からは一つの道か。
- 30. Socket Programming Considered Harmful (By K. Kato)
- 31. プログラム プログラム? （サブルーチン） 手続き呼び出し? (procedure call) 呼び出し側（クライアント側）? プロセス Call Wait 呼び出され側（サーバ側）? プロセス Receive Execute the body Call Message Receive Message 遠隔手続き呼び出し? (remote procedure call) 31 RPC技術
- 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
- 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]
- 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 VM-Integrated RPC [Kono, Kato&Masuda, ICDCS 1994, ECOOP 1996]
- 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] ポインタが分散透明に? 受け渡されていることに注意 遠隔参照
- 46. 目標 クライアント環境へ高セキュリティ機能を提供 したい． エンドユーザによる設定，操作をできるだけ簡 単にしたい． 共通汎用OS(Windows, Linux等)に適用可能と したい． 46
- 48. セキュア仮想マシンBitVisor !"#$%&'(! )*+,-.! /01234! 5617*89:!01;*<9:! =>9:! ?@AB9:! CDE!FGH! CII2J.! )*+,-.!"H! ? ストレージ管理 ? HDD及びUSBメモリの暗号化 ? ネットワーク管理 ? IPsecによるVPN接続 ? ID管理 ? ICカードによる鍵管理?認証 ? VMMコア ? CPU及びメモリの仮想化 48
- 49. チャレンジ ?限られた時間とマンパワー 実質2年半 ?フルスクラッチ ?デバイスドライバの取扱い 入出力機器（デバイス）ドライバの仮想化 ?ゲストOSとしてLinux & Windows XP/Vista ?抑制されたソースコード量とオーバーヘッド 開発の効率化 検証の容易化 49
- 50. 準パススルー型アーキテクチャ 基本はI/Oをパススルー ゲストOSがデバイスを制御 最小限のI/Oを監視?変換 制御I/Oの監視 - デバイスの状態把握 - VMMに対するアクセス制御 データI/Oの変換 - ストレージ?ネットワーク暗 号化 VMM: BitVisor ハードウェア ゲストＯＳ デバイス デバイスドライバ 準パススルー! ドライバ 監視 変換 制御I/O データI/O セキュリティ機能
- 51. 主要開発メンバー 筑波大学 加藤和彦（教授） 品川高廣（講師） 新城靖（准教授） 榮樂英樹（研究員） 面 和成（研究員，富士通） 谷本 幸一（研究員，日立） 長谷川 晶一（研究員，NEC） 保理江 高志（研究員，NTTデータ） セキュアVM開発室（秋葉原） 大山恵弘（准教授） 電気通信大学 河野健二（准教授） 慶應義塾大学 光来健一（助手） 千葉滋（准教授） 東京工業大学 関浩之（教授） 河合栄治（特任准教授） 八木勲（特任助教） 奈良先端科学技術 大学院大学 資源管理機構 通信管理機構 豊田高専 ID管理機構 セキュリティ 整合性 VM機構 平野学（助手） 全体の統括と開発 内閣官房 情報セキュリティセンター 総務省 NICT 経産省 IPA インテル NTTコミュニケーションズ ソフトイーサ イーゲル 協力組織 ?面氏（富士通）が退任し，北陸先端大へ移動 ?面氏の後任として宗氏（富士通）着任 ?光来氏が九工大准教授へ転任 ?千葉氏が教授に昇任 人事異動 51
- 52. 運営委員会（半年に1回開催） 加藤 和彦??筑波大学 教授（委員長） 品川 高廣??筑波大学 講師 大山 恵弘??電気通信大学 准教授 河野 健二??慶應義塾大学 准教授 光来 健一??九州工業大学 准教授 千葉 滋???東京工業大学 教授 関 浩之???奈良先端科学技術大学院大学 教授 平野 学???豊田工業高等専門学校 助教 山口 英???内閣官房 情報セキュリティセンター ?????? 情報セキュリティ補佐官 ?????? 奈良先端科学技術大学院大学 教授 大久保 明??内閣府 政策統括官 ?????? 新井 孝雄??総務省 情報通信政策局 ?????? 情報セキュリティ対策室長 ! 八尋 俊英??経済産業省 商務情報政策局 ?????? 情報処理振興課長 ! 篠田 陽一??情報通信研究機構(NICT) ?????? 情報通信セキュリティ研究センター長 ! 田代 秀一??情報処理推進機構(IPA) ?????? オープンソースソフトウェアセンター長 ! 坂村 健???YRPユビキタス?ネットワーキング研究所長 ?????? 東京大学 教授 石川 裕???プログラムオフィサー（研究領域主管）／ 東京大学 教授 田浦 健次郎?プログラムオフィサー（研究領域主管）／ 東京大学 准教授 落合 幸徳??プログラムオフィサー（プログラム主管） 林原 光男??プログラムオフィサー（プログラム主管） 北村 義男??主任調査員 科学技術振興機構(JST) 52
- 55. BitVisorの活用 ? ゲストOSのシステムファイル保護 ? 透過的VPN切り替え ? 透明なネットワークブートシステム ? ゲストOS起動高速化 ? VMM内空き時間利用計算 55
- 56. BitVisor as Research Platform ? HyperSafe [Wang et al., IEEE S&P ‘10] ? Integrity of hypervisor itself, i.e., modi?cation 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