知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6913636
(24)【登録日】2021年7月14日
(45)【発行日】2021年8月4日
(54)【発明の名称】共有ページ
(51)【国際特許分類】
G06F 12/14 20060101AFI20210727BHJP
【ＦＩ】
G06F12/14 510E
【請求項の数】7
【全頁数】33
(21)【出願番号】特願2017-564099(P2017-564099)
(86)(22)【出願日】2016年4月26日
(65)【公表番号】特表2018-523210(P2018-523210A)
(43)【公表日】2018年8月16日
(86)【国際出願番号】GB2016051168
(87)【国際公開番号】WO2016203190
(87)【国際公開日】20161222
【審査請求日】2019年4月19日
(31)【優先権主張番号】1510533.1
(32)【優先日】2015年6月16日
(33)【優先権主張国】GB
(73)【特許権者】
【識別番号】504394342
【氏名又は名称】アーム・リミテッド
(74)【代理人】
【識別番号】110000855
【氏名又は名称】特許業務法人浅村特許事務所
(72)【発明者】
【氏名】パーカー、ジェイソン
(72)【発明者】
【氏名】グリセンスウェイト、リチャード ロイ
(72)【発明者】
【氏名】ローズ、アンドリュー クリストファー
【審査官】
平井 誠
(56)【参考文献】
【文献】
特表２０１４−５３２２０１（ＪＰ，Ａ）
(58)【調査した分野】（Int.Cl.，ＤＢ名）
Ｇ０６Ｆ １２／１４
Ｇ０６Ｆ ２１／００−８８
(57)【特許請求の範囲】
【請求項1】
所定のメモリ領域が、複数のプロセスの中から所有権テーブルにおいて指定された所定の所有プロセスを有し、前記所定の所有プロセスが、前記所定のメモリ領域へのアクセスを制御する排他的な権利を有する、物理メモリアドレス空間内のメモリ領域の所有権利を行使する所有権回路を備え、
前記所有権テーブルは、物理メモリアドレス空間の領域にそれぞれ対応し物理メモリアドレス空間のその領域に対する所定の所有プロセスを指定する複数のエントリを備え、
メモリアクセス要求に応答して、前記所有権回路は、メモリアクセス要求の対象物理アドレスに基づいて前記所有権テーブルを検索するように構成され、
前記所定の所有プロセスが、前記所定のメモリ領域を、
前記所定の所有プロセスに対してプライベートであること、及び
前記所定の所有プロセスと、メモリアクセス要求の少なくとも１つの更なるソースとの間で共有されること、
のうちの１つとして指定する、データを処理する装置。
前記所有権テーブルは、物理メモリアドレス空間の領域にそれぞれ対応し物理メモリアドレス空間のその領域に対する所定の所有プロセスを指定する複数のエントリを備え、
メモリアクセス要求に応答して、前記所有権回路は、メモリアクセス要求の対象物理アドレスに基づいて前記所有権テーブルを検索するように構成され、
前記所定の所有プロセスが、前記所定のメモリ領域を、
前記所定の所有プロセスに対してプライベートであること、及び
前記所定の所有プロセスと、メモリアクセス要求の少なくとも１つの更なるソースとの間で共有されること、
のうちの１つとして指定する、データを処理する装置。
【請求項2】
前記所定の所有プロセスと、
メモリ領域内にマッピングされしかも前記所定の所有プロセスによって所有される１つ以上のバスマスタリング装置、
前記所定のメモリ領域の所有権を前記所定の所有プロセスに移した親プロセス、
前記所定の所有プロセスによる前記所定のメモリ領域の所有権より前の、前記所定のメモリ領域の所有権を移した前記所定の所有プロセスの先祖プロセス、及び
任意の他のプロセス、
のうちの１つとの間で共有されるものの１つとして共有される場合に、前記所定の所有プロセスが前記所定のメモリ領域を指定する、請求項１に記載の装置。
メモリ領域内にマッピングされしかも前記所定の所有プロセスによって所有される１つ以上のバスマスタリング装置、
前記所定のメモリ領域の所有権を前記所定の所有プロセスに移した親プロセス、
前記所定の所有プロセスによる前記所定のメモリ領域の所有権より前の、前記所定のメモリ領域の所有権を移した前記所定の所有プロセスの先祖プロセス、及び
任意の他のプロセス、
のうちの１つとの間で共有されるものの１つとして共有される場合に、前記所定の所有プロセスが前記所定のメモリ領域を指定する、請求項１に記載の装置。
【請求項3】
前記所有権回路が、前記所定の所有プロセスよりも高い特権レベルを有するプロセスによる前記所定のメモリ領域へのアクセスを前記所定の所有プロセスが拒否することを許可する、請求項１又は２に記載の装置。
【請求項4】
前記所定のメモリ領域を新たな所定の所有プロセスに割り当てることには、前記新たな所定の所有プロセスが前記排他的な権利を取得する前に、前記所定のメモリ領域内に格納されたデータを破壊的に上書きすることが含まれる、請求項１〜３のいずれか一項に記載の装置。
【請求項5】
前記破壊的な上書きが前記新たな所定の所有プロセスによって行われ、前記新たな所定の所有プロセスが前記排他的な権利を取得する前に前記上書きが確実に完了するように、上書き追跡ハードウェアが前記上書きの完了を追跡する、請求項４に記載の装置。
【請求項6】
所定のメモリ領域が、複数のプロセスの中から所有権テーブルにおいて指定された所定の所有プロセスを有し、前記所定の所有プロセスが、前記所定のメモリ領域へのアクセスを制御する排他的な権利を有する、物理メモリアドレス空間内のメモリ領域の所有権利を行使する所有権手段を備え、
前記所有権テーブルは、物理メモリアドレス空間の領域にそれぞれ対応し物理メモリアドレス空間のその領域に対する所定の所有プロセスを指定する複数のエントリを備え、
メモリアクセス要求に応答して、前記所有権手段は、メモリアクセス要求の対象物理アドレスに基づいて前記所有権テーブルを検索するように構成され、
前記所定の所有プロセスが、前記所定のメモリ領域を、
前記所定の所有プロセスに対してプライベートであること、及び
前記所定の所有プロセスと、メモリアクセス要求の少なくとも１つの更なるソースとの間で共有されること、
のうちの１つとして指定する、データを処理する装置。
前記所有権テーブルは、物理メモリアドレス空間の領域にそれぞれ対応し物理メモリアドレス空間のその領域に対する所定の所有プロセスを指定する複数のエントリを備え、
メモリアクセス要求に応答して、前記所有権手段は、メモリアクセス要求の対象物理アドレスに基づいて前記所有権テーブルを検索するように構成され、
前記所定の所有プロセスが、前記所定のメモリ領域を、
前記所定の所有プロセスに対してプライベートであること、及び
前記所定の所有プロセスと、メモリアクセス要求の少なくとも１つの更なるソースとの間で共有されること、
のうちの１つとして指定する、データを処理する装置。
【請求項7】
所定のメモリ領域が、複数のプロセスの中から所有権テーブルにおいて指定された所定の所有プロセスを有し、前記所定の所有プロセスが、前記所定のメモリ領域へのアクセスを制御する排他的な権利を有する、物理メモリアドレス空間内のメモリ領域の所有権利を所有権回路によって行使することを含み、
前記所有権テーブルは、物理メモリアドレス空間の領域にそれぞれ対応し物理メモリアドレス空間のその領域に対する所定の所有プロセスを指定する複数のエントリを備え、
メモリアクセス要求に応答して、前記所有権回路は、メモリアクセス要求の対象物理アドレスに基づいて前記所有権テーブルを検索するように構成され、
前記所定の所有プロセスが、前記所定のメモリ領域を、
前記所定の所有プロセスに対してプライベートであること、及び
前記所定の所有プロセスと、メモリアクセス要求の少なくとも１つの更なるソースとの間で共有されること、
のうちの１つとして指定する、データを処理する方法。
前記所有権テーブルは、物理メモリアドレス空間の領域にそれぞれ対応し物理メモリアドレス空間のその領域に対する所定の所有プロセスを指定する複数のエントリを備え、
メモリアクセス要求に応答して、前記所有権回路は、メモリアクセス要求の対象物理アドレスに基づいて前記所有権テーブルを検索するように構成され、
前記所定の所有プロセスが、前記所定のメモリ領域を、
前記所定の所有プロセスに対してプライベートであること、及び
前記所定の所有プロセスと、メモリアクセス要求の少なくとも１つの更なるソースとの間で共有されること、
のうちの１つとして指定する、データを処理する方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示はデータ処理システムの分野に関する。
【背景技術】
【0002】
１つ以上のゲスト実行環境の仮想化をサポートするデータ処理システムの提供が知られている。一例としては、それ自体がゲストオペレーティングシステムと１つ以上のゲストアプリケーションプログラムとを含みうる１つ以上のゲスト実行環境の実行を制御し且つスケジュールするハイパーバイザを用いたデータ処理システムの提供が知られている。こうしたシステムを少なくとも使用する間は、所定のゲスト実行環境のデータ（場合により機密データ）が、そのシステム内の他のプロセスによるアクセスから保護されることが望ましい。
【発明の概要】
【課題を解決するための手段】
【0003】
本開示の少なくとも幾つかの実施形態は、所定のメモリ領域が、特権レベルに関わらず、複数のプロセスの中から指定された所定の所有プロセスを有し、所定の所有プロセスが、所定のメモリ領域へのアクセスを制御する排他的な権利を有する、物理メモリアドレス空間内のメモリ領域の所有権利を行使する所有権回路を備え、
所定の所有プロセスが、所定のメモリ領域を、
所定の所有プロセスに対してプライベートであること、及び
所定の所有プロセスと、メモリアクセス要求の少なくとも１つの更なるソースとの間で共有されること
のうちの１つとして指定する、データを処理する装置を提供する。
【0004】
本開示の少なくとも幾つかの更なる実施形態は、所定のメモリ領域が、特権レベルに関わらず、複数のプロセスの中から指定された所定の所有プロセスを有し、所定の所有プロセスが、所定のメモリ領域へのアクセスを制御する排他的な権利を有する、物理メモリアドレス空間内のメモリ領域の所有権利を行使する所有権手段を備え、
所定の所有プロセスが、所定のメモリ領域を、
所定の所有プロセスに対してプライベートであること、及び
所定の所有プロセスと、メモリアクセス要求の少なくとも１つの更なるソースとの間で共有されること
のうちの１つとして指定する、データを処理する装置を提供する。
【0005】
本開示の少なくとも幾つかの更なる実施形態は、所定のメモリ領域が、特権レベルに関わらず、複数のプロセスの中から指定された所定の所有プロセスを有し、所定の所有プロセスが、所定のメモリ領域へのアクセスを制御する排他的な権利を有する、物理メモリアドレス空間内のメモリ領域の所有権利を行使することを含み、
所定の所有プロセスが、所定のメモリ領域を、
所定の所有プロセスに対してプライベートであること、及び
所定の所有プロセスと、メモリアクセス要求の少なくとも１つの更なるソースとの間で共有されることのうちの１つとして指定する、データを処理する方法を提供する。
【0006】
本技術の更なる態様、特徴及び利点が、添付の図面と併せて読まれる以下の例の説明から明らかとなろう。
【図面の簡単な説明】
【0007】
【図1】処理装置によって実行されるプロセスの例を概略的に示す。
【図2】データ処理装置の例を示す。
【図3】データストア内のデータにアクセスするためのアクセス要求の承認の例を概略的に示す。
【図4】データ処理装置の異なるポイントにおけるトランザクションの例を示す。
【図5】アクセス要求を承認する方法の例を示す。
【図6】物理アドレスの対応するページの所有権を要求するための要求プロセスの方法の例を示す。
【図7】上書きプロセスの例を示す。
【図8】所有権テーブル内の属性を更新する例を示す。
【図9】ルックアサイドバッファ内のエントリを無効化する命令の例を示す。
【図10】ゲスト実行環境の安全な初期化を概略的に示す。
【図11】物理メモリアドレス空間のページの所有権を破壊的に請求するプロセスを概略的に示すフロー図。
【図12】ハイパーバイザ及び複数のゲスト実行環境をサポートするハードウェアシステムを概略的に示す。
【図13】ハイパーバイザとセキュリティ制御部と複数のゲスト実行環境との関係を概略的に示す。
【図14】物理メモリアドレス空間のページの様々な共有状態を概略的に示す。
【図15】共有許可の変更要求への対応を概略的に示すフロー図。
【図16A】実行コンテキストの切り替えを概略的に示すフロー図。
【図16B】実行コンテキストの切り替えを概略的に示すフロー図。
【図17】プロセス記述子エントリの例を概略的に示す。
【図18】プロセスステータス状態を概略的に示す。
【発明を実施するための形態】
【0008】
本技術の幾つかの具体例を以下に説明する。
【0009】
図１は、データ処理装置によって実行できるプロセスの例を概略的に示す。ハイパーバイザ２が幾つかの仮想マシン（ゲストオペレーティングシステム又はゲストＯＳとしても知られる、ＶＭ）４を管理できる。各ＶＭ４は１つ以上のアプリケーション６を管理できる。例えば、ハイパーバイザ２は、例えば各仮想マシン４間の時分割処理リソースへの割り込みをスケジュールする等、アドレス空間のどの領域を各仮想マシン４に割り当てるかの制御及び仮想マシン４間の切り替えの制御ができる。同様に、各ＶＭ４は、アドレス空間のどの領域を、ＶＭ４の下で実行される各アプリケーション６に割り当てるかを制御でき、また、必要に応じてアプリケーション間の切り替えを制御できる。
【0010】
図１に示すように、各プロセスは、所定の特権レベルＥＬ０，ＥＬ１，ＥＬ２及びＥＬ３と関連付けられている。この例では大きい数字の特権レベルの方が小さい数字の特権レベルよりも優先されるが、他の例では数字が逆に割り振られてもよい。この例では、アプリケーション６が特権レベルＥＬ０で実行され、ＶＭ４が特権レベルＥＬ１で実行され、ハイパーバイザ２が特権レベルＥＬ２で実行される。通常、高い特権レベルで実行されるプロセスは、低い特権レベルで実行されるプロセスには得られない権利を有する。
【0011】
図１に示すように、ハイパーバイザ２、ＶＭ４及びアプリケーション６は、正規ドメインで動作できる。また、装置は、セキュアドメインをサポートしており、そのセキュアドメインは、正規ドメインで実行されるプロセスが、セキュアドメインと関連付けられたデータ又は命令にアクセスできないように、正規ドメインから分離されている。これにより、セキュアオペレーティングシステム（ＯＳ）１０や、セキュアドメイン内でセキュアＯＳ１０の制御下で実行される信頼アプリケーション（「トラステッドアプリケーション(Trusted Application)」とも言う）１２といった、セキュアドメイン内で動作するプロセスも存在できる。セキュアＯＳ１０及び信頼アプリケーション(信頼app)１２は、それぞれ特権レベルＳ−ＥＬ１及びＳ−ＥＬ０で実行される。また、セキュアモニタープロセス１４が特権レベルＥＬ３に設けられ、正規ドメインとセキュアドメインとの間の移行を管理する。セキュアモニタープロセス１４は、例えば、正規ドメイン内の非セキュアプロセスがセキュア領域内のデータ又は命令にアクセスするのを防止する或る保護ハードウェアが設けられることで、アドレス空間のどの領域をセキュアドメイン又は非セキュアドメインと関連付けるかを管理できる。正規ドメインとセキュアドメインとを分離する技術の例としては、英国ケンブリッジのＡＲＭ（登録商標） Ｌｉｍｉｔｅｄ社が提供するＴｒｕｓｔＺｏｎｅ（登録商標）技術があるが、他の例が使用されてもよい。図１に示すようなセキュアドメインの提供は任意であり、例えば他の実施形態ではセキュアモニター１４、セキュアＯＳ１０及び信頼アプリケーション１２がサポートされなくてもよい。
【0012】
プロセス２，４，６，１０，１２及び１４は、それぞれ仮想アドレス（ＶＡ）を用いて、メモリ等のデータストア内でアクセスされるロケーションを識別する。ＶＡは、対応するストレージロケーションを直接的に識別する物理アドレス（ＰＡ）へと変換される。アプリケーション６又は仮想マシン４については、まずＶＡが中間物理アドレス（ＩＰＡ）へと変換され、そのＩＰＡがＰＡへと変換される。２段階のアドレス変換を設けることで、例えば、仮想マシン４は、ＶＡからＩＰＡへの変換用のページテーブルを制御して、アドレス空間のどの部分が各アプリケーション(App)６に割り当てられるかを制御でき、ハイパーバイザ２は、ＩＰＡからＰＡへの変換用のページテーブルを制御して、アドレス空間のどの部分が各仮想マシン４に割り当てられるかを制御できる。他のプロセス２，１４，１０及び１２については、ＶＡは、例えば各プロセスがアドレス空間のどの部分にアクセスできるかを制御するページテーブルを制御する（正規ドメイン内の）ハイパーバイザ２又は（セキュアドメイン内の）セキュアＯＳ１０によって、直接ＰＡへと変換される。
【0013】
従って、データ処理装置によって実行できる幾つかのプロセスが存在してもよい。通常のシステムでは、アドレス空間へのアクセスに対する制御は、高い特権レベルにあるプロセスが、低い特権レベルのプロセスがどのアドレスにアクセスできるかを制御する、「トップダウン」の手法で管理される。例えば、ＥＬ２にあるハイパーバイザ２は、ＥＬ１にある仮想マシン４がどのアドレスにアクセスできるかを定義するアクセス許可を設定する。しかしながら、高い特権レベルで動作するプロセスは、通常、その下の低い特権レベルで動作する各プロセスと関連付けられた全てのアドレスに対して読み取り又は書き込みができる。これにより、低い特権レベルで動作するプロセスのデベロッパーにとっては、セキュリティの問題が生じることがある。例えば、様々なパーティーによって提供された幾つかの仮想マシン４が実装されたクラウドプラットフォームにおいて、パーティーの１つが、クラウドオペレータといった他のパーティーが提供したハイパーバイザ２に対して仮想マシン４と関連付けられたデータ又はコードが露出されることを防ぎたい場合がある。
【0014】
本願は、所定の仮想マシン４と関連付けられた全てのデータを必ずしも見ることができなくても、仮想マシン４を管理し且つアドレス空間のどの部分にアクセスできるかを制御する「ブラインドハイパーバイザ」の概念を導入する。同様に、他の特権レベルで動作するプロセスについても、高い特権レベルで動作するプロセスが低い特権レベルで動作するプロセスが使用するアドレスにアクセスするのを防止できる。
【0015】
図２は、命令に応じてデータを処理する幾つかの処理回路を含む幾つかのバスマスターを備えたデータ処理装置２０の例を示す。この例では、処理回路は２つの中央処理装置（ＣＰＵ）２４と、グラフィック処理装置（ＧＰＵ）２５と、以下に説明されるような特定のセキュリティ機能を管理するための専用の処理装置であるセキュリティコンプレックス２８とを含む。また、バスマスターは、例えばダイレクトメモリアクセス（ＤＭＡ）制御部２６、又は外部装置へのデータの入力若しくは出力を制御する（図２には示されていない）入出力（Ｉ／Ｏ）インターフェースといった、処理回路の１つの代わりに処理タスクを実行できる他の装置も含む。なお、他の種類のマスター装置を設けてもよいことは理解されよう。システムバス３０は、バスマスターのそれぞれを、メモリ３４へのアクセスを制御するメモリ制御部（ＤＭＣ）３２に接続する。この例では、メモリはダイナミックランダムアクセスメモリ（ＤＲＡＭ）を用いて実装されるが、他の形態のメモリ又は他の種類のデータストアも設けられることが理解されよう。各バスマスター２４，２５，２６及び２８は、バス３０を介してメモリ制御部３２にデータアクセストランザクション（読み取り又は書き込み）を発行し、制御部はメモリ３４を制御してトランザクションを利用可能にする。
【0016】
幾つかのキャッシュ３６が、処理回路２４及び２５のローカルなデータ又は命令をキャッシュするように設けられる。ＣＰＵ２４は、それぞれが自身のレベル１命令キャッシュとレベル１データキャッシュとを有するが、レベル２キャッシュは共有する。ＧＰＵ２５は、データ又は命令をキャッシュするキャッシュ３６を有する。なお、これは単に利用できる実現可能なキャッシュ階層の例であって、他の構成も実現可能であることが理解されよう。また、各処理回路（ＣＰＵ及びＧＰＵ）２４及び２５は、仮想アドレス（ＶＡ）と中間物理アドレス（ＩＰＡ）と物理アドレス（ＰＡ）との間で変換を行い、以下に詳述するような、ページテーブルを用いる特定のプロセスによって設定されたアクセス許可を実施するメモリ管理ユニット４０も有する。
【0017】
ＣＰＵ２４及びＧＰＵ２５は、図１に関して上述された任意の種類のプロセスから命令を実行できる。図１のプロセス２，４，６，１０，１２及び１４のそれぞれは「ブラインドドメイン」（ＢＤ）と称されてもよく、対応するブラインドドメイン識別子（ＢＤＩＤ）を有する。プロセスの幾つかについては、各プロセスに対してＢＤＩＤを適当に割り当ててもよい。例えば、ハイパーバイザ２、セキュアモニター１４又はセキュアＯＳ１０には、対応するＢＤＩＤ値を単にあてがうだけでもよい。しかしながら、他のプロセスについては、ＢＤＩＤは、個別のプロセスに既にあてがわれた既存の識別子を連結したものであってもよい。例えば、特定の仮想マシン４の下で実行される所定のアプリケーション６に対するＢＤＩＤは、その少なくとも一部が、そのアプリケーションと仮想マシン識別子（ＶＭＩＤ）とに関連付けられたアプリケーション空間識別子（ＡＳＩＤ）から形成されてもよい。また、ＢＤＩＤには、プロセスがセキュアドメイン又は正規ドメインと関連付けられているかどうかを示すセキュアビットＳも含まれてもよい。つまり、各プロセスは、その対応するＢＤＩＤを用いることで一意的に識別が可能である。
【0018】
メモリ３４内にはブラインドドメイン記述子テーブル（ＢＤＤＴ）４２が設けられ、各ＢＤ２，４，６，１０，１２及び１４の状態を追跡(track)する。例えば、ＢＤＤＴ４２は、各ＢＤＩＤについて、以下のうちの１つのようなブラインドドメインの状態を特定してもよい。・無効（Ｉｎｖａｌｉｄ）：このＢＤＩＤにはまだブラインドドメインが設定されていない。
・消去（Ｓｃｒｕｂ）：ＢＤＩＤはセキュリティコンプレックス２８によって請求されている（後述のように、これには、事前に同じＢＤＩＤを使用したプロセスと関連付けられたメモリ３４内の任意のデータを上書きする上書き手続きを行うことが含まれてもよい）。
・準備（Ｐｒｅｐａｒｅ）：セキュリティコンプレックス２８は、そのＢＤＩＤと関連付けられたＢＤを初期化して、ＢＤを実行する準備をしている。
・実行（Ｅｘｅｃｕｔｅ）：ＢＤは初期化されていて、実行の準備が完了しているか既に実行されている。
例えば、ＢＤＤＴ４２は各ＢＤＩＤに対して２ビットの状態フィールドを指定して、対応するブラインドドメインの状態を識別してもよい。ブラインドドメインの状態のライフサイクルを以下により詳しく説明する。ＡＳＩＤによって識別されたアプリケーションに対するＢＤＤＴエントリは、所定の仮想マシン４のＶＭＩＤを、その仮想マシン４の下で実行されるアプリケーション６のＡＳＩＤにマッピングするＶＭＩＤ‐ＡＳＩＤ間接テーブル(VMID-to-ASID indirection table)を用いて追跡されてもよい。なお、ＢＤＤＴ４２が、上記の状態識別子だけでなく、所定のＢＤと関連付けられた他の情報も含んでもよいことが理解されよう。
【0019】
各ブラインドドメイン（ＢＤ）は、そのデータ又は命令を任意の他のブラインドドメインから保護できる。任意のＢＤが、物理アドレス空間の選択されたページの所有者ＢＤになることを要求できる。メモリ３４にはページ所有権テーブル（ＰＯＴ(page ownership table)）５０が格納され、（存在する場合は）どのＢＤがメモリの各物理ページの所有者ＢＤであるかを追跡する。メモリの所定のページの（所有者プロセスとも称される）所有者ＢＤは、そのページへのアクセスを制御する排他的な権利を有する。例えば、所有者ＢＤは、他のＢＤがそのページへのアクセスを許可されるかどうかを制御する属性をページ所有権テーブル５０内に設定できる。各バスマスターには、所定のページの所有者ＢＤによって設定された許可属性を行使する保護ハードウェア６０及び６２が設けられ、バス３０へと出力されている他のＢＤが所有者ＢＤの制御する制約に違反した場合に、そのページを対象としているアクセス要求を防止する。これによって、任意のプロセスが、そのデータ又は命令に（高い特権レベルプロセスを含む）他のプロセスがアクセスするのを防止することができる。
【0020】
図２に示すように、ページ所有権テーブル（ＰＯＴ）５０は、物理アドレス空間の異なるページにそれぞれ対応する幾つかのエントリ５２を含む。ＰＯＴ５０は物理アドレスでインデックスされる。ＰＯＴ５０の各エントリ５２は以下の情報を含む。・対応する物理ページを所有するＢＤのＢＤＩＤを指定する所有者ＢＤＩＤフィールド５４。
・対応する物理ページへのアクセスを制御する１つ以上の属性を指定する属性フィールド(attribute field)５６。これらの属性は、ＢＤＩＤフィールド５４内で識別される所有者ＢＤによって設定される。
・アドレスフィールド５８。その所有者ＢＤが仮想アドレス又は中間物理アドレスを使用するページ（例えばアプリケーション６及び１２や仮想マシン４）に対して、そのページが所有者ＢＤによって請求されたときに、アドレスフィールド５８は、対応する物理ページの物理アドレスにマッピングされるＶＡ又はＩＰＡを指定する。
・（図２には示されていない）ページ状態フィールド。対応するページの状態を示す。例えば、各物理ページは以下の状態の１つであってもよい。
○無効（Ｉｎｖａｌｉｄ）：どのＢＤにも所有されていない。
○請求（Ｃｌａｉｍｉｎｇ）：ＢＤＩＤフィールド５４内で示されるＢＤによって請求されているプロセス内にあるが、まだ所有が有効でない。
○有効（Ｖａｌｉｄ）：ＢＤＩＤフィールド５４内で示されるＢＤによる所有が有効である。
・任意で、ページの所有権を請求した場合に行われる上書きプロセスの際に上書きされたページの行数を追跡する（以下により詳しく説明される）請求カウントフィールド(claim count field)６０。
また、ＣＰＵ２４又はＧＰＵ２５のレジスタ内又はメモリ３４内のスタック構造内といった異なるロケーション内に請求カウンター(claim counter)６０を格納することも可能であり、これによって、必要に応じて、請求カウントフィールド６０をＰＯＴ５０から省略できる。
【0021】
所定のページに対するＰＯＴエントリ５２の属性フィールド５６をそのページの所有者ＢＤが設定することで、所有者ＢＤによって、他のＢＤがページにアクセスすることを排他的に制御できるようにする。属性フィールド５６は、例えば以下のような、対応するページへのアクセスを制御する属性の幅を含んでもよい。・所有者ＢＤＩＤ以外のどのプロセスがページにアクセスできるかを示す共有属性。例えば、共有属性は以下のページのタイプの１つを指定できる。
○プライベート（Ｐｒｉｖａｔｅ）：ＢＤＩＤフィールド５４内で識別された所有者ＢＤのみがページにアクセスできる。
○ＩＯ：ＢＤＩＤフィールド５４内で識別された所有者ＢＤ及び、所有者ＢＤによって請求されている任意の装置２６のみがページにアクセスできる（後述の装置所有権の請求を参照）。
○共有（Ｓｈａｒｅｄ）：所有者ＢＤ及び１つ以上の選択された他のＢＤがページにアクセスできるが、その他のＢＤはいずれもアクセスできない。選択された他のＢＤは、属性フィールド５６の更なる属性、又はページ所有権テーブル５０とは別に格納された制御データによって識別できる。
○グローバル（Ｇｌｏｂａｌ）：どのＢＤもページにアクセスできる。
・所有者ＢＤ以外のＢＤがページへのアクセスを許可された場合、そのＢＤがページに対する読み取り専用のアクセスを有しているか、読み取り／書き込みアクセスのどちらも有しているかを示す、読み取り／書き込み属性。
・対応する物理ページに書き込まれるデータに適用される暗号のレベルを示す暗号属性。
【0022】
図２に示すように、メモリ制御部３２は、メモリ３４に書き込まれたデータの暗号化及びメモリ３４から読み取られたデータの複合化を行う暗号化回路５６を含んでもよい。暗号化回路５６は幾つかの秘密暗号化キーを保持してもよく、各ＢＤＩＤはそれ自身のキーを有してもよい。暗号化回路５６は、全く暗号化されないもの（データが暗号化することなくメモリに書き込まれる）から、連続的に強力な形態となる暗号化を通して、幾つかの異なる暗号化レベルをサポートする。一般的に、暗号化が強力なほどセキュリティが高くなり、より多くのリソースがデータの暗号化及び復号化に消費される。
【0023】
幾つかの実現において、所定のＢＤが、自身が所有する全てのページに対して同じレベルの暗号化を指定してもよい。ＢＤが所有する全てのページに対する暗号化が同じレベルの場合は、代替として、ＢＤが所有するページの各ＰＯＴエントリ５２に代わって、ＢＤＤＴ４２内のＢＤのエントリにおける暗号化レベルを指定することになるだろう。しかしながら、ページテーブル内の暗号化レベルを指定することで、暗号化回路５６が、ページの所有者ＢＤ及び暗号化レベルの両方を識別するのに、ＰＯＴ５０及びＢＤＤＴ４２を読み取るのではなく１つのテーブル５０を読むだけで済むようになるため、処理速度を上げることができる。
【0024】
しかし、他の実施形態では、所有者ＢＤは、所有する異なるページに対して異なるレベルの暗号化を指定してもよい。ページごとに求められる暗号化レベルを所有者ＢＤが選択できるようにすることで、最も強力な暗号化を本当にそれを必要としているページのために留保しておくことができ、それほど機密ではない情報を格納しているページには低いレベルの暗号化を用いて、電力を節約することができる。これによって、セキュリティと電力消費とのバランスが良くなる。
【0025】
従って、書き込みにおいて、暗号化回路５６は対象アドレスのＰＯＴエントリ５２を確認して、対応するページに適用する暗号化レベルを判断する。暗号化回路５６は、そのＰＯＴエントリ５２のＢＤＩＤ５４フィールド内で示される所有者ＢＤに対して適切な暗号化キーを選択し、キー及び指定された暗号化レベルを用いてデータを暗号化してから、暗号化されたデータをメモリ３４に書き込む。同様に、読み取りアクセスにおいて、暗号化回路５６は対応するページのＰＯＴエントリ５２を確認して、必要な復号化レベル及び復号化にどの所有者ＢＤのキーを使用すべきかを判断し、メモリ３４から読み取られたデータを復号化して、その後、復号化されたデータを要求したマスターに、バス３０を介してデータを出力する。
【0026】
従って、各プロセスは物理アドレスの対応するページの所有者になることができ、高い特権レベルのプロセスの制御を含めて、他のプロセスがそのページにアクセスできるかどうかを排他的に制御する。これによって、例えば仮想マシン４が、ハイパーバイザ２がそのデータ又は命令にアクセスするのを防止することが可能となり、上記の問題に対処する。
【0027】
ページ所有権テーブル５０に設定された方針の実施は、各処理回路２４，２５及び２８と関連付けられたブラインドドメイン管理ユニット（ＢＤＭＵ）６０によって実行される。図３に示すように、ＢＤＭＵ６０は、メモリ管理ユニット（ＭＭＵ）４０が行う任意の確認を通ったトランザクションに対して行われるトランザクション承認の更なるステージとして機能してもよい。
【0028】
図３に示すように、ＭＭＵ４０は、それぞれがアドレストランザクションの２つのステージを提供するステージ１ＭＭＵ（Ｓ１ＭＭＵ）４０−１とステージ２ＭＭＵ（Ｓ２ＭＭＵ）４０−２とを含んでもよい。ＭＭＵに入力されるトランザクションは、アクセスされる仮想アドレス７０と、トランザクションが読み取りトランザクション及び書き込みトランザクションのどちらであるかを指定するトランザクションタイプ属性７２と、トランザクションを発行したアプリケーション６を識別するＡＳＩＤ７３と、その下でアプリケーション６が実行されている仮想マシン４を識別するＶＭＩＤ７４とを備える。ＡＳＩＤ及びＶＭＩＤは、共に、トランザクションが実行されたコンテキストを識別するコンテキスト識別子を形成すると考えることができる。
【0029】
Ｓ１ＭＭＵ４０−１は、メモリ３４内に格納されたステージ１（Ｓ１）ページテーブル８０からエントリの一部をキャッシュするＳ１ＭＭＵ内のローカルキャッシュである、ステージ１トランザクションルックアサイドバッファ（Ｓ１ＴＬＢ）内の仮想アドレス７０及びＡＳＩＤ７３をルックアップする。正規ドメインでは、Ｓ１ページテーブル８０は、アプリケーション６を制御する仮想マシン４によって設定され、セキュアドメインでは、Ｓ１ページテーブル８０は、セキュアＯＳ１０によって設定される。各Ｓ１ページテーブルエントリは、対応するＡＳＩＤが、対応するページへの読み取り許可又は書き込み許可を有するかどうかを指定する属性と共に、仮想アドレス空間の対応するページに対するＶＡ−ＰＡ又はＶＡ−ＩＰＡマッピングを指定する。Ｓ１ＴＬＢがＶＡ７０及びＡＳＩＤ７３に対応するエントリを含まない場合は、ページテーブルウォークが行われて、必要なエントリをＳ１ページテーブル８０から取り出す。必要なエントリがＳ１ＴＬＢ内にある場合、Ｓ１ＭＭＵ４０−１は、読み取り／書き込み属性７２によって指定されたタイプのアクセスが、指定されたＡＳＩＤ７３及び仮想アドレス７０に対して許可されているかどうかを確認する。アクセスが許可されていない場合、トランザクションは拒否され、ステージ１アクセス違反があったことが知らされてもよい。一方、許可が得られている場合、入力ＶＡ７０に対応する変換されたＰＡ又はＩＰＡ７５が出力される。
【0030】
例外のレベルＳ−ＥＬ０，Ｓ−ＥＬ１，ＥＬ２又はＥＬ３の１つにおいて入力トランザクションが発行された場合は、Ｓ１ＭＭＵ４０−１の出力はＰＡであり、ステージ２ＭＭＵ４０−２を回避できる。
【0031】
しかしながら、ＥＬ０又はＥＬ１で実行されるアプリケーション６又は仮想マシン４によって入力トランザクションが発行された場合は、Ｓ２ＭＭＵ４０−２が更なるアドレス変換及びアクセス許可確認を行う。Ｓ２ＭＭＵ４０−２は、エントリの一部をメモリ３４内のステージ２（Ｓ２）ページテーブル８２からキャッシュするステージ２ＴＬＢ（Ｓ２ＴＬＢ）を含む。Ｓ２ページテーブル８２は、（正規ドメインについては）ハイパーバイザ２又は（セキュアドメインについては）セキュアＯＳ１０によって設定される。Ｓ２ＭＭＵ４０−２はＳ２ＴＬＢをルックアップして、指定されたＩＰＡ７５及びＶＭＩＤ７４のエントリがあるかどうかを確認し、無い場合はページテーブルウォークを行って必要なエントリをＳ２ページテーブル８２から取り出す。必要なエントリがＳ２ＴＬＢ内にある場合、Ｓ２ＭＭＵ４０−２は、属性７２内で指定されたタイプのトランザクションが許可されているかどうかを確認し、許可されている場合、ＩＰＡ７５に対応する変換されたＰＡ７６を出力する。トランザクションが許可されていない場合、ステージ２アクセス違反があった旨のフラグが立てられ、トランザクションは拒否される。
【0032】
従って、ＭＭＵ４０−１及び４０−２の各ステージは、アクセス要求が、所定の特権レベルにおける所定のプロセスによって設定されたアクセス許可を得ているかどうかを確認するアクセス制御回路と考えられる（例えば、Ｓ１ＭＭＵ４０−１は、仮想マシン４又はセキュアＯＳ１０によって設定された許可を実施し、Ｓ２ＭＭＵ４０−２は、ハイパーバイザ２によって設定された許可を実施する）。
【0033】
そして、物理アドレス７６はＢＤＭＵ６０へと渡り、物理アドレス空間の対応するページに対するＰＯＴ５０内の所有者ＢＤによって設定された任意のアクセス制御を実施する。ＢＤＭＵ６０は、ＭＭＵ４０の各ステージ内のＴＬＢと同様に、ＰＯＴ５０とＢＤＤＴ４２との一部をメモリ３４からキャッシュするルックアサイドバッファを含んでもよい（以下の図９参照）。従って、ＢＤＭＵ６０は、（ＥＬ２、ＥＬ３若しくはＳ−ＥＬ１からの物理的にアドレス指定されたトランザクション、又はＭＭＵ４０によるＶＡ又はＩＰＡからの変換によって）物理アドレス７６を受信すると、必要なＰＯＴエントリ５２及びＢＤＤＴエントリがそれぞれのルックアサイドバッファに存在するかどうかを確認し、存在しない場合、メモリ３４から必要なエントリを取り出す。必要なエントリが得られた場合、以下の一連の確認を介して物理アドレスを承認する。・ＢＤＭＵ６０は現在のコンテキストＢＤ（そこからトランザクションが生成されたＢＤ）がＢＤＤＴ４２内の有効コンテキストであるかどうかを確認する。例えば、ＢＤＤＴ６０は、ＶＭＩＤ７４及びＡＳＩＤ７３から現在のコンテキストＢＤのＢＤＩＤを形成して、対応するＢＤＩＤがＢＤＤＴ４２内で「実行」状態としてマークされているかどうかを確認する。
・ＢＤＭＵ６０は、現在のコンテキストＢＤが、物理アドレス７６に対応するＰＯＴエントリ５２内で所有者ＢＤ５４として示されているかどうかを確認する。
・現在のコンテキストＢＤが所有者ＢＤでない場合、ＢＤＭＵ６０は、（上記の共有属性を用いて）現在のコンテキストＢＤがページにアクセスするのを所有者ＢＤに許可されているかどうかを確認する。
・現在のコンテキストＢＤが所有者ＢＤでない場合、ＢＤＭＵ６０は、対応するＰＯＴエントリの読み取り／書き込み属性を確認して、属性７２で指定されたタイプのトランザクションが所有者ＢＤに許可されているかどうかを判断する。
・現在のコンテキストＢＤが所有者ＢＤである場合、ＢＤＭＵ６０は、入力トランザクションが行われたＶＡ７０又はＩＰＡ７５が、対応するＰＯＴエントリ５２のアドレスフィールド５８内のＶＡ／ＩＰＡと合致するかどうかを確認する。
・また、ＢＤＭＵ６０は、現在のアクセスに対してＳ１ページテーブルエントリ内で指定された想定の共有属性が、対応するＰＯＴエントリ内で指定された実際の共有属性と合致するかどうかも確認する。
これらのうちいずれかの確認が取れなかった場合、アクセスは拒否され、アクセス違反が生じる。それ以外の場合は、物理的アドレストランザクションは承認され、システムバス３０へと出力される。なお、上記の確認が任意の順序で行われたり、少なくとも部分的に並列に行われたりしてもよいことが理解されよう。
【0034】
同様に、物理アドレス空間の特定のページの所有者が、対応するＰＯＴエントリ５２の属性フィールド５６内でページを「ＩＯ」タイプとしてマークしているかどうかに基づいて、ＢＤフィルタ６２が、そのページを対象とするトランザクションをシステムバス３０へと出力するかどうかを制御してもよい。
【0035】
従って、図４に示すように、システムバス３０に接続された各バスマスター２４，２５，２６及び２８には、物理的にアドレス指定されたトランザクションを承認するＢＤＭＵ６０又はＢＤフィルタ６２のいずれかが設けられてもよく、これによって、システムバスに出力された全てのトランザクションが物理アドレスを指定する承認済みのトランザクションとなるため、メモリ制御部３２において更なる承認を行う必要がなくなる。或いは、代替として、ＢＤＭＵ機能性６０をメモリ制御部３２へと移動させて、ＭＭＵ４０によって承認済みだがページ所有者がＰＯＴ５０内に設定しているどの許可ともまだ比較されていないトランザクションがバスへと出力され、そして、そのトランザクションがメモリ制御部３２に到達するとＰＯＴ５０と照合される。しかしながら、バスへと出力されているＰＯＴ５０確認が取れないであろうトランザクションが防止され、各トランザクションと関連付けられた現在のコンテキストＢＤを識別するメモリ制御部に向けてバスマスターから送信される追加のタグが必要でなくなることから、バスのトラフィックが軽減するため、ＢＤＭＵ６０を設けることは有利である。逆に言えば、ハードウェア攻撃から守るために、メモリに書き込まれるデータを暗号化できるように、暗号化／復号化回路５６がメモリ制御部３２に設けられるが、バスマスター２４，２５，２６及び２８自体が暗号化機能を有する必要はない。
【0036】
図５は、処理回路２４の１つが発行したデータアクセストランザクション（アクセス要求）が許可されているかどうかを確認する方法を示す。ステップ１００において、入力トランザクションが受信されてＶＡ７０が指定される。ステップ１０２において、Ｓ１ＭＭＵ４０−１は、入力ＶＡ７０と現在のコンテキスト（ＶＭＩＤ及びＡＳＩＤ）とに対応するエントリのＳ１ＴＬＢをルックアップする。Ｓ１ＭＭＵ４０−１は、そのエントリ内に設定されたアクセス許可の違反があるかどうかを確認する。Ｓ１アクセス違反がある場合、ステップ１０４においてトランザクション要求は拒否される。Ｓ１アクセス違反がない場合、変換されたＩＰＡ又はＰＡが出力される。また、以下により詳しく述べるように、ページのＰＩＳＧ状態（想定の共有属性）がＳ１ＭＭＵ４０−１によって出力される。トランザクションがＥＬ２、ＥＬ３、Ｓ−ＥＬ０又はＳ−ＥＬ１で発行された場合、変換されたアドレスはＰＡであり、Ｓ２ＭＭＵ４０−２は回避される。トランザクションがＥＬ０又はＥＬ１で発行された場合、出力されたアドレスはＩＰＡであり、アドレス変換の第２ステージが行われる。この場合、Ｓ２ＭＭＵＭＭＵ４０−２は、同様に、ＩＰＡ７５と現在のコンテキスト（ＶＭＩＤ）とに対応するエントリのＳ２ＴＬＢをルックアップする。そのエントリ内のアクセス許可が確認され、アクセス違反がある場合、要求はステップ１０４において再び拒否される。Ｓ２ＭＭＵ４０−２によってアクセスが許可されている場合、ＩＰＡはＰＡ７６へと変換され、ＢＤＭＵ６０へと出力される。
【0037】
従って、ステージ１アドレス変換又はステージ２アドレス変換のいずれにおいてもアクセス違反が無い場合、物理アドレスが得られる。ステップ１１２において、物理アドレスは、現在のコンテキストのＢＤＩＤが「実行」状態でＢＤＤＴ４２内に示されているかどうかを確認するＢＤＭＵ６０に提供される。示されていない場合、要求はステップ１１４において拒否される。そのＢＤＩＤは、実行状態に進むためにはまず、後述するように、「消去」及び「準備」状態を通過しなければならない。ＢＤＩＤを承認するこのステップは、まだ安全に初期化されていないＢＤＩＤにアクセスを発行することで安全初期化プロセスが回避されるという事態を防止する。また、ここでも、ＢＤＤＴ４２の最近見られた幾つかのエントリをキャッシュするローカルルックアサイドバッファがＢＤＭＵ６０内に保持されて、ＢＤＤＴエントリの確認速度を上げることができる。
【0038】
現在のコンテキストのＢＤＩＤが「実行」状態だと承認されると、ステップ１１６においてＢＤＭＵ６０は必要な物理アドレス７６に対応するＰＯＴエントリ５２を確認する（ＰＯＴ［ＰＡ］の表記はＰＯＴエントリ５２を意味する）。また、ここでも、ＢＤＭＵ６０内に設けられたＰＯＴルックアサイドバッファ内でアクセスが行われて、より速いアクセスのために、最近遭遇したＰＯＴエントリの一部をキャッシュしてもよい。ＢＤＭＵは、対応するＰＯＴエントリ５２が、現在のコンテキストのＢＤＩＤを対象ページの所有者ＢＤとして識別しているかどうかを確認する。識別していない場合、ステップ１１８において、ＢＤＭＵは、対応するＰＯＴエントリ５２の共有属性が、現在のコンテキストの特定のＢＤＩＤと共に「グローバル」又は「共有」のいずれかにマークされているかどうかを確認する。また、ＢＤＭＵ６０は、アクセス要求の読み取り／書き込みのタイプが、対応するＰＯＴエントリ５２の属性フィールド５６内で所有者以外のＢＤとして定義された許可済みのタイプに合致するかどうかも確認してもよい。これらの確認が取れた場合、ステップ１２０において、ＢＤＭＵはトランザクションを承認し、それをシステムバス３０へと出力する。一方、ページが現在のコンテキストのＢＤＩＤと共有されていなかった場合（例えばページがプライベートになっていたか、他のＢＤのみと共有されていた場合）、又はアクセス要求が書き込みを指定したがページは読み取り専用とマークされている場合、ステップ１１４においてリクエストは拒否される。
【0039】
一方、ステップ１１６において、現在のコンテキストが、対応するページの所有者ＢＤである場合、所有者ＢＤは自身のページへのアクセスが許可されているため、共有属性５６を確認する必要はない。しかしながら、ステップ１２２において、トランザクションのソースが特権レベルＥＬ０，ＥＬ１又はＳ−ＥＬ０にある場合、ＢＤＭＵ６０は、トランザクションのＶＡ又はＩＰＡが、対応するＰＯＴエントリ５２のアドレスフィールド５８内に格納されたＶＡ又はＩＰＡと合致するかどうかを確認する。ＥＬ０又はＳ−ＥＬ０で発行されたトランザクションについては、ＢＤＭＵ６０はトランザクションのＶＡがアドレスフィールド５８内のＶＡと合致するかどうかを確認し、ＥＬ１で発行されたトランザクションについては、ＢＤＭＵ６０はトランザクションのＩＰＡがアドレスフィールド５８内のＩＰＡと合致するかどうかを確認する。合致している場合、ステップ１２０においてトランザクションは承認されてバス３０に出力される。アドレスが合致しない場合、ステップ１１４において要求は拒否される。
【0040】
このような、ＶＡ又はＩＰＡをＰＯＴ５０内に記録されたＶＡ又はＩＰＡに対して最終確認することが有用である理由はすぐには明らかにならないだろう。そこで、以下の場合を検討する。
【0041】
ハイパーバイザ２は、例えば、以下のように、２つの物理的にアドレス指定されたページＰＡ０及びＰＡ１を、Ｓ２ページテーブル８２内のアドレスマッピングによって特定の仮想マシン４に割り当てることができる。ＩＰＡ ＰＡ
ＩＰＡ４ ＰＡ１
ＩＰＡ９ ＰＡ０
そして、仮想マシン４は、以下のように、これらの両方のページの所有権を得て、ＰＯＴ５０内の共有属性を設定できる。
ＰＡ 共有？
ＰＡ０ グローバル
ＰＡ１ プライベート
【0042】
そして、仮想マシン４は、例えば、（ＶＭ４がＰＯＴ５０内でプライベートとしてマークされていると想定しうる）ＩＰＡ４に機密データを書き込む或るコードを含み、このデータに他のプロセスがアクセスするのを防止できる。
【0043】
しかしながら、ＶＭ４が、機密データを書き込むコードの安全な部分を開始する前に、ハイパーバイザ２はＳ２ページテーブル８２を以下のように変形できる。ＩＰＡ ＰＡ
ＩＰＡ４ ＰＡ０
ＩＰＡ９ ＰＡ８
【0044】
ここで、ＶＭ４が、中間物理アドレスＩＰＡ４を用いてそのコードの安全な部分を実行した場合、安全な部分が、「グローバル」ページであるＰＯＴ５０内でマークされた異なる物理アドレスＰＡ０にマッピングされてしまうことがある。ＶＭ４は、その機密データを「グローバル」ページに書き込み、この情報を、ハイパーバイザ２自体を含む任意の他のプロセスに露出してしまうことがある。
【0045】
この問題は、ＰＯＴ５０内に情報５８を提供して、所有ページに対するアドレスマッピングを特定のマッピングに「ロック」することで防止でき、これによって、所有権属性情報がＰＯＴ５０内に設定された後に他のプロセスがページテーブル８０及び８２内のアドレスマッピングを変更した場合にアクセス違反を生じさせることができる。例えば、所有者ＢＤがページを請求する場合、ページを請求するときに行われる現在のＶＡ−ＰＡ又はＩＰＡ−ＰＡマッピングが、その物理的にアドレス指定されたページに対応するＰＯＴエントリ５２のアドレスフィールド５８を用いて記録されてもよい。上記の例では、ＰＯＴ５０は以下のようであってもよい。ＰＡ 共有？ ＩＰＡ
ＰＡ０ グローバル ＩＰＡ９
ＰＡ１ プライベート ＩＰＡ４
【0046】
その後、ＶＭ４が中間アドレスＩＰＡ４を用いてプライベートページにアクセスしようとしたときに、その間にハイパーバイザ２がＩＰＡ４をＰＡ０へのポイントにリマッピングした場合、このアクセスの中間アドレスＩＰＡ４が、このとき物理ページＰＡ０のＰＯＴエントリ５２内の中間アドレスＩＰＡ９と合致するため、このリマッピングを検出できる。そのため、エラーのフラグを立てることでき、ＶＭ４はその安全処理を中断して、機密情報を他のプロセスに露出することを防止する。これによって、上記のような種類の攻撃が避けられる。そして、ＶＭ４は再びＩＰＡ４及びＩＰＡ９の所有権を要求し、このときこれらのＩＰＡにマッピングされている物理ページＰＡ０及びＰＡ８に必要なアクセス制御許可を設定する。
【0047】
従って、逆アドレス変換を含むＰＯＴ５０内のマッピングが、ページテーブル内の変化に起因する上記のような種類の攻撃を避けるのを助けることができる。上記の例では、仮想マシン４が所有するページに対するページテーブルマッピングを変形させるハイパーバイザについて述べたが、同様の技術を、アプリケーション６又は信頼アプリケーション１２が所有するページに対するページテーブルマッピングを変形させる仮想マシン４を防止するのに使用でき、この場合、ＩＰＡではなくＶＡがアドレスフィールド５８に格納されうる。
【0048】
図５には示されていないが、トランザクションを承認する方法は、対象ＰＡに対応するＰＯＴエントリ５２の「共有」属性が、対応するＶＡに対するＳ１ページテーブルエントリ内で指定された想定の属性と合致するかどうかを検証する追加のステップも含んでもよい。ページ所有者が所定のページに共有属性を設定すると（これによって、上述したようにページがプライベート、ＩＯ、共有又はグローバルのいずれかであることが示される）、Ｓ１ページテーブルの更新も生じるため、対応するページテーブルエントリが、対応する属性を指定できる。幾つかの場合では、ページテーブルエントリはまずＳ１ＴＬＢ内でのみ更新され、そして、対応するページテーブルエントリがＳ１ＴＬＢから無くなると、メモリ内のＳ１ページテーブル８０を更新できる。その後、そのページにアクセス要求が発行されると、Ｓ１ＭＭＵ８０は、対応するＳ１ページテーブルエントリ内で指定された想定の共有属性（ＰＩＳＧタイプ）を出力でき、ＢＤＭＵ６０は、想定の共有属性が、ＰＡに対応するＰＯＴエントリ５２内で指定された共有属性と合致するかどうかを確認できる。合致する場合、（上記の他の確認次第で）アクセス要求を承認できる。しかしながら、実際の共有属性がＳ１ページテーブルエントリ内で指定された想定の共有属性と合致しない場合、アクセス要求は拒否される。これによって、以下のような潜在的な攻撃から守られる。
【0049】
例えば、所定のＢＤは、所定の物理ページの所有権を請求して、そのページに機密情報を書き込む準備としてプライベートとマークしてもよい。しかしながら、ＢＤが機密情報の書き込みを開始する前に、他のＢＤによって同じページの所有権が請求されて、そのページがグローバルとマークされることがある。すると、前の所有者ＢＤがページに機密情報を書き込もうとすると、現在の所有者によってページがグローバルとマークされているため、要求が承認されてしまい、機密情報を他のプロセスに露出してしまう可能性がある。これは、そのページの想定のページ共有タイプを示す対応するページテーブルエントリに情報を書き込んで、そのページにアクセスするときに、ＰＯＴ内に記録された実際の共有タイプがこの想定のページ共有タイプと合致するかどうかを確認することで防止できる。
【0050】
上記の例では、想定の共有属性（ＰＩＳＧタイプ）はＳ１ページテーブル内で指定されるが、他の例では、これをＳ２ページテーブル内で指定してもよい。また、幾つかの場合では、どのプロセスが共有属性を設定するかによって、幾つかのページが、Ｓ１ページテーブル内で指定された想定の共有属性を有して、他のページが、Ｓ２ページテーブル内で指定された共有属性を有してもよい。
【0051】
つまり、ＢＤＭＵ６０は、アクセス許可確認の追加のレイヤーをＭＭＵ４０の最上位に設けることで、ＭＭＵ４０及びＢＤＭＵ６０の両方で確認が取れないとトランザクションの承認ができないようにする。ＭＭＵ４０が、特定の特権レベルのプロセスによって設定された許可を確認する一方で（例えばＥＬ１がＳ１ページテーブルを制御し、ＥＬ２がＳ２ページテーブルを制御する）、ＢＤＭＵ６０が、任意の特権レベルで実行される所有者プロセスによって特定のページに適用できる許可を実施する。従って、例えばハイパーバイザ２が、まだアドレス空間の特定の領域を特定の仮想マシン４に割り当てることができて、それらの領域に他のＶＭ４がアクセスするのをＳ２ＭＭＵ４０−２及びＳ２ページテーブルを用いて防止できる場合、仮想マシン４自身によって、ＰＯＴ５０内に適切な許可を設定して、ＢＤＭＵ６０を制御し、ハイパーバイザ２からそれらのページへの任意の要求を拒否することで、ハイパーバイザ２が、ページのその割り当てられた「プール(pool)」内の幾つかのページにアクセスするのを防止できる。これによって、各「ブラインドドメイン(blind domain)」がそのセキュリティを実施でき、システム内の他のどのドメインからもデータを隠すことができるシステムを可能にする。
【0052】
図６は、ＢＤが、書き込みアクセスを行う物理アドレス空間の任意のページの所有権を要求できる方法の例を示す。ページの所有権を要求する際、同じ物理ページの前の所有者によってそのページに既に安全データが書き込まれていることがある。異なるＢＤ間でページの所有権が移る際にデータが漏出しないようにするために、新たな所有者は、ページの有効な所有者となる前に、要求されたページの各ロケーション内のデータを上書きする上書きプロセス１５０を完了させなければならないようにしてもよい。各ロケーションに書き込まれた特定のデータ値は、前のデータが上書きさえされればよく、例えば各ロケーションには０又は任意の他のダミー値が書き込まれてもよい。新たな所有者が、所有権の請求が有効となる前に、破壊的な請求シーケンスを行うことでページ内に存在する全てのデータを上書きしなければならないようにすることで、所定のページを前に所有していた特定のＢＤが無くなっていても（例えばハイパーバイザ２が所定のＶＭ４の実行を終了していても）、データのセキュリティを実施できる。幾つかの例では、或る専用ハードウェアを処理回路２４，２５及び２８内に設けて、ページ所有権が要求されると上書きシーケンスが行われるようにできる。しかしながら、以下の例では、新たな所有者ＢＤと関連付けられたソフトウェアが、請求されているページの各ロケーションに一連の書き込みを生じさせることで上書きを行うが、そのソフトウェアを実行する処理回路２４，２５及び２８内の或る制御ハードウェアが、新たな所有者ＢＤが上書きプロセス１５０を無事に完了させているかどうかを確認して、上書きプロセス１５０が終了するまでＰＯＴ５０内で有効とマークされるのを防ぐ。
【0053】
所有権要求は、例えば、請求されるページに対応するアドレスを指定する所有権請求命令を実行する将来的な所有者ＢＤに対応してもよい。ステップ１３０において、ＶＡが指定された所有権要求が受信され、所有権が要求されたページを識別する。ステップ１３２において、ＭＭＵ４０は書き込みアクセスが指定されたページに対して許可されているかどうかを判断し、ＭＭＵ４０のステージ１又はステージ２のいずれかが書き込みアクセスが許可されていないと判断すると、ステップ１３４において要求が拒否される。従って、ＢＤは、それ自体にデータを書き込むことを許されていないページの所有権の請求を防止される。書き込みアクセスが許可されている場合、ＶＡが（直接又はＩＰＡを介して）ＰＡへと変換され、ＰＡが出力される。
【0054】
そして、この方法は、対象ＰＡに対応するページの各ロケーション内のデータを上書きする上書き手続き１５０によって進められる。上記の請求カウンター６０は制御ハードウェアによって用いられ、上書きプロセスの進行を追跡して、それまでに上書きされたページの行数をカウントする。ステップ１５２において、上書きカウンター６０は、例えばページのベースアドレスからのオフセットがゼロであるアドレスといった、ページ内で最初のアドレスへのポイントに初期化される。ステップ１５４において、制御ハードウェアは（所有権を要求したＢＤである）要求者ＢＤを待って、書き込みを生じさせる。書き込みが行われると、ステップ１５６において、制御ハードウェアは書き込みの対象アドレスが正しいかどうかを確認する。例えば、制御ハードウェアは要求者ＢＤがページの各行を固定順序で反復するようにして、次のアドレスに書き込みがあるかどうか（例えば書き込みオフセットがインクリメントカウンターと合致するかどうか）を単に確認するようにしてもよい。アドレスが正しくない場合、ステップ１５８において、所有権要求は拒否されて、ページはＰＯＴ内で無効とマークされ、例えば、そのページに無い他のアドレスに書き込むか、同じアドレスに繰り返し書き込むことで、要求しているＢＤが上書き手続きを回避するのを防止する。所有権要求が拒否された場合に要求者ＢＤが再び所有権の要求を望むと、新たな所有権要求を再び開始して、上書き手続き１５０を正しく完了させる必要がある。
【0055】
ステップ１５６において対象アドレスが正しかった場合、ステップ１５９において制御ハードウェアは上書きカウンターをインクリメントする。ステップ１６０において、制御ハードウェアは、要求しているＢＤが、所有権請求プロセスの最後に到達したことを宣言したかどうかを確認する。例えば、要求者ＢＤは所有権請求終了命令を実行して、上書き手続き５０を終了した旨のフラグを立ててもよい。所有権請求の最後に到達していない場合は、この方法はステップ１５４へと戻り、上書きされるページの次の行を確認する。プロセスは、ページの各行ごとにステップ１５４〜１６０を何度も繰り返す。最後に、要求プロセスはその上書き手続き１５０の最後に到達したことを宣言し、ステップ１６２において、制御ハードウェアはページ全体に書き込みが行われたかどうか（例えば上書きカウンターがページの行数と合致するかどうか）を確認する。ページ全体に書き込みが行われていない場合、ステップ１５８において、所有権要求は再び拒否され、ページはＰＯＴ５０内で無効としてマークされる。ページ全体に書き込みが行われている場合、ステップ１６４において、ページは有効としてマークされるため、このとき要求者ＢＤはページの有効な所有者となることができ、ページへのアクセスを排他的に制御できる。また、ページのＰＩＳＧタイプ（共有属性）が、対応するＰＯＴエントリ５２に書き込まれる。幾つかの場合では、新たに請求されたページが最初はデフォルトでプライベートとマークされており、新たな所有者がページをＩＯ、共有又はグローバルに変更したい場合には、（例えば以下の図８又は図１４に示すように）続いて属性の変更が必要となる。一方、最初の所有権要求において、そのページに対して指定される共有属性の値を指定可能であってもよい。また、共有属性の更新によって、Ｓ１ＴＬＢ及び／又はＳ１ページテーブル８０内の対応するページテーブルエントリの更新を生じさせて、想定の共有属性タイプをエンコードすることで、その後のメモリへのアクセスにおいて属性を共有するＰＯＴを承認できるようにしてもよい。
【0056】
ステップ１６６において、要求者ＢＤがＥＬ０又はＳ−ＥＬ０のプロセスである場合は、所有権要求に指定されたＶＡが、請求されたページのＰＯＴエントリ５２のアドレスフィールド５８に書き込まれ、要求者ＢＤがＥＬ１のプロセスである場合は、ＭＭＵによって取得されるＩＰＡがアドレスフィールド５８に書き込まれ、逆のＰＡ−ＶＡ又はＰＡ−ＩＰＡマッピングをＰＯＴ内に閉じ込めて、上記のような種類の攻撃を防止する。なお、ステップ１６６は、他の実施形態では、例えば所有権要求を受信し次第すぐ等、より早く行われてもよいことが理解されよう。同様に、要求者プロセスのＢＤＩＤは、ＰＯＴエントリ５２がステップ１６４までに有効になることがない限りは、図６に示す方法の間いつでもＰＯＴ５０に書き込まれてよい。
【0057】
所有権要求を実行する、要求者ＢＤの或る疑似コード、及び上書き手続き１５０の一例を以下に示す。ＢＤ．Ｐａｇｅ．Ｉｎｖａｌｉｄａｔｅ（ＶＡ１）／／ｂｒｏａｄｃａｓｔ ｐａｇｅ ｉｎｖａｌｉｄａｔｅ
ＢＤ．Ｐａｇｅ．Ｃｌａｉｍ．Ｓｔａｒｔ（ＶＡ１）／／ｒｅｑｕｉｒｅｓ ａｎ ｉｎｖａｌｉｄ ｐａｇｅ
ｌｉｎｅ＝（＊６４ｂｙｔｅ＿ｐｔｒ）ＶＡ１
ｄｏ ｗｈｉｌｅ（ｌｉｎｅ＜（ＶＡ１＋ＰＡＧＥＳＩＺＥ））
ＤＣＺ．ＷＴ（ｌｉｎｅ＋＋）／／ｏｒｄｅｒｅｄ ｚｅｒｏｉｎｇ ｏｆ ｐａｇｅ
ＢＤ．Ｐａｇｅ．Ｃｌａｉｍ．Ｅｎｄ（ＶＡ１）／／ｍａｋｅ ｐａｇｅ ｖａｌｉｄ
【0058】
図７は疑似コードを説明するフロー図である。例えばアプリケーションが、仮想アドレス「ＶＡ１」に対応するページの所有権の請求を望む。要求者ＢＤは、所有権を要求する前に、無効化命令（ＢＤ．Ｐａｇｅ．Ｉｎｖａｌｉｄａｔｅ）を実行して、ＢＤＭＵ６０内の任意のルックアサイドバッファからのアドレスＶＡ１と関連付けられた任意のＰＯＴエントリを無効化する。これにより、所有権請求を受けて、古いデータがルックアサイドバッファに確実に残らなくなる。従って、図７のステップ１９０において、ページは最初は無効状態(Invalid state)にある。そして、要求者ＢＤはページ請求開始命令（ＢＤ．Ｐａｇｅ．Ｃｌａｉｍ．Ｓｔａｒｔ）を実行して所有権要求を発行する。これにより、（ＭＭＵ４０を用いてＶＡ１を変換することでアドレスが取得された）物理的にアドレス指定されたページＰＡ１が「請求(Claiming)」状態(state)へと移行する。要求者（呼び出し元）ＢＤのＢＤＩＤは、ページＰＡ１のＰＯＴエントリ５２のＢＤＩＤフィールド５４に書き込まれる。このときＰＡ１にマッピングされている仮想アドレスＶＡ１はアドレスフィールド５８に書き込まれる。請求カウンター(claim counter)はゼロに初期化される。
【0059】
そして、要求プロセスはデータゼロ化命令（ＤＣＺ．ＷＴ）を実行して初めての上書き動作を開始する。この例では、データゼロ化命令は一度に６４バイトのページをゼロにするが、他の例では、他のサイズのデータブロックにも作用できることが理解されよう。ステップ１９６において、制御ハードウェアは、その命令の書き込みオフセット(write offset)が請求カウント（claim count)と合致するかどうかを確認する。合致しない場合、ステップ１９０において要求は拒否されてページは「無効(Invalid)」状態(state)に戻るように移行するため、要求者ＢＤは、所有権の請求を更に試みたい場合は、他のＢＤ．Ｐａｇｅ．Ｃｌａｉｍ．Ｓｔａｒｔ命令を実行する必要がある。一方、書き込みオフセットが請求カウントと合致する場合、ステップ１９８において請求カウンター６０はインクリメントされ、ステップ１９４において要求者ＢＤは他のデータゼロ化命令ＤＣＺ．ＷＴを実行する。ステップ１９６，１９８及び１９４は、要求者ＢＤがページ請求終了命令（ＢＤ．Ｐａｇｅ．Ｃｌａｉｍ．Ｅｎｄ）を実行して全ての上書き動作が終了したことを知らせるまで繰り返される。ステップ１９８において、制御ハードウェアは、請求カウンターがページ内のアドレスの数と合致するかを確認する。請求カウンターのビット数がページのサイズに対応して選択されると、請求カウンターは、対応するページ内の全てのロケーションに書き込みが行われている場合はオーバーフローするため、制御ハードウェアは、１に等しいと上書き手続きが完了したことを示す、請求カウンターのオーバーフロービットを単に確認することができる。ステップ１９８において請求カウンターがオーバーフローしていない場合、ステップ１９０においてページは再び無効状態に戻るように移行し、要求者ＢＤは、所有権の請求を再び開始する必要がある。ステップ１９８において請求カウンターがオーバーフローしている場合、ステップ２００においてページＰＡ１は有効(Valid)となり、所有者はこのページに対する属性を設定できる。
【0060】
特定のＢＤＩＤを新たなプロセスで使用するのに再利用する場合にも、同様の破壊的な上書き手続き１５０を行うことができる。例えば、所定のＢＤＩＤを「無効」状態から「準備(Prepare)」状態に移行するには、ＢＤＩＤをまず「消去(Scrub)」状態に移行する。ハードウェアは、「消去」状態の間、このとき所定のＢＤＩＤがＰＯＴ５０内で所有者として示されている各ページ内の各アドレスを上書きするように上書き手続き１５０が行われているかを確認してもよい。また、ハードウェアは、そのＢＤＩＤと関連付けられた各ＰＯＴエントリ５２が無効化されることも求めてもよい。実際の上書き動作は、ハイパーバイザ２又は新たなＢＤの確立を要求する他のプロセスによってソフトウェア内で行うことができるが、ハードウェアは上書き手続きが無事に完了しているかを確認して、無事に完了するまでの間ＢＤＩＤが「準備」状態に移行するのを防止してもよい。これにより、そのＢＤＩＤを有する古いプロセスと関連付けられた機密情報が、同じＢＤＩＤを共有する新たなプロセスに漏出しないようにする。
【0061】
他の実施形態では「消去」状態を省略してもよいが、対応するＢＤＩＤに所有されているとしてＰＯＴ５０内に記録されている各ページ内のデータを上書きする上書きプロセスが無事に完了して、そのＢＤＩＤと関連付けられた各ＰＯＴエントリ５２を無効化するまで、「無効」状態から「準備」状態への移行を禁止してもよい。
【0062】
図８は、所定のページの所有者ＢＤがＰＯＴ５０内の属性を更新する方法を示す。ステップ２１０において、対象ページを識別するＶＡ及びそのページのＰＯＴエントリ５２に書き込まれる１つ以上の属性を指定したＰＯＴ更新要求が発行される。ステップ２１２において、ＭＭＵ４０はそのページへの書き込みアクセスが許可されているかどうかを確認し、Ｓ１ＭＭＵ４０−１又はＳ２ＭＭＵ４０−２がアクセス違反を知らせた場合、要求は拒否される。書き込みアクセスが許可されている場合、変換されたＰＡが（ＶＡから直接又はＩＰＡを介して）取得される。
【0063】
ステップ２２２において、物理アドレスを用いてＰＯＴ５０をルックアップし、更新要求を発行した現在のコンテキストＢＤが必要なページの所有者ＢＤかどうかを判断する。必要なページの所有者ＢＤでない場合、ステップ２２４において要求は拒否される。
【0064】
現在のコンテキストＢＤが、必要なページの所有者である場合、ステップ２２６において、アドレスフィールド５８は（ＥＬ０、ＥＬ１又はＳ−ＥＬ０を起点とした要求である）更新要求のＶＡ／ＩＰＡと照合され、アドレスマッピングが、ＰＯＴエントリ５２が割り当てられたときとまだ同じかどうかを確認する。同じでない場合、ステップ２２８において更新要求は拒否される。アドレスが合致すると、ステップ２３０において、対応するページ所有権テーブルエントリの属性が、更新要求内で指定された属性に基づいて更新される。例えば、ページの所有者は、プライベートページが共有となったり共有ページがプライベートとなったりするように属性を変更したり、そのページに対して読み取り又は書き込みが許可されているかどうかを変更したりできる。共有属性に変更があると、Ｓ１ＴＬＢ内のＳ１ページテーブルエントリ又はページテーブル８０に記録されている想定の共有属性（ＰＩＳＧ状態）の対応する更新も生じることがある。
【0065】
アドレスマッピングの変更は、どの場合でも、上記の図５に示すようにメモリアクセスが後から発行されたときに検出できるため、ステップ２２６は任意であり、他の実施形態ではステップ２２２から直接ステップ２３０に進むことができる。とはいえ、ＰＯＴ属性を更新するときにアドレスマッピングの変更のフラグが立つと、潜在的な問題が存在する旨のフラグを所有者ＢＤに向けてより早く立てることができる。
【0066】
図９に示すように、ＢＤＭＵ６０は、ＰＯＴ５０の最近アクセスされたエントリをキャッシュするページ所有権テーブルルックアサイドバッファ（ＰＯＴＬＢ）３０２と、ＢＤＤＴ４２の最近アクセスされたエントリをキャッシュするＢＤＤＴルックアサイドバッファとを有してもよい。これらは、ＭＭＵ４０内のＴＬＢ３００と同様に動作する。図９の下部に示すように、システムバス３０と処理ユニット２４，２５及び２８とが、ＰＯＴＬＢ３０２又はＢＤＤＴＬＢ３０４のエントリを無効化する無効化命令をサポートしてもよい。処理ユニット２４，２５及び２８がこれらの命令の１つを実行すると、コマンドがシステム内のＢＤＭＵ６０のそれぞれにバス３０を介して一斉送信され、各ＢＤＭＵ６０による、ＴＬＢ３０２及び３０４からのエントリの無効化を生じさせる。命令３１０及び３１２はＰＯＴＬＢ３０２のエントリを無効化するためのものである。これらは、例えば、ページの所有権の請求又はＰＯＴ５０内の属性の更新の直前に用いることができる。命令３１０は、ＢＤＭＵ６０による、ＰＯＴＬＢ３０２からのエントリの全ての無効化を生じさせる。命令３１２は、ＢＤＭＵ６０による、指定されたページアドレスに対応する、ＰＯＴＬＢ３０２のそうしたエントリのみの無効化を生じさせる（命令がＶＡ又はＩＰＡを指定した場合はＭＭＵによってＰＡに変換され、物理的にアドレス指定された無効化トランザクションがＢＤＭＵ６０に一斉送信されて、対応するＰＯＴエントリを無効化する）。同様に、命令３１４及び３１６は、命令３１４が、ＢＤＤＴＬＢ３０４の全てのエントリの無効化を生じさせ、命令３１６が、指定されたＢＤＩＤと関連付けられたエントリのみを無効化することで、ＢＤＤＴＬＢ３０４のエントリを無効化するためのものである。無効化を受けて、特定のＢＤＩＤ又はページを求める後続のアクセス要求が生じた場合は、対応するエントリをメモリ３４内の主要ＢＤＤＴ４２又はＰＯＴ５０から取り出す必要があるだろう。
【0067】
幾つかの場合では、同様の無効化コマンドを、所定のＢＤが実行する他の命令によって自動的に生成してもよい。例えば、プロセスが無効化命令を実行してＰＯＴ５０のエントリを無効化すると、処理回路２４及び２５内、ＢＤＭＵ６０内又はメモリ制御部３２内のハードウェアによって一斉送信無効化コマンドが自動的に生成され、ＢＤＭＵ６０内のエントリの対応する無効化が生じる。同様に、ＰＯＴエントリの更新、又はＢＤのステータスにおけるライフサイクルの更新若しくは変更によって、ＢＤＭＵ６０内のＰＯＴ又はＢＤＤＴエントリが無効化される。
【0068】
幾つかの具体例が上述された。しかしながら、本技術はこれらの通りの例に限定されない。例えば、上記の例はページ単位でメモリブロックの所有権を管理するが、ＰＯＴ５０は、或る他のサイズの物理アドレスブロックに対応するエントリを有してもよい（これらは複数のページであってもよいし、ＭＭＵ４０が用いる同じサイズのページに必ずしも対応する必要のないより適当なアドレスブロックに対応してもよい）。
【0069】
上記の例は１つのページ所有権テーブル５０を備えたシステムを示すが、同じシステム内に複数のＰＯＴ５０が存在する場合があってもよい。例えば、物理メモリ内でばらばらになっている異なるＤＲＡＭを制御する複数のメモリ制御部が存在する場合、各メモリ制御部／ＤＲＡＭに対して別々のＰＯＴ５０を設けると有用となりうる。
【0070】
また、上記の例は、所有者プロセスが発行しているＰＯＴを制御及び更新するコマンドを示すが、他の例では、これらのコマンドは所有者プロセスが信頼する他のプロセスから出されてもよい。例えば、幾つかのシステムでは、ＰＯＴ５０は、セキュリティ制御部２８上で動作するプロセスによって所有者ドメインの代わりに管理されてもよい。従って、所有者プロセスが、要求されるページの所有権又はＰＯＴ５０の更新を求める場合に、信頼されたプロセス（例えばセキュリティ制御部２８上で動作するプロセス）によって所有権要求又は更新要求の発行を生じさせるコマンドを、信頼されたプロセスに送信してもよい。同様に、上記の上書き（破壊的な請求）プロセスは、必ずしも所有者プロセスでなくてよい信頼されたプロセスによって行われてもよい。
【0071】
また、上記の例では、所有権要求又はＰＯＴ更新要求を生じさせる命令の実行を説明したが、他の例では、他の形態のコマンドによって所有権又はテーブル更新の要求が生じてもよい。例えばコマンドは、命令、ＰＯＴを制御するハードウェア制御部への直接的なＩ／Ｏ動作、又は（信頼された）関数呼び出しであってもよい。同様に、所有権請求の開始コマンド及び終了コマンドは、必ずしも命令でなくてよく、他の形態のコマンドであってもよい。
【0072】
図１０はゲスト実行環境（ＧＥＥ）の安全な初期化を概略的に示す。ゲスト実行環境は、例えばスタンドアロンアプリケーション、１つ以上のアプリケーションプログラムの実行をサポートする動作システム、又は更なる仮想化システムまでも、といった多くの様々な形態をとることができる。安全な初期化は、そのゲスト実行環境の実行可能コードのソースからゲスト実行環境を起動する要求を送信することで開始される。起動要求はハイパーバイザに送信される。要求は、例えば、ハイパーバイザが制御する仮想化コンピュータシステム（クラウドベースコンピューティングシステム）を用いた或る所望の処理の起動をユーザーが望んだ結果であってもよい。ゲスト実行環境の起動要求は、同時に（又は潜在的には遅れて）、ゲスト実行環境の実行の少なくとも最初の部分に対する暗号化されたバージョンの実行可能コードに伴う。この暗号化された実行可能コードは、異なる様々な方法でその対象である受信者への伝達が行われる間、そのセキュリティ保護を助けるように暗号化されてもよい。この例では、暗号化された実行可能コードは、パブリック／プライベートキーペアのパブリックキーによって暗号化される。プライベートキーペアはセキュリティ制御部によって秘密裏に保持される（後述）。
【0073】
ハイパーバイザは、ハイパーバイザの通常動作のように、ゲスト実行環境の起動要求を受信して、新たな仮想マシン（ＶＭ）を作り出し、ゲスト実行環境に用いられるページを物理メモリアドレス空間に割り当て、そしてゲスト実行環境と関連付けられた他のパラメータを設定する。そしてハイパーバイザは、ゲスト実行環境の初期化要求と、暗号化された実行可能コードと、ハイパーバイザによってゲスト実行環境に割り当てられた物理メモリアドレス空間のページを示すページ識別子と、ゲスト実行環境が用いるブラインドドメイン識別子とをセキュリティ制御部に転送する。なお、通常のシステムにおいて、ハイパーバイザが大量の物理メモリアドレス空間をゲスト実行環境に割り当て、ゲスト実行環境がこの割り当てられたアドレス空間の一部又は全てをその動作に用いてもよいことが理解されよう。本実施形態の例では、セキュリティ制御部（及びその後のゲスト実行環境自体）は、まず、セキュリティ制御部及びその後ゲスト実行環境が所有するようにゲスト実行環境が使用できるものとしてハイパーバイザが既に割り当てたものの中から、使用したい物理メモリアドレス空間の任意のページを破壊的に請求する。
【0074】
セキュリティ制御部は、ハイパーバイザから転送された要求を受信し、暗号化された実行可能コードのインストールが望まれる全てのページを破壊的に請求する。セキュリティ制御部は、請求及び消去しているプロセスを、請求及び消去しながら、要求されたプロセスのプロセス記述子エントリ内に示された状態「消去」へとマークする。そして実行可能コードがインストールされるとプロセスは「準備」とマークされる。セキュリティ制御部は、そのプライベートキーを用いて、受信した実行可能コードを復号化する。復号化されたコードは、セキュリティ制御部が所有するこのステージにおける請求されたページ内へと格納される。そして、復号化された実行可能コードを格納しているページは、これらがクローズしており実行の準備が整っていることを示す「実行」としてマークされる。そしてセキュリティ制御部は、請求されたページの所有権を、初期化されたゲスト実行環境に移す。このとき、当該ブラインドドメイン内におけるデフォルト且つ空のＣＰＵ実行コンテキスト構造も起動される。この実施形態の例では、セキュリティ制御部は、そのプライベートキーを実行可能コードの復号化に適用することで安全な初期化を行っている。他の実施形態の例では、安全な初期化は、セキュリティ制御部による実行可能コードの検証及び／又は安全なインストールの証明を追加で又は代わりに含んでもよい。
【0075】
このステージでは、セキュリティ制御部は、このときゲスト実行環境が「実行(execute)」できる状態であることをハイパーバイザに通知する。これが「最初」の実行であることを示す状態は、当該プロセスのＣＰＵコンテキストテーブルエントリと別々に格納されてもよい。
【0076】
ハイパーバイザは、実行のためのプロセスをスケジューリングする役割を果たす。新たに初期化されたゲスト実行環境が初めて実行される時間になると、ハイパーバイザはこの実行を開始する。そしてゲスト実行環境は、セキュリティ制御部によってゲスト実行環境の所有権に移されている物理ページ内へと格納された、復号化された実行可能コードを実行する。ゲスト実行環境内で実行されるコードは、ハイパーバイザが使用可能であるとマークしたページの中から、動作に必要な任意の更なるページを破壊的に請求する。
【0077】
ゲスト実行環境は様々な異なる形態をとってもよいことが理解されよう。幾つかの実施形態では、ゲスト実行環境は複数のゲストアプリケーションプログラムをサポートするフルオペレーティングシステムであってもよい。他の実施形態の例では、ゲスト実行環境は、自身のメモリページは用いるが別のオペレーティングシステム又は他の関連付けられたシステムは用いずに実行される、単一且つ剥き出しのアプリケーションであってもよい。本技術は、これらの環境及び他の環境で用いることができる。ハイパーバイザの制御下で動作するゲスト実行環境によって、別々のプロセスを互いに分離して実行する機能が提供される。また、セキュリティ制御部、ページ所有権テーブルのメカニズム及びページの所有権の破壊的な請求を設けることで、（任意の形態の）ゲスト実行環境のデータを他のゲスト実行環境及びハイパーバイザ自体によるアクセスから保護できるシステムを提供しようとしている。
【0078】
この実施形態の例では、セキュリティ制御部は別々のプロセッサの形態をとる。他の実施形態の例では、セキュリティ制御部は、要求された／所望のセキュリティの特定の度合いに応じて、同じプロセッサ上で動作する信頼されたプロセス（例えばＡＲＭ Ｌｉｍｉｔｅｄ社のＴｒｕｓｔＺｏｎｅをサポートするプロセッサ上で安全モードで動作する信頼されたプロセス）の形態、又は信頼されたハイパーバイザの形態をとってもよい。
【0079】
図１１は、破壊的ページ請求のプロセスを概略的に示すフロー図である。ステップ７００において、処理は、ページの所有権を求める要求が受信されるまで待機する。こうした要求が受信されると、ステップ７０２が、通常メモリ管理ユニットが要求プロセスに関するページに対して書き込み許可を提供しているかどうかを判断する。このメモリ管理ユニットはハイパーバイザによって制御されてもよい。メモリ管理ユニットが書き込み許可を与えなかった場合、要求は拒否されて処理はステップ７００に戻る。メモリ管理ユニットが書き込み許可を与えた場合、処理は、上書きカウンターが起動されるステップ７０４に進む。ステップ７０６は、所有権が要求されたページの行が上書きされたことが検出されるまで待機する。ステップ７０８は、これが上書きされる次の想定の行だったかどうかを判断する。この実施形態の例では、メモリのページを形成する行に連続的に書き込まれるのを想定されているものとする。想定の行が上書きされていなかった場合、所有権を請求する要求は再び失敗し、処理はステップ７００に戻る。ステップ７０８において、想定の次の行が上書きされていると判断された場合、処理は、上書きカウンターがインクリメントされるステップ７１０に進む。ステップ７１２は、所定の値に到達した上書きカウンターによって示されるようにページ全体に書き込みが行われているかどうかを判断する。上書きカウンターが、ページ全体に上書きが行われていることを示す値にまだ到達していない場合、処理はステップ７０６に戻り、システムはページの次の行が上書きされるまで待機する。ページ全体に上書きが行われていた場合、ステップ７１４は、ページ所有権テーブル内で、今や要求者によって所有されたとしてページをマークする働きをする。
【0080】
図１２は、本明細書に説明されるシステムを提供するハードウェア環境８００を概略的に示す。この例では、ハードウェア環境８００には、複数のプロセッサ８０２及び８０４と、セキュリティ制御部８０６と、物理主要メモリ８０８と、メモリマッピング入出力装置８１０といったバスマスタリング装置とが設けられ、これら全てが相互接続８１２を介して接続されている。なお、ハードウェア環境８００は、広く様々な異なる形態をとることができることが理解されよう。本技術は、例えば、テナント（クラウドカスタマー）が実行が望まれる処理タスクを有する、クラウドコンピューティングのコンテキスト内で使用するのに適している。要求されたタスクを行うのに自身の処理ハードウェアを有するのではなく、クラウドサービスプロバイダによって提供されるゲスト実行環境内で実行されるように要求されたタスクを送信する。クラウドサービスプロバイダは、ハイパーバイザプログラムによってゲスト実行環境に対する要求を受信して、上述のようにそのゲスト実行環境の実行を開始してもよい。ゲスト実行環境の実行は、設けられているクラウド実行サポートのタイプに応じて、自身を複数のプロセスに亘って、又は複数の場所にも亘って分配する。本明細書に説明されるメカニズムは、ゲスト実行環境間のセキュリティのレベルを上げようとしており、これにより、ゲスト実行環境を互いに保護させ且つハイパーバイザ自体からも保護してもよい。
【0081】
図１２のハードウェア実行環境８００は、本明細書に説明されるようにページ所有権テーブルをサポートする。プロセッサ８０２及び８０４並びにセキュリティ制御部には、物理メモリアドレス空間のページの所有権を取得するプロセス、及び、本明細書内で説明されるように請求プロセスの一部としてそのページを上書きするプロセスを管理する働きをする所有権・上書き追跡ハードウェア（ＯＴＨ）がそれぞれ設けられる。少なくとも、コンテキスト切り替えをサポートするプロセッサ８０２及び８０４内には、コンテキスト切り替えプロセスの一部として主要メモリ８０８内のコンテキストデータメモリにコンテキストデータを保存する働きをするコンテキスト切り替え回路（ＣＳ）も設けられる。コンテキスト切り替え回路は例外処理回路の形態をもつ。各コンテキストについてコンテキストデータメモリ８１４を形成する領域が当該関連付けられたプロセスに所有されることで、コンテキストデータへのアクセスを制御でき、望まれる場合は、コンテキストデータを確実にプライベートに維持できる。
【0082】
図１３は、現在の技術を用いたソフトウェアレイヤーモデルを概略的に示す。このソフトウェアレイヤーモデルは、最上位にあるセキュリティ制御部から、下位にあるハイパーバイザ、及びそれ自体がゲストオペレーティングシステムとゲストアプリケーションとを含んでもよいゲスト実行環境へと延在する、複数の特権レベルを含む。新たなゲスト実行環境は、ハイパーバイザの特権レベルよりも低い特権レベルで初期化される。
【0083】
一実施形態の例では、特権レベルは、ゲストアプリケーションプログラムに対応する最下位から延在してもよい。次に高いレベルはゲストオペレーティングシステムであり、その後にハイパーバイザ、そしてセキュリティ制御部によって実行されるモニタープログラム又はファームウェアが続く。最上位の特権には、システム内で使用される暗号キーへのアクセス、その分配及び承認を管理するセキュリティコンプレックスを関連付けることができる。なお、他の特権レベルモデルを導入してもよいことが理解されよう。
【0084】
本技術の特徴は、ページ所有権メカニズムが、ゲスト実行環境が自身が所有するページへのアクセスの制御を有するようにシステムを操作することを認める一方で、例えば、高い特権レベルを有するハイパーバイザがそれらのページにアクセスするのをゲスト実行環境が防止してもよいという点である。これは、高い特権レベルの方がより多くのアクセス権利を与えアクセス権利を制御するという一般的な想定に反する。図１２に示す所有権・上書き追跡回路は、そのページに対する所有プロセスによって制御されるアクセス構成に応じて物理メモリアドレス空間内のメモリ領域の所有権利を行使する働きをしてもよい。（ページ所有権テーブル内で示される）所有プロセスは、ページ所有権を、所有プロセスに対してプライベートであるとマークするか、又は所有プロセスとメモリアクセス要求の１つ以上の更なるソースとの間で共有されるようにマークしてもよい。通常、ページは、その破壊的な請求を受けてプライベート状態へと初期化される。所有プロセスによるアクセスの共有は、図１４に示すように様々な異なる形態をとってもよい。ページに対する所有プロセスは、そのページの所有権を、所有プロセス（「親」プロセス）によって初期化される「子」プロセスに移してもよい。こうした親プロセスが子プロセスを初期化して、子プロセスがまだ「準備」状態にある場合、親が所有する１つ以上のページの所有権をその子プロセスに移すことができる。子プロセスは、まず、その子プロセスに対してプライベートとマークされたこれらのページを受信する。そして子プロセスは、そう望む場合は、自身が所有するページのうちいずれかの共有されたアクセス制御ステータスを変更して、その親プロセスと共有しているという共有ステータスを示すようにしてもよい。子プロセスは、その親プロセスから新たなページを受信すると、その新たなページを子プロセスに割り当てるように破壊的な請求を行う。共有は、祖父母プロセス又は先祖階層における任意の年上のプロセスといった先祖プロセスと行うこともできる。
【0085】
プロセスがページにアクセスすると、幾つかの実施形態の例では、そのページに対するその共有されたアクセス制御データが想定のプロセスと同じであるかを確認してもよい。一例として、プロセスがページを所有しており、その共有アクセス制御を「プライベート」と設定している場合、そのページに任意の機密データが格納される前に、ページがまだページ所有権テーブル内でこのように構成されているかを確認してもよい。
【0086】
所有プロセスによって選択されうる共有の他の形態には、メモリマッピングされた装置とのページの共有があり、当該メモリマッピングされた装置は、アクセス制御を変更するプロセスが所有するメモリのページへとマッピングされる。こうして、プロセスが所有するメモリアドレス空間内にあるメモリマッピングされた装置には、同じプロセスが所有するメモリの或るページ又は他のページにアクセスする権利を与えられてもよい。
【0087】
所有プロセスによって指定できる共有アクセスの更なる形態には、物理アドレスメモリのページがどの他のプロセスもアクセスが許可され且つどの個別のプロセスにも所有されないという、グローバル共有ステータスがある（幾つかの実施形態の例では、固有のＢＤＩＤが全てのグローバルページと関連付けられるように設けられてもよい）。所有プロセスは、確実に、その所有プロセスの機密データがそのグローバル共有されたページへと書き込まれないようにしてもよい。
【0088】
図１５は、所有権回路としての働きをする所有権・上書き追跡ハードウェアが、プロセスから受信された共有許可を変更する要求に対応するのにどのような働きをするかを概略的に示す。ステップ９００において、処理は、共有許可を変更する要求が受信されるまで待機する。こうした要求が受信されると、ステップ９０２は、当該ページを所有しているとページ所有権テーブル内で示されるプロセスから、アクセス許可を変更する要求が受信されているかどうかを判断する。所有プロセスから要求が受信されると、ステップ９０４はその要求されたアクセス許可変更を行い（例えば図１４に示すアクセス制御ステータス選択肢の１つを導入する）、処理はステップ９００に戻る。ステップ９０２において、当該ページを所有していないプロセスからの要求と判断された場合、処理が再びステップ９００に戻る前に、ステップ９０６が、要求された変更を無視して、任意で、間違った及び／又は不適切な変更要求が受信されたことを警告する。
【0089】
図１０と共に述べたように、ハイパーバイザは異なる実行環境の実行をスケジュールする働きをしてもよい。これらの異なる実行環境は、自身の物理メモリアドレス空間のページをそれぞれ所有する。ハイパーバイザが１つのゲスト実行環境の処理を停止して他のゲスト実行環境の処理を開始すると、これが実行コンテキストのスイッチとなり、このプロセスのスイッチがアクティブとなる。このコンテキストの切り替えは保護された例外対応によって行われてもよい。コンテキストの変更が生じる際のプロセッサ又はより広いシステムの状態データは、例えばレジスタ内容、設定変数及びプログラムステータス値等の多くの状態パラメータを含んでもよい。この状態データはコンテキストデータであり、他のゲスト実行環境又はハイパーバイザ自体に対しては使用可能にならないようにすることが望まれているプライベート情報を表してもよい。図１６Ａ及び図１６Ｂは、実行コンテキストをどのように保護できるかを示すフロー図である。
【0090】
ステップ１０００において、処理は、強制的に他のプロセスに向かうといった、コンテキスト切り替え割り込みが受信されるまで待機する。ステップ１００２は、割り込みされるプロセス（ゲスト実行環境）が所有するコンテキストデータメモリ８１４の一部に再始動データを保存する。この再始動データは、幾つかの実施形態の例では、割り込みされたプロセスを再始動させるのに十分な状態データとなりうるが、割り込みされたプロセスに依存する全ての状態データを含む必要はない。例として、再始動データは一般的な目的レジスタ内容を含んでもよいが、キャッシュ内容や変換ルックアサイドバッファ内容といったマイクロアーキテクチャ状態を含む必要はない。ステップ１００２で割り込みされたプロセスが所有するコンテキストデータメモリ８１４の一部へと再始動データを保存するのに続いて、ステップ１００４は、現在のプロセスに依存しており且つ他のプロセスへのスイッチを受けて任意の他のプロセスがアクセス可能となりうる状態データを、破壊的に上書きする働きをする。上書きされたデータは再始動データの上位集合であってもよい。上書きされたデータとしては、マイクロアーキテクチャデータも除外されてもよいし、新たに始動したプロセスがアクセスできない他のデータ、例えば、ページ所有権テーブル及び他のメカニズムの影響で、新たに始動したプロセスがアクセスできなくなる、割り込みされているプロセスが所有するメモリ領域内のデータも除外されてもよい。上書きは、例えば、現在のプロセスに依存するアクセス可能状態の全てを、ゼロ値、又は割り込みされているプロセスが実際に行った処理に依存しない他の所定値に設定する。そしてシステムはステップ１０００に戻り、次のコンテキスト切り替え割り込みを待つ。例えば高い例外レベルへのプロセス呼び出しといった、プロセスの強制終了の場合、例えばＲ０〜Ｒ７といったレジスタ内容の部分集合を、他のレジスタ／状態が格納されている呼び出し対象に受け渡して、出口及び再エントリ上に復元してもよい。
【0091】
図１６Ｂに示すように、ステップ１００５において、システムは新たなプロセスが開始されるまで待機する。ステップ１００６は、開始される新たなプロセスが、関連付けられたステータスがＣＰＵコンテキストデータ内で「準備完了（ｒｅａｄｙ）」になっているものかどうかを判断する働きをする。プロセスが準備完了状態でない場合、これは、既に実行がスケジュールされていて且つ少なくとも一度実行されていることを示し、すなわち、実行が再始動される前に復元されるべきそれ自身のコンテキストデータを有することを示す。開始されるプロセスが「準備完了状態」でない場合、ステップ１００８は、プロセスがコンテキストデータメモリ８１４内に所有するメモリのページから、プロセスの再始動データを復元する働きをする。開始されるプロセスが「準備完了」状態、例えば「初めての実行の準備完了」状態にある場合、ステップ１００８は回避される。最後に、ステップ１０１０において、新たなプロセスの実行が、プロセスがステップ１００５に戻って他の新たなプロセスを待つ前に開始される。
【0092】
図１７は、プロセス記述子テーブル内の複数のプロセス記述子エントリの１つとなりうるプロセス記述子エントリを示す。プロセス記述子エントリは、例えばブラインドドメイン識別子（ＢＤＩＤ）を含む。また、ページ記述子エントリは、当該プロセスから切り替えられる際に当該プロセスのためのコンテキストデータが保存される（そして当該プロセスはそこから復元される）コンテキストデータメモリ８１４内のロケーションへのポインタ（ハンドル）も含む。このポインタは、当該プロセスが所有するメモリの領域を示す。また、ページ記述子エントリは、以下に更に述べられる現在のプロセスステータスも含む。
【0093】
図１８は、プロセスに対するプロセスステータス状態の例を概略的に示す。使用が中止されたプロセスは無効とマークされ、そのＢＤＩＤを新たなプロセスによって再請求できるようになる。ハイパーバイザは、プロセスの作成及びプロセス記述子エントリの設定を担当してもよい。そのプロセスの初期化は、上述したように、セキュリティ制御部と連動して行われてもよい。後続の、プロセスによって導入できる次の状態は「消去」状態である。これは、当該プロセスＢＤＩＤは請求されており、プロセスによって所有権に関連付けられたページは消去中であり、例えば当該ＢＤＩＤの先の使用に対するページ所有権テーブル内に存在するエントリは削除され、そしてＢＤＩＤ用の新たなページが請求されて消去される（破壊的な上書きが行われる）ことを示す。消去が完了すると、当該プロセスは「準備」状態に切り替えられ、これは、当該プロセスはオープンであり、自身のページを追加する準備が整っていることを示す。ページの追加が完了すると、プロセスは「実行」状態に変化し、クローズされて実行の準備が整う。ここでは、ドメイン内のＣＰＵ実行コンテキストのステータスフィールド内に格納され、プロセス実行が開始されるときに再始動データを復元するかどうかを制御するのに用いられる第１の実行状態の準備が整う。図１８は、その実行準備に沿って順番にプロセスが通過する複数のプロセス状態を含むプロセスの「ライフサイクル」を示す。これらの状態の数および特定の形態は変化してもよい。
【0094】
少なくとも幾つかの実施形態の例は、プロセスを実行するかしないかを切り替える際にそのプロセスの状態データを格納するのに用いることができるブラインドドメイン実行コンテキスト（又はフレーム）ＢＤＥＣを含む。この状態データには、当該プロセスが既に或る実行を経験したかどうかの表示が含まれる。プロセスがまだ実行されていなかった場合、この例では、「新（ｎｅｗ）」とマークされる（上述した「準備完了(ready)」状態を参照）。実行コンテキストデータには、プロセスが終了した時点での汎用レジスタ内容といった状態データも含まれてもよい。これらのレジスタ内容は、プロセスが再始動したときに復元されてもよい。ここでは、プロセスが（例えばソフトウェア関数呼び出しを受けて）自主的に終了したのか、（例えばハードウェア割り込みを受けて）非自主的に終了したのかを更に特定するステータスパラメータが存在し、この情報を、プロセスをどのように再始動するか、また、プロセスとして事前に形成されたアクションをどのように終了するかを制御するのに用いてもよい。コンテキストデータは、当該プロセスに対してプライベートとなるように格納されてもよい。
【0095】
各ＢＤＥＣは、新、自発的終了（Ｖｏｌｕｎｔａｒｙ＿Ｅｘｉｔ）、非自発的終了（Ｉｎｖｏｌｕｎｔａｒｙ＿Ｅｘｉｔ）、自発的完了（Ｖｏｌｕｎｔａｒｙ＿Ｃｏｍｐｌｅｔｅ）、非自発的完了（Ｉｎｖｏｌｕｎｔａｒｙ＿Ｃｏｍｐｌｅｔｅ）、及び無効といった状態の表示を含んでもよい。ＢＤＥＣは、ドメインを所有する例外レベルの表示と、ドメイン用の汎用レジスタ内容（例えばＲ０〜Ｒ３０、ＰＣ、Ｐ−Ｓｔａｔｅ等）と、ドメイン用の例外レベルレジスタ内容（例えばＴＴＢＲ＿ＥＬｘ等）とも含んでもよい。
【0096】
一般的に、対応する物理アドレスブロックへのアクセスを例外制御する所有者プロセスが複数のプロセスであることを、対応する物理アドレスブロックにそれぞれ示す１つ以上のエントリを備える、所有権テーブルが設けられてもよい。これにより、複数のプロセスのいずれか１つが、他のプロセスによる物理アドレス空間の所定の領域へのアクセスを制限するために、その領域を排他的に制御できるようにするのに有用となる。これは、一般的なシステムでは不可能である、低い特権レベルのプロセスが、より高い特権をもつプロセスによるデータへのアクセスを制御又は制限できるようにするのに特に有用である。
【0097】
一般的に、対象の物理アドレスブロックの所有権を要求する要求プロセスには幾つかの手段が存在してもよい。対象の物理アドレスブロックは、要求において直接的に識別されてもよいし、仮想アドレス又は中間アドレスを特定することで間接的に識別されてもよいし、或る他の手法で識別されてもよい。所有権要求は、例えば（上記の請求開始命令といった）専用所有権要求命令であってもよいし、所有権が所定のページに対して要求されることを示すパラメータを伴う他の種類の命令であってもよく、又は、例えば或る他のプロセスを生じさせて所有権要求を開始する或る制御情報を設定することで、要求が他の種類の所有権要求コマンド（必ずしも命令でなくてもよい）に対応してもよい。処理回路は、所有権要求に応答して、要求プロセスがこのとき対象ページの所有者になったことを示すように所有権テーブルを更新できる。従って、要求プロセスは、例えば、機密データをメモリに書き込む前に、対応するアドレスブロックの所有権を要求することで機密データを保護することができる。
【0098】
所定のアドレスブロックの所有権が一方のプロセスから他方に変更する場合、機密情報が古い所有者から新たな所有者に漏出しないように幾つかの技術を用いることができる。１つの方法は、上記の例に述べられるように、所有権を要求しているプロセスが、対象ブロックに対する所有者プロセスとして有効となる前に、そのブロック内の各アドレスを上書きする上書き手続きを無事に完了させるようにすることである。これは、上書き手続きを実際に行うハードウェア、又は、上書き手続きを実行するが無事に完了したかどうかをハードウェアが確認する要求プロセスそのものか他の信頼されたプロセスかのいずれかによって実施できる。上書き手続きが無事完了したかどうかをハードウェアが確認する１つの方法として、所有権請求開始コマンドと所有権請求終了コマンドとの間で行われる１つ以上の書き込み動作において上書きされる物理アドレスに、対象ブロックの全ての物理アドレスが含まれているかどうかを確認してもよい。所有権請求開始コマンドと所有権請求終了コマンドとの間で行われる書き込みが全てのアドレスブロックを連続的に網羅していない場合、上書き手続きは失敗であり、要求者は正当には所有者になれないとしてもよい。例えば、これらの確認は、上述したように、完了した書き込みとそのアドレスオフセットとの数を追跡する請求カウント値を用いて行うことができる。なお、上書き手続きによって対象ブロックの各物理アドレスにおけるデータが無事に上書きされたかを判断する他の技術が存在してもよいことが理解されよう。
【0099】
幾つかの実施形態は、メモリに書き込まれたデータを暗号化し、メモリから読み取られたデータを復号化する暗号化回路を設けてもよい。各プロセスは１つ以上の関連付けられたキーを有してもよく、また、特定のアドレスブロックに書き込まれたデータは、そのブロックの所有者と関連付けられたキーを用いて暗号化され、メモリからデータを読み戻すことで復号化されてもよい。暗号化を備えるシステムでは、１つのプロセスと関連付けられたデータが、アドレスブロックが他の所有者に移った後もメモリに残ったとしても、データは古い所有者のキーを用いて暗号化されていることから、新たな所有者はそれを読むことができないため、上書き手続きは必須でなくてもよい。
【0100】
とはいえ、セキュリティの向上のために、暗号化機能がある場合でも、アドレスブロックの所有権が移されるときにそのブロックに対して上書き手続きを行うようにするのが好ましいといえる。暗号化及び上書き手続きの両方を組み合わせることは、所有者プロセスが、ブロックの所有権が移されるときにデータが失われるという危険に晒されることなく、自身が所有しているアドレスブロックのそれぞれに求められる暗号化レベルを変更できるという利益も有する。異なる暗号化モードは、例えば異なるレベル又は強さの暗号化を備えてもよい。
【0101】
一般的に、所有権テーブルの対応するエントリが、現在のプロセスが対象の物理アドレスにアクセスするのを所有者プロセスに許可されていないことを示す場合に、現在のプロセスからの、そのアドレスにおけるデータへのアクセス要求を拒否するように、所有権保護回路が設けられてもよい。例えば、所有権保護回路は上記のＢＤＭＵを備えてもよいし、或いは、メモリ制御部内に設けられる或る回路であってもよい。所有者プロセスは、所有者の許可に満たない要求を拒否することで、所有するアドレスブロックへのアクセスを排他的に制御できる。
【0102】
所有権保護回路に加えて、ハイパーバイザ、仮想マシン又はオペレーティングシステムといった特定のプロセスによって設定されるアクセス許可を実施するアクセス制御回路も存在してもよい。例えばアクセス制御回路は、上述したようなＭＭＵに対応できる。アクセス制御回路が特定の特権レベルの特定のプロセスによって設定された許可を実施する（例えば、ハイパーバイザが、例えば異なる仮想マシン間でアドレス空間を区切るようにする）一方で、所有権保護回路は、そうした許可が求められるページの所有権を要求することで、どのプロセスにも、その特権レベルに関わらず他のプロセスに許可を実施させることができる。
【0103】
この技術は、２つ以上のハイパーバイザ、１つ以上の仮想マシン、１つ以上のゲストオペレーティングシステム、及び１つ以上のアプリケーションをサポートするシステムに対して特に有用となりうる。しかしながら、より一般には、この技術は、複数のプロセスが共存し且つ１つのプロセスが他のプロセスによるデータへのアクセスを防止しうる任意のシステムに適用できる。
【0104】
上述したように、ＰＯＴ５０は、ＰＯＴエントリ５２と関連付けられたＰＡから、基準時点においてＰＡに変換されたＶＡ又はＩＰＡへの「逆変換マッピング」を効果的に表すアドレスフィールド５８を含んでもよい。
【0105】
しかしながら、同様の技術を、物理アドレスでインデックスされた任意のテーブルにもより一般的に適用でき、この物理アドレスについては、少なくとも１つのエントリが、アドレス変換回路によって対応する物理アドレスに変換された第１アドレスを識別してもよい。物理アドレスから、第１アドレスから変換された物理アドレスへの逆マッピングのスナップショットを保持することで、マッピングがまだ同じであるかどうかを後から確認することが可能になり、テーブルの内容の有効性に影響しうるアドレスマッピングにおける後続の変化を検出するのに有益となりうる。
【0106】
一般的に、処理回路は、所定の物理アドレスに対応するテーブルのエントリにおいて、そのときアドレス変換回路によって所定の物理アドレスへと変換されている第１アドレスを記録することへの関連事象の発生に対応できる。関連事象は、例えば、所定の物理アドレスのテーブルへの新たなエントリの割り当てや、所定の物理アドレスのテーブルに存在するエントリにおける情報の更新や、所定のタイプの命令（例えば所定の第１アドレスを指定する命令）の実行や、又はデータ処理装置のオペレーティングモードの所定の変更（例えば安全モードへの変更）であってもよい。従って、テーブル内に記録された第１アドレスは、第１アドレスと、関連事象の際に存在していた対応する物理アドレスとの間のマッピングを表してもよい。
【0107】
その後、アドレス変換回路によって対象物理アドレスへと変換される対象第１アドレスを指定するアクセス要求が受信されると、制御回路は、対象第１アドレスと対象物理アドレスに対応するテーブルのエントリが指定した第１アドレスとの間に齟齬がないかどうかを判断できる。例えば、これによって、アドレスマッピングが関連事象とまだ同時であるかどうかが効果的に判断され、テーブルに格納されている第１アドレスにつながる。これらのアドレス間に齟齬がある場合、要求を拒否するか又はエラーを知らせることができる。
【0108】
幾つかの場合では、物理的にインデックスされたテーブルは、過去のアドレスマッピングを追跡すること及びそれらが後になってもまだ同じであるかどうかを検出することだけを目的に設けられてもよく、つまり、物理的にインデックスされたテーブルは、第１アドレスそのもの以外の情報を一切含む必要がない。
【0109】
この技術はどの物理的にインデックスされたテーブルにも使用できるが、対応する物理アドレスブロックの所有者を示し、所有者がそれらのアドレスへのアクセスを排他的に制御できる、上述した形態の所有権テーブルに対して特に有用である。逆物理−第１アドレスマッピングをテーブル内に記録することで、アドレスマッピングの変更によって機密情報が失われうる上記のような種類の攻撃の防止を助けることができる。
【0110】
幾つかの場合では、第１アドレスは仮想アドレスであってもよい。他の場合では、第１アドレスは中間物理アドレスであってもよい。また、１つのテーブルが、第１アドレスが仮想アドレスである幾つかのエントリと、第１アドレスが中間アドレスである他のエントリとを有することも可能である。
【0111】
本願では、用語「…するように構成され」は、装置の要素が、定義された動作を実行することが可能な構成を有することを意味するように使用される。これに関連して、「構成」は、ハードウェア又はソフトウェアの相互接続の構造又は手法を意味する。例えば、装置が、定義された動作を提供する専用のハードウェアを有してもよいし、プロセッサ又は他の処理装置が、機能を行うようにプログラムされてもよい。「…するように構成され」は、装置要素が、定義された操作を提供するために何らかの方法で変更される必要があることを暗示するものではない。
【0112】
本発明の例示的な実施形態が、添付の図面を参照して本明細書に詳細に説明されているが、本発明はこれらの通りの実施形態に限定されないこと、そして当業者によって、添付の請求項に定義される本発明の範囲及び精神から逸脱することなく、実施形態に様々な変更及び変形をもたらすことができることが理解されよう。