特表 2022-503972 信頼される仲介レルム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-01-12

(54)【発明の名称】信頼される仲介レルム

(51)【国際特許分類】

   G06F 21/62 20130101AFI20220104BHJP

【ＦＩ】

G06F21/62

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2021517828

(86)(22)【出願日】2019-09-03

(85)【翻訳文提出日】2021-04-27

(86)【国際出願番号】 GB2019052447

(87)【国際公開番号】W WO2020079388

(87)【国際公開日】2020-04-23

(31)【優先権主張番号】1817041.5

(32)【優先日】2018-10-19

(33)【優先権主張国・地域又は機関】GB

(81)【指定国・地域】

(71)【出願人】

【識別番号】500395107

【氏名又は名称】アーム・リミテッド

(74)【代理人】

【識別番号】110000855

【氏名又は名称】特許業務法人浅村特許事務所

(72)【発明者】

【氏名】ウッド、ニコラス

(57)【要約】

メモリ・アクセス回路２６が、２つ以上のレルムの中から指定された所有者レルムを、所与のメモリ領域について、定義する所有権情報に基づいてメモリへのアクセスを制御し、各レルムは、処理回路８で実行するソフトウェア・プロセスの少なくとも一部分に対応する。所有者レルムは、所与のメモリ領域内に記憶されたデータに他のレルムがアクセスすることを排除する権利を有する。所与のレルムのセキュリティ構成パラメータが、所与のレルムはセキュリティ構成パラメータによって識別された信頼される仲介レルムと関連付けられると指定するとき、信頼される仲介レルムは、所与のレルムの少なくとも１つのレルム管理機能、たとえば、秘密鍵のプロビジョニング及び／又はセキュリティ構成パラメータの保存／復元、を実行することを可能にされ得る。これは、共通のパラメータを有する同じレルムの複数のインスタンスが、異なる時間に同じシステムで又は異なるシステムで確立される必要がある、使用事例を可能にし得る。

【特許請求の範囲】

【請求項1】

１つ又は複数のソフトウェア・プロセスに応答してデータ処理を実行するための処理回路と、
複数のレルムの中から指定された所有者レルムを、所与のメモリ領域について、定義する所有権情報に基づいて複数のメモリ領域へのアクセスを制御するためのメモリ・アクセス回路であり、各レルムが、ソフトウェア・プロセスのうちの少なくとも１つの少なくとも一部分に対応し、前記所有者レルムが、前記所与のメモリ領域内に記憶されたデータに他のレルムがアクセスすることを排除する権利を有する、メモリ・アクセス回路と、
所与のレルムに関連するセキュリティ構成パラメータに基づいて前記所与のレルムの動作を制御するためのレルム管理ユニットと
を備える装置であって、
前記所与のレルムの前記セキュリティ構成パラメータが、前記所与のレルムが、前記セキュリティ構成パラメータによって識別される信頼される仲介レルムと関連付けられると指定するとき、前記レルム管理ユニットが、前記所与のレルムの少なくとも１つのレルム管理機能を前記信頼される仲介レルムが実行することを許すように構成された、装置。

【請求項2】

前記レルム管理機能が、前記所与のレルムの前記セキュリティ構成パラメータの少なくとも一部分を更新することを含む、請求項１に記載の装置。

【請求項3】

ルート・レルム以外の各レルムが、前記レルムを作成した対応する親レルムと関連付けられ、
前記レルム管理ユニットが、前記信頼される仲介レルムを前記所与のレルムの前記親レルム以外のレルムとして定義する前記セキュリティ構成パラメータをサポートするように構成された、請求項１及び２のいずれか一項に記載の装置。

【請求項4】

前記レルム管理ユニットが、前記所与のレルムの作成中に前記親レルムによって発行された少なくとも１つのコマンドに基づいて、前記所与のレルムが前記信頼される仲介レルムと関連付けられるかどうかを設定するように構成された、請求項３に記載の装置。

【請求項5】

前記レルム管理ユニットが、目標レルムを識別する証明書コマンドに応答して、前記目標レルムのプロパティを証明する証明書を提供するように構成された、請求項１から４までのいずれか一項に記載の装置。

【請求項6】

前記所与のレルムの前記セキュリティ構成パラメータが、前記目標レルムは前記信頼される仲介レルムと関連付けられると指定するとき、前記証明書が、前記目標レルムは前記信頼される仲介レルムと関連付けられることを示す情報を含む、請求項５に記載の装置。

【請求項7】

前記目標レルムの前記セキュリティ構成パラメータが、前記目標レルムは前記信頼される仲介レルムと関連付けられると指定するとき、前記目標レルムの前記証明書が、仲介レルム証明書情報を指定し、
前記仲介レルム証明書情報が、前記信頼される仲介レルムのプロパティを証明する、又は前記目標レルムと関連付けられた前記信頼される仲介レルムの証明書を前記証明書の受信者が要求することを可能にするための情報を提供する、請求項５及び６のいずれか一項に記載の装置。

【請求項8】

前記レルム管理ユニットが、所与のレルムがアクティブ化されるまで、前記所与のレルムを前記処理回路が処理することを防止するように構成され、そして、
前記レルム管理ユニットが、前記所与のレルムと関連付けられた前記信頼される仲介レルムが、前記所与のレルムがアクティブ化される前に、前記所与のレルムの証明書の生成をトリガすることを許すように構成された、請求項５から７までのいずれか一項に記載の装置。

【請求項9】

前記レルム管理ユニットが、前記所与のレルムの少なくとも１つのプロビジョニング済みの秘密を前記信頼される仲介レルムが提供することを許すように構成され、前記プロビジョニング済みの秘密が、
前記所与のレルムと関連付けられたデータを保護するための少なくとも１つの秘密鍵と、
前記少なくとも１つの秘密鍵を導出するための鍵材料と
のうちの少なくとも１つを含む、請求項１から８までのいずれか一項に記載の装置。

【請求項10】

前記レルム管理ユニットが、前記所与のレルムの前記少なくとも１つのプロビジョニング済みの秘密を前記信頼される仲介レルム以外のレルムが提供することを禁止するように構成された、請求項９に記載の装置。

【請求項11】

前記レルム管理ユニットが、所与のレルムがアクティブ化されるまで、前記所与のレルムを前記処理回路が処理することを防止するように構成され、
前記レルム管理ユニットが、前記所与のレルムがアクティブ化される前に前記信頼される仲介レルムが前記所与のレルムの前記少なくとも１つのプロビジョニング済みの秘密を提供することを許すように構成され、
前記レルム管理ユニットが、前記所与のレルムがアクティブ化された後に前記所与のレルムの前記少なくとも１つのプロビジョニング済みの秘密を前記信頼される仲介レルムが提供することを防止するように構成された、請求項９及び１０のいずれか一項に記載の装置。

【請求項12】

前記レルム管理ユニットが、前記信頼される仲介レルムによって提供される鍵管理ポリシー情報に基づいて前記少なくとも１つのプロビジョニング済みの秘密のプロビジョニングを管理するように構成された、請求項９から１１までのいずれか一項に記載の装置。

【請求項13】

前記レルム管理ユニットが、前記所与のレルムに関連付けられた少なくとも１つのサブセットの前記セキュリティ構成パラメータを示すセキュリティ構成記録を前記信頼される仲介レルムが記録することを許すように構成された、請求項１から１２までのいずれか一項に記載の装置。

【請求項14】

前記レルム管理ユニットが、前記信頼される仲介レルムが前記信頼される仲介レルムによって前に記録されたセキュリティ構成記録に基づいて前記所与のレルムに関連付けられた少なくとも１つのサブセットの前記セキュリティ構成パラメータを更新することを許すように構成された、請求項１から１３までのいずれか一項に記載の装置。

【請求項15】

前記レルム管理ユニットが、前記信頼される仲介レルムによって提供されるポリシー情報に基づいて、前記セキュリティ構成記録の記録又は前記セキュリティ構成記録からのセキュリティ構成パラメータの復元を管理するように構成された、請求項１３及び１４のいずれか一項に記載の装置。

【請求項16】

前記所与のレルムの前記セキュリティ構成パラメータが、
レルム・タイプと、
前記所与のレルムと関連付けられた保護されたアドレス範囲と、
デバッギングが前記所与のレルム内で可能にされるかどうかの指示と、
前記メモリ・アクセス回路によるアクセス制御を受ける第１のメモリから第２のメモリへのデータのエクスポートが許されるかどうかの指示と、
前記所与のレルムと関連付けられたデータを保護するための少なくとも１つの秘密鍵の導出のための鍵材料と
のうちの少なくとも１つを含む、請求項１から１５までのいずれか一項に記載の装置。

【請求項17】

前記所有者レルムが、前記所有者レルムより大きな特権レベルで実行されるプロセスによる前記所与のメモリ領域へのアクセスを防止する権利を有する、請求項１から１６までのいずれか一項に記載の装置。

【請求項18】

１つ又は複数のソフトウェア・プロセスに応答してデータ処理を実行するステップと、
複数のレルムの中から指定された所有者レルムを、所与のメモリ領域について、定義する所有権情報に基づいて複数のメモリ領域の所有権を行使し、各レルムは、前記ソフトウェア・プロセスのうちの少なくとも１つの少なくとも一部分に対応し、前記所有者レルムは、前記所与のメモリ領域内に記憶されたデータに他のレルムがアクセスすることを排除する権利を有する、ステップと、
所与のレルムに関連付けられたセキュリティ構成パラメータに基づいて前記所与のレルムの動作を制御するステップと
を含み、
前記所与のレルムの前記セキュリティ構成パラメータが、前記所与のレルムが、前記セキュリティ構成パラメータによって識別された信頼される仲介レルムと関連付けられると指定するとき、前記信頼される仲介レルムは、前記所与のレルムの少なくとも１つのレルム管理機能を実行することを許される、データ処理方法。

【請求項19】

命令実行環境を提供するためにホスト・データ処理装置を制御するためのコンピュータ・プログラムであって、
複数のレルムの中から指定された所有者レルムを、所与のメモリ領域について、定義する所有権情報に基づいてシミュレートされたメモリ・アドレス空間の複数のメモリ領域へのアクセスを制御するためのメモリ・アクセス・プログラム論理であり、各レルムが、前記命令実行環境において実行される複数のソフトウェア・プロセスのうちの少なくとも１つの少なくとも一部分に対応し、前記所有者レルムが、前記所与のメモリ領域内に記憶されたデータに他のレルムがアクセスすることを排除する権利を有する、メモリ・アクセス・プログラム論理と、
所与のレルムに関連付けられたセキュリティ構成パラメータに基づいて前記所与のレルムの動作を制御するためのレルム管理プログラム論理と
を含み、
前記所与のレルムの前記セキュリティ構成パラメータが、前記所与のレルムが、前記セキュリティ構成パラメータによって識別された信頼される仲介レルムと関連付けられると指定するとき、前記レルム管理プログラム論理は、前記所与のレルムの少なくとも１つのレルム管理機能を前記信頼される仲介レルムが実行することを許すように構成された、コンピュータ・プログラム。

【請求項20】

請求項１９に記載の前記コンピュータ・プログラムを記憶する記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本技法は、データ処理の分野に関する。

【背景技術】

【0002】

メモリ・アドレス空間内の特定のメモリ領域のアクセス権を行使するためのメモリ・アクセス制御技法を提供することが知られている。より高い特権レベルを実行するプロセスが、より少ない特権を有するプロセスがメモリ領域にアクセスすることを排除することができるように、これらは、通常は、特権レベルに基づき得る。

【発明の概要】

【課題を解決するための手段】

【0003】

少なくともいくつかの実例は、１つ又は複数のソフトウェア・プロセスに応答してデータ処理を実行するための処理回路と、複数のレルムの中から指定された所有者レルムを、所与のメモリ領域について、定義する所有権情報に基づいて複数のメモリ領域へのアクセスを制御するためのメモリ・アクセス回路であり、各レルムは、ソフトウェア・プロセスのうちの少なくとも１つの少なくとも一部分に対応し、前記所有者レルムは、前記所与のメモリ領域内に記憶されたデータに他のレルムがアクセスすることを排除する権利を有する、メモリ・アクセス回路と、所与のレルムに関連するセキュリティ構成パラメータに基づいて所与のレルムの動作を制御するためのレルム管理ユニットとを備え、所与のレルムのセキュリティ構成パラメータが、所与のレルムはセキュリティ構成パラメータによって識別された信頼される仲介レルムと関連付けられると指定するとき、レルム管理ユニットは、所与のレルムの少なくとも１つのレルム管理機能を信頼される仲介レルムが実行することを許すように構成される、装置を提供する。

【0004】

少なくともいくつかの実例は、１つ又は複数のソフトウェア・プロセスに応答してデータ処理を実行するステップと、複数のレルムの中から指定された所有者レルムを、所与のメモリ領域について、定義する所有権情報に基づいて複数のメモリ領域の所有権を行使し、各レルムは、ソフトウェア・プロセスのうちの少なくとも１つの少なくとも一部分に対応し、前記所有者レルムは、前記所与のメモリ領域内に記憶されたデータに他のレルムがアクセスすることを排除する権利を有する、ステップと、所与のレルムに関連するセキュリティ構成パラメータに基づいて所与のレルムの動作を制御するステップとを含み、所与のレルムのセキュリティ構成パラメータが、所与のレルムはセキュリティ構成パラメータによって識別された信頼される仲介レルムと関連付けられると指定するとき、信頼される仲介レルムは、所与のレルムの少なくとも１つのレルム管理機能を実行することを許される、データ処理方法を提供する。

【0005】

少なくともいくつかの実例は、命令実行環境を提供するためにホスト・データ処理装置を制御するためのコンピュータ・プログラムであって、複数のレルムの中から指定された所有者レルムを、所与のメモリ領域について、定義する所有権情報に基づいて、シミュレートされたメモリ・アドレス空間の複数のメモリ領域へのアクセスを制御するためのメモリ・アクセス・プログラム論理であり、各レルムは、命令実行環境において実行される複数のソフトウェア・プロセスのうちの少なくとも１つの少なくとも一部分に対応し、前記所有者レルムは、前記所与のメモリ領域内に記憶されたデータに他のレルムがアクセスすることを排除する権利を有する、メモリ・アクセス・プログラム論理と、所与のレルムに関連するセキュリティ構成パラメータに基づいて所与のレルムの動作を制御するためのレルム管理プログラム論理とを含み、所与のレルムのセキュリティ構成パラメータが、所与のレルムはセキュリティ構成パラメータによって識別された信頼される仲介レルムと関連付けられると指定するとき、レルム管理プログラム論理は、所与のレルムの少なくとも１つのレルム管理機能を信頼される仲介レルムが実行することを許されるように構成される、コンピュータ・プログラムを提供する。

【0006】

記憶媒体は、コンピュータ・プログラムを記憶し得る。記憶媒体は、非一時的記憶媒体でもよい。

【0007】

本技法のさらなる態様、特徴及び利点は、以下のような添付の図面と併せて読まれることになる、以下の実例の説明から明らかとなろう。

【図面の簡単な説明】

【0008】

【図1】第１のメモリ及び第２のメモリ内に記憶されたメモリ領域を使用する複数の処理要素を含むデータ処理システムを概略的に示す図である。

【図2】実行される複数のプロセスの関係と、それらのプロセスに関連する特権レベルと、どのプロセスが所与のメモリ領域を所有するか及びそれに応じてその所与のメモリ領域へのアクセスを制御するための排他的権利を有するかを制御するためのそれらのプロセスに関連付けられたレルムとを概略的に示す図である。

【図3】レルム管理ユニット及びメモリ管理ユニットによる管理下のメモリ領域を概略的に示す図である。

【図4】処理要素と、メモリに記憶されたレルム管理制御データとのより詳細な実例を示す図である。

【図5】親レルムが様々な子レルムのプロパティを記述するレルム記述子を定義することができる、レルムの階層の実例を示す図である。

【図6】レルム階層の異なる実例を示す図である。

【図7】レルム階層の異なる実例を示す図である。

【図8】親レルムによって、その子レルムのレルム記述子を記録するために保持される、レルム記述子ツリーの実例を示す図である。

【図9】レルム記述子の内容の実例を示す図である。

【図10】異なるレルム・ライフサイクル状態を示すテーブルである。

【図11】レルムのライフサイクル状態の変化を示す状態機械の図である。

【図12】所与のメモリ領域の所有権テーブルにおけるエントリの内容を示すテーブルである。

【図13】所有者以外のどのレルムが領域にアクセスすることを許されるかを制御するために所与のメモリ領域について設定することができる可視性属性を示すテーブルである。

【図14】レルム管理ユニットによって排他的アクセス向けに確保されたＲＭＵプライベート・メモリ領域に対応する状態を含む、メモリ領域の異なるライフサイクル状態の実例を示す図である。

【図15】所与のメモリ領域のライフサイクル状態の遷移を示す状態機械を示す図である。

【図16】所与のメモリ領域の所有権が親レルムとその子レルムとの間をどのように通過することができるかを示す図である。

【図17A】所有者レルムによって設定された許可に基づくメモリ・アクセスの制御の直交レベルを提供する特権レベル及びレルム管理ユニット・レベルに依存する、メモリ制御属性を定義するページ・テーブルに基づいて提供されるメモリ・アクセス制御を概略的に示す図である。

【図17B】変換ルックアサイド・バッファの実例を示す図である。

【図18】ページ・テーブル及びＲＭＵテーブルに基づいてメモリへのアクセスを制御する方法を示す流れ図である。

【図19】サブレルムの親レルムと関連付けられたプロセス内の指定のアドレス範囲に対応するサブレルムの使用を示す図である。

【図20】パラメータ署名の実例を示す図である。

【図21】パラメータ署名が期待される署名とマッチしないときにレルムのアクティブ化を制約する方法を示す図である。

【図22】それが、別のレルムによって使用されるのと同じ鍵又はセキュリティ構成でレルムを開始するために有用になり得る、使用事例の実例を示す図である。

【図23】それが、別のレルムによって使用されるのと同じ鍵又はセキュリティ構成でレルムを開始するために有用になり得る、使用事例の実例を示す図である。

【図24】レルムが、信頼される仲介レルムと関連付けられ得る、実例を示す図である。

【図25】仲介レルムを使用する目標レルムのレルム管理機能を制御する例示的方法を示す図である。

【図26】目標レルムの証明書を生成する方法を示す図である。

【図27】使用され得るシミュレータ実例を示す図である。

【発明を実施するための形態】

【0009】

特権ベースのメモリ・アクセス制御方式において、より大きな特権を有するプロセスは、より少ない特権を有するプロセスがどのメモリ領域にアクセスすることができるかを定義する、アクセス許可を設定することができる。しかしながら、これは、一般に、より少ない特権を有するプロセスにアクセス可能な任意の領域がより大きな特権を有するプロセスにもアクセス可能であることを暗示し得る。したがって、所与のオペレーティング・システム又は仮想マシンの下で実行するすべてのアプリケーションは、オペレーティング・システム又は仮想マシンと関連付けられたソフトウェアを信頼する必要があり得、所与のハイパーバイザの下で実行するすべてのオペレーティング・システム又は仮想マシンは、ハイパーバイザを信頼する必要があり得る。

【0010】

いくつかの使用事例において、より大きな特権を有するプロセスのこの信頼は、望ましくないことがある。たとえば、データセンタでは、いくつかの仮想マシンが、データセンタを管理するクラウド・プラットフォーム・プロバイダによって提供されるハイパーバイザの制御下でそれぞれ実行する、いくつかの異なるパーティによって提供され得る。所与の仮想マシンのプロバイダ（又は所与の仮想マシンの下で実行するアプリケーション）は、たとえば、それのデータをハイパーバイザに又は他の仮想マシンに公開することを望まないことがある。たとえば、バンキング・プロバイダは、バンキング・アプリケーションを実行するための仮想マシンを提供し得、機密金融情報がハイパーバイザに又は同じ物理プラットフォームを共用する他の仮想マシンにアクセス可能になることを望まないことがある。

【0011】

装置は、１つ又は複数のソフトウェア・プロセス（たとえば、アプリケーション、オペレーティング・システム／仮想マシン、ハイパーバイザなど）の処理をサポートするための処理回路を有し得る。メモリ・アクセス回路は、複数のレルムの中から指定された所有者レルムを、所与のメモリ領域について、定義する所有権情報に基づいてメモリ・アドレス空間のいくつかのメモリ領域へのアクセスを制御するために、提供され得る。各レルムは、ソフトウェア・プロセスのうちの少なくとも１つの少なくとも一部分に対応する。所与のメモリ領域の所有者レルムは、所与のメモリ領域内に記憶されたデータに他のレルムがアクセスすることを排除する権利を有する。したがって、アクセス許可が、どのプロセスが所与のメモリ領域にアクセスする（読む又は書き込む）ことを可能にされるかを単に定義する、特権ベースのモデルとは対照的に、レルムベースの手法で、所有者レルムは、他のどのレルムがそれの所有するメモリ領域にアクセスするかを制御するための能力を有する。したがって、単一のプロセスが、より少ない特権を有するプロセスによるアドレス空間へのアクセスのためのトップダウンのルールを定義する、通常の特権ベースのモデルではなくて、アドレス空間の異なる部分が、アドレス空間のその部分へのアクセスの制御を有する異なるレルム所有者を割り当てられ得る、メモリ・アクセスの分散型制御が存在する。この手法は、同じ特権レベルにおいて又はより高い特権レベルにおいて動作するプロセスを含む他のプロセスによるアクセスから所与のレルムがそれのデータを保護することを可能にする。

【0012】

いくつかの実例において、このレルムベースの手法は、所与のメモリ領域のアクセス権の複数の重複するセットが存在するように、特権ベースのメモリ保護モデルと並行して適用され得る。より高い特権プロセスによって設定された特権ベースの許可、及び対応するメモリ領域の所有者レルムによって設定されたアクセス許可。それが、両方のセットの許可を満たす場合に、メモリ・アクセスは、可能にされ得る。

【0013】

レルム管理ユニットは、所与のレルムに関連するセキュリティ構成パラメータに基づいて所与のレルムの動作を制御するために、提供され得る。たとえば、セキュリティ構成パラメータは、情報、たとえば、レルム・タイプ（どのプロパティをレルムは有するか又はどの動作をレルムは実施することができるかを統制することができる）、所与のレルムと関連付けられた（所与のレルムによって安全にアクセスされ得るメモリ領域の範囲にマークを付け得る）保護されたアドレス範囲、及び、メモリ・アクセス回路による保護の範囲外の外部メモリへのメモリ・アクセス回路を使用するメモリ保護装置からのデータのデバッギング又はエクスポートなどの動作が許されることになるかどうかに関する他の情報、を定義することができる。また、セキュリティ構成パラメータは、たとえば、所与のレルムに関連するデータを保護するための少なくとも１つの秘密鍵を導出するための鍵材料を含み得る。様々な異なるセキュリティ構成パラメータがレルムのために定義され得ることが理解されよう。

【0014】

後述の技法において、所与のレルムのためのセキュリティ構成パラメータは、所与のレルムが、セキュリティ構成パラメータによって識別された信頼される仲介レルムと関連付けられると指定し得る。レルム管理ユニットは、所与のレルムの少なくとも１つのレルム管理機能を信頼される仲介レルムが実行することを許し得る。そのような信頼される仲介レルムのプロビジョニングは、同じレルムの別個のインスタンスは、たとえば、異なる時点において及び／又は異なる物理プラットフォームで、セットアップされる必要がある、いくつかの使用事例を可能にするために有用になり得、同じレルムの各インスタンスが、確立されているレルムの特定のインスタンスにかかわらずレルムが予想どおりに動作することを可能にするために、いくつかの共通の構成パラメータへのアクセスを必要とする。セキュリティ及び信頼をさらに維持しながら、そのような共用される構成パラメータが、所与のレルム自体によって、又はハードウェア・プラットフォームによって、反復可能な方式で確立されることは困難になり得る。所与のレルムのある種のレルム管理機能を実行することを可能にされた信頼される仲介レルムを定義することによって、これは、１つのプラットフォームから別のプラットフォームへのレルムの安全な移行、或いは負荷バランシング又は冗長性を目的とした異なる物理システムで同じシステムを実行する同じレルムの複数のインスタンスへの共通の秘密鍵のプロビジョニングなどの使用事例を可能にし得る。信頼される仲介レルムは、メモリ・アクセス回路によって提供される独自の所有権保護を有するレルム自体なので、これは、信頼される仲介レルム自体のセキュリティは、信頼される仲介レルムによって管理されるレルムが安全であるという信頼をもたらすことが確認及び証明され得る、ということを意味する。

【0015】

レルム管理機能は、所与のレルムのセキュリティ構成パラメータの少なくとも一部分を更新することを含み得る。場合により、セキュリティ構成パラメータを更新するこの能力は、レルム・ライフ・サイクル内のある種のステージ、たとえば、所与のレルムのアクティブ化の前、に制約され得る。レルムは、それがアクティブ化されるまで、処理回路によって処理されることを可能にされないことがある。

【0016】

ある種のセキュリティ構成パラメータの更新を管理することができる信頼される仲介レルムを提供することによって、これは、プラットフォーム間でレルムを移行すること或いはレルムの前のバージョンを保存又は復元する又は共通のセキュリティ構成を有する同じレルムの複数のインスタンスを開始することをより単純にする。

【0017】

１つの実例において、ルート・レルム以外の各レルムは、レルムを作成した対応する親レルムと関連付けられ得る。レルム管理ユニットは、信頼される仲介レルムを所与のレルムの親レルム以外のレルムとして定義するセキュリティ構成パラメータをサポートし得る。すなわち、信頼される仲介レルムは、必要に応じて、親レルムとして定義され得るが、アーキテクチャはまた、信頼される仲介レルムが親レルム以外のレルムとして定義されることを可能にする。

【0018】

したがって、親レルムは、レルムを最初に作成し得るが、時には、親レルム自体は、所与のレルムのある種のセキュリティ構成パラメータ、たとえば、レルムによって使用されることになるデータを保護するための秘密鍵を導出するための鍵材料、を認識していると信頼されていないことがある。仲介によって管理される目標レルムのある種のセキュリティ構成パラメータを親レルム以外のレルムが確立することを可能にすることによって、これは、複数のレルムが同じセキュリティ構成を有する必要がある場合に、より大きなセキュリティを可能にし得る。たとえば、信頼される仲介レルムは、バンキング・プロバイダ、医療提供者、又は管理されたレルムがある種の機密情報へのアクセスを有することを意図する他のパーティによって提供されるソフトウェアに基づいて動作させられるレルムになり得るが、親レルムは、バンキング／医療提供者などによって信頼されていないことがあるクラウド・プラットフォームで実行するハイパーバイザになり得る。

【0019】

レルム管理ユニットは、所与のレルムの作成中に親レルムによって発行される少なくとも１つのコマンドに基づいて、所与のレルムは信頼される仲介と関連付けられるかを設定し得る。したがって、親レルムと信頼される仲介レルムとの両方が、所与のレルムのライフサイクルのある種のステージにおいて、ある種のセキュリティ構成パラメータを設定する能力を有し得る。後述するように、パラメータ署名方式が、セキュリティ構成パラメータが、それがアクティブ化される前に、所与のレルムのために正しく設定されてあるかどうかを証明するために使用され得る。これは、信頼される仲介レルムによって定義されるものとしてのある種のセキュリティ構成設定をレルムが有することを確実にする必要があるパーティが、正しい信頼される仲介レルムが関わっていることをチェックすることができるように、親レルムがレルムの作成中に信頼される仲介レルムを正しく構成したことをチェックするために使用され得る。これは、所与のレルムの信頼される仲介レルムの識別を不正確に設定する悪意のある親レルムから保護することができる。

【0020】

レルム管理ユニットは、証明書機能をサポートし得、そこでは、目標レルムを識別する証明書コマンドに応答して、レルム管理ユニットは、目標レルムのプロパティを証明する証明書を提供し得る。たとえば、証明書は、目標レルムの構成パラメータから導出された情報及び／又は目標レルムによって所有されるメモリ領域の内容を含み得る。証明書は、それの真正性を証明するある特定の鍵で署名され得る。

【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】

レルム管理データ１２２はまた、レルム退出又はエントリ時に所与のレルムに関連するアーキテクチャの状態を保存及び復元するために使用することができるレルム実行コンテキスト領域１２６を含む。レルム管理データはまた、どのレルムがそのメモリ領域の所有者レルムであるかを、メモリ・アドレス空間の各領域について、定義するレルム・グラニュール・テーブル（又は所有権テーブル）１２８を含む。所与のメモリ領域の所有者レルムは、そのメモリ領域内に記憶されたデータに他のレルム（より大きい特権を有するプロセスを含む）がアクセスすることを排除する権利を有する。このレルム管理データの使用について、以下でさらに詳しく論じる。一般に、レルム管理ユニット２０及びＭＭＵ２６は、そのレルムによって所有されているメモリ領域の所有者レルムによって定義された所有権を行使するメモリ・アクセス回路として見ることができる。これは、たとえば、クラウド・サーバ・オペレータによって提供されるハイパーバイザ３８の制御下で、他の異なるパーティによって提供されるいくつかの仮想マシン３６が実行し得る、クラウド・プラットフォームについて、特に有用になり得る。仮想マシンのうちの１つを提供するパーティは、それらのデータ及びコードがハイパーバイザにアクセス可能になることを望まないことがある。権限のより低い例外レベルで実行するレルムが、より大きい特権を有する例外レベルがそれのデータ又は命令にアクセスすることを排除することができる、レルムの概念を導入することによって、これは、他のパーティによって提供されるコードと物理ハードウェアが共用され得るクラウド・サービスでそれらのソフトウェアをインストールするためのコード開発者の信頼度を上げることができる、ブラインド・ハイパーバイザが提供されることを可能にする。

【0052】

図５に示すように、レルムは、ルート・レルム１３０以外の各レルムが、初期化コマンドを実行することによって子レルムを初期化した対応する親レルムを有する子レルムである、レルム階層に従って、ＲＭＵ２０によって管理される。ルート・レルム１３０は、たとえば、最も大きな特権を有する例外レベルＥＬ３において実行するモニタ・コード又はシステム・ファームウェアに関連するレルムでもよい。説明を容易にするために、図５の実例及び後に論じられる最初の実例は、各子レルムがその親レルムより低い特権を有するレベルにおいて実行する事例を示す。しかしながら、後述するように、その親と同じ例外レベルで実行するサブレルムを確立することもまた可能である。

【0053】

一般に、ＭＭＵ２６によって提供されるメモリ・アクセス制御のレルム管理部分について、子レルムは、その親レルムによって所有される任意のメモリ領域へのデフォルト・アクセス権を有する。同様に、所与のレルムの任意の子孫は、所与のレルムの所有されたメモリ領域へのアクセス権を有すると想定される。しかしながら、レルム管理制御は、例外レベルに基づいて変換テーブル１２０によって提供される制御に直交であるので、より高い特権レベルにおいて実行するプロセスは、それに応じて変換テーブル１２０のパラメータを設定することによって、権限のより少ないコードがそれのデータにアクセスすることをさらに排除することができる。したがって、一般に、所与の子レルムは、所与の子レルムによって所有された所与のメモリ領域に記憶されたデータにその親レルムがアクセスすることを排除する権利を有する。親レルムが所与のメモリ領域にアクセスすることを子レルムが実際に排除するかどうかは、所有権テーブル１２８において設定された制御属性に基づいて設定され得る（デフォルトは、親レルムは子レルムの所有された領域へのアクセス権を有さないということであるが、子レルムは、それに応じて可視性属性を設定することによって、親レルムにアクセス権を与えることを選択することができる）。複数の兄弟レルム（同じ親レルムを共有する異なる子レルム）が存在するとき、次いで、所与の子レルムは、所与の子レルムによって所有された所与のメモリ領域に記憶されたデータに兄弟レルムがアクセスすることを排除することができる。さらに、所有権テーブル１２８において設定された可視性属性は、兄弟レルムがどの程度互いのデータにアクセスすることができるかを制御することができる。別法として、子レルムがページをその親レルムに可視にした場合に、同ページは、それの兄弟レルム及び兄弟レルムのさらに子孫にも可視になるように、兄弟レルムによるアクセスは、親可視性属性に基づいて、制御され得る。いくつかの事例において、所有権テーブル１２８は、任意のレルムの下で実行する任意のプロセスがその所有するメモリ領域内のデータにアクセスすることを可能にすることを所与の所有者プロセスを許し得るグローバル可視性属性を有し得る。

【0054】

図５に示すように、各レルム１４０は、所与のレルムから退出するときに、レジスタ値など、レルムのアーキテクチャ状態を記憶するために使用することができる１つ又は複数のレルム実行コンテキスト（ＲＥＣ：Ｒｅａｌｍ Ｅｘｅｃｕｔｉｏｎ Ｃｏｎｔｅｘｔ）メモリ領域１２６に関連付けられている。所与のレルムのために提供されるＲＥＣ１２６の数は、所与のレルムの下でいくつの実行のスレッドが動作しているかに応じて決まり得る。たとえば、最初に初期化されるときのレルムは、単一の１次ＲＥＣ領域１２６と確立され得るが、次いで、そのレルムは、必要に応じてさらにＲＥＣの役割を果たすようにそのレルムによって所有される他のメモリ領域を構成することができる。ＲＥＣメモリ領域は、その実行状態がそのＲＥＣに記憶された対応するレルムによって所有される。

【0055】

各レルムは、そのプロパティがレルム記述子１２４に記述されたレルムの親レルムによって所有されているメモリ領域に記憶されたレルム記述子１２４と関連付けられている。レルムの所与の世代において定義することができる子レルムの数の柔軟性のために、レルム記述子は、さらに詳しく後述されるレルム記述子ツリー（ＲＤＴ：Ｒｅａｌｍ Ｄｅｓｃｒｉｐｔｏｒ Ｔｒｅｅ）と呼ばれるツリー構造を使用して、管理される。レルム記述子１２４は、セキュリティを確保するためにレルムからのエントリ又は退出時にＲＭＵ２０によってチェックすることができるレルムのプロパティを定義するために使用することができる。レルムについてのある指定のＲＭＵコマンドの実行が、レルムが安全な方式で作成される及び無効にされることを確実にするために、指定のライフサイクル状態に限定され得るように、レルム記述子はまた、様々なライフサイクル状態を通してレルムの進行を追跡することができる。

【0056】

図６及び７は、可能なレルム階層の２つの異なる実例を示す。図６の実例では、図２に示されたプロセスのそれぞれが、独自のレルムを定義されている。したがって、ルート・レルム１３０は、例外レベルＥＬ３において動作するモニタ・ソフトウェア又はファームウェアに対応する。ルート・レルムは２つの子レルム１４２を定義し、一方は、安全ＥＬ１で動作する安全オペレーティング・システムに対応し、もう一方は、ＥＬ２におけるハイパーバイザに対応する。ハイパーバイザは、ＥＬ１における異なるゲスト・オペレーティング・システムに対応する孫レルム１４４を定義し、それらのゲスト・オペレーティング・システムのそれぞれは、最も少ない特権を有する例外レベルＥＬ０において実行するアプリケーションに対応する曾孫レルム１４６をさらに定義する。同様に、レルム１４２内の安全オペレーティング・システムは、異なる安全アプリケーションに対応する孫レルム１４８を定義することができる。階層内の親レルムは、それが現在所有するメモリ・ページの所有者を新しい子レルムに移転することができ（後述するようにＧｒａｎｕｌｅ．Ａｄｄコマンドを使用することによって）、又はそれのページのうちの１ページを無効にし、それを子の仮想アドレス空間にマップし、ページ所有権（Ｃｌａｉｍ）コマンドを実行することによってページの所有権を子レルムが請求することを可能にすることができる。メモリ・アドレス空間の指定されたページが、コマンドを発行した親レルムによってすでに所有されていない場合、ページ所有権コマンドは拒否され得る。

【0057】

図７に示すように、特権のあらゆるレベルにおけるプロセスが別個のレルムを有することは必須ではなく、したがって、図７に破線で示された特権レベルの境界線のうちのいくつかは、レルム境界に対応しないことがある。たとえば、図７において、アプリケーション１５０及びそれのオペレーティング・システムは、例外レベルＥＬ２において動作するハイパーバイザ・レルム１４２と同じレルム内で実行し、そうして、単一のレルムが、ＥＬ２ハイパーバイザ・コード、ＥＬ１で動作するオペレーティング・システム、及びＥＬ０におけるアプリケーションの両方に広がる。他方で、同じハイパーバイザの下の異なるアプリケーション１５２は、独自の別個のレルムを定義され得る。この場合、レルム境界はＥＬ１とＥＬ０との間にあり、ＥＬ２－ＥＬ１レルム境界は存在しない（ハイパーバイザ及びオペレーティング・システムの両方が同レルム内で実行し得る）。別のオペレーティング・システムでは、別個のＥＬ１レルム１５４が定義され得、これは、オペレーティング・システムと同じレルム内で実行するいくつかのアプリケーション、及びそれら自体の専用のレルムを有する他のアプリケーションをさらに有し得る。同様に、安全側では、図７の安全なＯＳ及びアプリケーションは、ＥＬ３ルート・レルム内で完全に実行し、したがって、安全側で動作しているときにレルム境界は存在しない。したがって、レルムの正確な構成は、実行されているプロセスの必要性に応じて所与のシステムの実行時間において決定され得る。ソフトウェアは、それが小さい固定数の子レルムのみを必要とするか（低レベル・ファームウェアの場合に事実であり得る）或いは多数のレルム又は様々な数のレルムを必要とするか（たとえば、未知数のゲスト仮想マシンを管理することができる、クラウド・プラットフォーム上のハイパーバイザに有用であり得る）を実行時間において判定することができる。

【0058】

所与の親レルムのレルム記述子１２４は、レルム記述子ツリー（その親レルムのいくつかの子レルムのレルム管理データを定義するレルム管理ツリーの実例である）に従って、管理される。ツリーは、可変数のレベルを有する。図８は、指定の親レルムによって管理されるそのようなレルム記述子ツリー１６０の実例を示す。ツリー１６０は、いくつかのレルム記述子ツリー・エントリ（ＲＤＴＥ：Ｒｅａｌｍ Ｄｅｓｃｒｉｐｔｏｒ Ｔｒｅｅ Ｅｎｔｒｉｅｓ）１６４をそれぞれ含むいくつかのレルム記述子ツリー・グラニュール（ＲＤＴＧ：Ｒｅａｌｍ Ｄｅｓｃｒｉｐｔｏｒ Ｔｒｅｅ Ｇｒａｎｕｌｅｓ）１６２を含む。各ＲＤＴＥ１６４は、親レルムの所与の子レルムのレルム記述子１６６、又はレルム記述子ツリーの次のレベルのさらなるＲＤＴＧ１６２のいずれかへのポインタを提供する。ツリーの第１のレベルのＲＤＴＧ１６２は、親レルムに関連する（たとえば、親レルムのレルム記述子を有する）データの一部として記憶され得るレルム記述子ツリー・ポインタ１６８によって識別され得る。したがって、親レルムが、所与の子レルムに関連するＲＭＵコマンドを発行するとき、それは、必要とされる子レルムのレルム記述子１６６を見つけるために、ＲＭＵをトリガしてレルム記述子ツリーを走査することができる（そのレルム記述子がＲＭＵ２０内にすでにキャッシュされていない場合）。各ＲＤＴＧ１６２は、可変数のエントリ１６４を有し得る。

【0059】

図８のテーブルに示すように、ツリーの後続のレベルにおいてＲＤＴＧ１６２へのポインタを提供する所与のＲＤＴＥ１６４は、ポインタが示すＲＤＴＧにおけるエントリの最大数を示す位数値を含み得る。たとえば、位数値は、ポインタが示すＲＤＴＧにおけるエントリの総数に対応する２つのパワーを示し得る。ＲＤＴＥ１６４に含まれ得る他の情報は、ＲＤＴＥの状態（たとえば、ＲＤＴＥがレルム記述子ツリー・データの割当てのために空いているかどうか、及びＲＤＴＥがさらなるＲＤＴＧ１６２へのポインタ又は子レルム記述子１６６へのポインタを提供するかどうか）を示す状態値を含み得る。ポインタに加えて、ＲＤＴＥはまた、さらなるＲＤＴＥはそのＲＤＴＧ１６２に割り当てることができるかどうかを決定するために有用であり得る、空いていないＲＤＴＧへのポインタにおけるＲＤＴＥの数を追跡することができる参照数を含み得る。親レルムによってトリガされたＲＭＵコマンドは、ツリーのさらなるＲＤＴＧを確立する及び／又は既存のＲＤＴＧ内のＲＤＴＥの内容を編集するようにＲＭＵ２０を制御することができる。

【0060】

図８に示すツリーは１つの指定の親レルムの子レルムを示すことに留意されたい。それぞれの親レルムは、自らの子レルムを追跡する別個のレルム記述子ツリーを有し得る。ＲＤＴＧ１６２及び子レルム記述子１６６を含むツリーに関連するデータは、親レルムによって所有されるページ内に記憶され、そうして、他のレルムがこのデータにアクセスすることを排除することができる。したがって、より高い特権レベルで実行するプロセスが、レルムがそれが自分で直接作成した任意の子レルムよりも下に作成したものの可視性を有し得ないように、親レルムのみが、どの指定の子エルムをそれが構成したかの可視性を有し得る。

【0061】

図８に示すように、所与の親レルムの子レルムのそれぞれは、指定の子レルムを識別するためにその親レルムによって使用される、対応するレルム識別子（ＲＩＤ：Ｒｅａｌｍ ＩＤｅｎｔｉｆｉｅｒ）１６８を有し得る。ＲＩＤは、それが指定の親レルムに特有であるという点で、ローカル・レルム識別子である。異なる親レルムの子レルムは、同じローカルＲＩＤを有し得る。所与の子レルムの親レルムによって選択された任意の値を有するローカルＲＩＤを使用することは可能であるが、図８に示す手法では、所与の子レルムのローカルＲＩＤは、可変数の可変長ビット部分を有し、可変長部分のそれぞれは、レルム記述子ツリー１６０の所与のレベル内にインデックスを付けるためにＲＭＵ２０によって使用される。たとえば、図８のローカルＲＩＤ＝７を有する子レルムのレルム記述子は、第１のレベルＲＤＴＧ１６２のエントリ７内のレルム記述子ポインタをたどることによって、アクセスされる。ローカルＲＩＤ＝３．３を有する子レルムのレルム記述子は、ツリーの第１のレベル内のエントリ３、次いで、ツリーの第２のレベル内のエントリ３をたどることによって、アクセスされる。同様に、ローカルＲＩＤ＝１．２を有する子レルムのレルム記述子は、第１の層内のエントリ１と、第２の層内のエントリ２とをたどることによって、アクセスされる。図８は、簡潔にするために１０進値７、３．３などを使用するローカルＲＩＤを示すが、これらは、処理装置２における２進数の連結として実装されることになる、ということに留意されたい。

【0062】

所与のレルムのＲＩＤは、所与のレルムのレルム管理データにアクセスするためにレルム記述子ツリーのそれぞれのレベルにおいて使用されることになるインデックスの連結を含み得る。インデックスがそれらがツリーを通して進むために使用されることになるであろう順番と同じ順番で連結されることは必須ではないが、これはツリー・アクセスの管理をより単純にするので、望ましくなり得る。連結が低から高へ進むか高から低へ進むかは重要ではない。インデックスの連結には、進むべきツリーのさらなるレベルがいつ存在しないかをＲＭＵ２０が判定することを可能にすることができる所定の終了パターンが続き得る。

【0063】

いくつかの実装形態は、類似のツリー構造においてシステム内のすべてのレルムのレルム記述子を記憶し得るグローバル・レルム記述子ツリーに、このＲＩＤ構築技法を適用し得る（それぞれのＲＩＤがグローバルに一意の値である）。しかしながら、ソフトウェア開発は、１つのツリー内の所与の親の子レルムを定義することと、次いで、その子レルムを追跡するためにそれぞれの他の親レルムの別個のツリーを有することとによって、より単純にすることができる。したがって、レルム記述子ツリーは、所与の親レルムによって初期化された子レルムのレルム管理データを記憶するための所与の親レルムに関連するローカル・レルム記述子ツリーでもよい。したがって、レルム識別子は、所与の親レルムによって使用される指定の子レルムを識別するローカル・レルム識別子でもよい。異なる親レルムによって初期化された子レルムは、同値のローカル・レルム識別子有することを可能にされ得る。このようにして、親レルムは、他のどのようなレルムが他の親レルムによって確立されたかを意識することなく、どのＲＩＤがそれの子レルムのために使用されるかを選択することができ、親レルムがそれのレルム記述子ツリーを構成したやり方に応じて子レルムのＲＩＤは構築される。

【0064】

ローカル・レルム識別子は、ソフトウェア・プロセスによって発行されたレルム・エントリ命令又はＲＭＵコマンドによって使用され得る。しかしながら、ハードウェア・インフラストラクチャは、異なる親によって作成されたレルムを区別するために、所与の子レルムの絶対識別を使用することができる。したがって、図８に示されたローカル・レルム識別子に加えて、所与のレルムはまた、所与のレルムに一意であるグローバル・レルム識別子（又は「内部」レルム識別子）を有し得る。少なくとも１つのハードウェア構造は、ローカル・レルム識別子（ＬＲＩＤ：Ｌｏｃａｌ Ｒｅａｌｍ ＩＤｅｎｔｉｆｉｅｒ）の代わりにグローバル・レルム識別子（ＧＲＩＤ：Ｇｌｏｂａｌ Ｒｅａｌｍ ＩＤｅｎｔｉｆｉｅｒ）を使用する所与のレルムを識別することができる。たとえば、レルム・グラニュール・テーブル１２８及び／又はＴＬＢ１００は、グローバル・レルム識別子を使用し、レルムを識別することができる。

【0065】

いくつかの実例では、任意の２進法の値が、その子レルムを参照するために親レルムによって使用されるＬＲＩＤと完全に無関係であり得る、所与のレルムのＧＲＩＤとして割り当てられ得る。同じレルム・アーキテクチャの異なるマイクロ・アーキテクチャの実装形態は、ＧＲＩＤを割り当てるために異なる手法を使用し得る。

【0066】

しかしながら、１つの実例では、所与のレルムのＧＲＩＤは、それの先祖レルムのＬＲＩＤに基づいて構築され得る。これは、ＭＭＵ２６及びＲＭＵ２０によるアクセス制御に有用になり得る所与のレルムが別のレルムの子孫であるか又は別のレルムの先祖であるかのより単純な判定を可能にすることができるので、有用になり得る。

【0067】

すべてのローカルＲＩＤがツリー・インデックス手法の連結を使用して構築される必要はない。いくつかの事例では、ローカルＲＩＤの指定の値が、ある指定のデフォルト・レルムを参照するために確保されることが有用であることがある。現在のレルム又は現在のレルムの親レルムを指定するＲＭＵコマンドは、比較的一般的でもよい。したがって、所定のＲＩＤ値は、現在のレルムの親レルムを参照するために確保され得る。たとえば、すべてのビットが１に設定された（１の値を示す）ＬＲＩＤは、現在のレルムの親レルムを参照するために確保され得る。同様に、所定のレルム識別子値は、現在のレルム自体を参照するために確保され得る。たとえば、０のＬＲＩＤ値は、現在のレルムを参照するために使用され得る。

【0068】

ＲＭＵは、それがそれのレルム記述子ツリーを確立しているときにそれが満たさなければならない制約を問い合わせるために、所与のレルムによってトリガされ得る、ある種の問合せコマンドをサポートし得る。たとえば、問合せコマンドに応答して、ＲＭＵ２０（又は処理回路３２）は、所与のレルムによって定義されることを可能にされたレルム記述子ツリー１６０のレベルの最大数、所与のレルムのツリー構造の所与のレベルにおいて許されたツリー・エントリの最大数、及び／又は所与のレルムによって初期化され得る子レルムの最大数のうちの少なくとも１つを示す、制約値を返し得る。たとえば、システムは、指定のハードウェア実装形態のために使用されるＬＲＩＤ又はＧＲＩＤにおいて利用可能なビットの数などのプロパティを示し得るレジスタを含み得る。ＲＭＵ又は処理回路は、問合せコマンドに応答して、レルム識別子（又は、適切な応答は指定のプロセッサ実装形態のためのハードワイヤードでもよい）のために利用可能なビットの数をチェックし得、さらなる子を定義するために現在のレルムのためにいくつのビットが利用可能に残っているかを判定するために、識別子のいくつのビットがグローバル・レルム識別子において先祖レルムによってすでに使用されているかを指定する情報をチェックし得る。親レルムは、それのＲＤＴをどのように構築するかを決定するために、問合せコマンドへの応答を使用することができる。

【0069】

図９は、所与のレルムのレルム記述子１６６の内容の実例を示す。レルム記述子は、レルムのセキュリティ構成パラメータを定義し得る。これは単に１つの実例であり、他の実装形態は、掲載された情報のすべてを含まないことがあり、又は追加の情報を含み得ることが理解されよう。この実例では、レルム記述子は、以下を含む。
・レルムのグローバルＲＩＤ。したがって、ローカルＲＩＤに基づくレルム記述子ツリーを通過することによって、対応するグローバルＲＩＤは、識別することができ、これは、所与のレルムによってＴＬＢなどのハードウェア構造体にインデックスを付けるために、又は所有権テーブル若しくはＧＲＩＤに基づいて定義される他の情報をチェックするために、使用することができる。
・所与のレルムによってトリガされた所与のコマンドを受け入れるかどうかを決定するためにＲＭＵ２０によって使用され得る、所与のレルムのライフサイクル状態。
・所与のレルムのタイプ。たとえば、レルム・タイプは、後述するようなレルムが完全レルムであるかサブレルムであるかを示すことができる。
・対応するレルムの境界例外レベルを識別する、境界例外レベル（ＢＥＬ：Ｂｏｕｎｄａｒｙ Ｅｘｃｅｐｔｉｏｎ Ｌｅｖｅｌ）値。ＢＥＬは、レルムが実行することを許される最高の特権レベルを示す。たとえば、図７のレルム１４２はＥＬ２のＢＥＬを有し得、レルム１５２はＥＬ０のＢＥＬを有し得、そして、レルム１５４はＥＬ１のＢＥＬを有し得る。ＢＥＬは、現在のレルム内で例外が取られ得るかどうか、又は例外を処理するために親レルムへのレルム退出が必要とされるかどうかを判定するために、例外が発生したときに使用することができるので、レルム記述子においてＢＥＬを識別する明示的パラメータを提供することによって、これは、複数の例外レベルにわたるレルムの柔軟性を実現する。
・レルム及びその子孫によって所有されるメモリ領域（レルム保護グラニュール又はＲＰＧ）の総数を示すリソース・カウント。これは、レルム及びその子孫によって所有されるすべてのメモリ・ページが、それらのメモリ領域が異なるレルムに割り当てられ得る前に、無効にされる（及びデータを究極的にワイプされる）ことを確実にするために使用される。たとえば、リソース・カウントは、いくつの領域がまだ消去される必要があるかを追跡するために使用することができる。
・レルムの保護されたアドレス範囲の開始及び終了アドレス。たとえば、保護されたアドレス範囲は、その中でページは対応するレルムによって所有され得るメモリ・アドレス空間の範囲を定義し得る。レルム記述子において定義された保護されたアドレス範囲をメモリ・アクセスの後続のアドレスと比較することによって、レルムによって以前所有されたメモリ領域がもはやレルムによって所有されていない事例が識別され得るので、これは、子レルム・データにアクセスする試みにおいて子レルムに以前割り当てられた領域の所有権を再請求する悪意ある親レルムに対する保護のために有用であり得る。
・所与のレルムに関連するデータを暗号化する又は解読するために暗号回路１０４によって使用される１つ又は複数の暗号化鍵。この実例では、２つの別個の暗号化鍵が提供される。レルムによって所有される内容及びメモリを暗号化／解読するためのメモリ鍵と、前述のような永続記憶装置６にメモリ１６の間でエクスポート／インポートされるデータを暗号化／解読するためのページング鍵。しかしながら、他の実例では、同じ鍵が両方の目的のために使用され得、或いは、さらなる鍵が他の指定の目的のために提供され得る。
・レルム記述子ツリーのルートを識別するレルム記述ツリー・エントリ（ＲＤＴＥ）。レルム記述子におけるＲＤＴＥは、ルートＲＤＴＧにアクセスするためのポインタ（及び、そのＲＤＴＧのためのインデックスとしていくつのビットを使用するかを定義する位数値）を提供する。
・レルムの実行に関連するアーキテクチャの状態を保存又は復元するための１次ＲＥＣ（レルム実行コンテキスト）メモリ領域へのポインタ。

【0070】

さらに詳しく後述するように、レルム記述子はまた、他の情報、たとえば、信頼される仲介レルムの識別、デバッギング又はエクスポートがレルムについて可能にされるかどうかを定義する情報、及びレルムのアクティブ化と同時にレルムのパラメータの署名に照らしてチェックするための期待される署名、を含み得る。

【0071】

図１０は、この実例ではクリーン状態、新しい状態、アクティブ状態及び無効状態を含む、所与のレルムが存在することができる１組のライフサイクル状態を示す。図１０は、以下の各状態について示す、各状態のプロパティを要約する。対応する状態内のレルムが、その親レルムによって修正されたそれのレルム記述子１６６のパラメータを有し得るかどうか、そのレルムのために指定された暗号化鍵が有効に使用され得るかどうか、レルムが任意のメモリ領域（ＲＰＧ）を所有し得るかどうか、並びに、そのレルムに関連するコードが実行可能か否か。レルム記述子のパラメータはクリーン状態において修正可能であるが、その他の状態のいずれでも修正することはできないことに留意されたい。これは、悪意ある親レルムが所与のレルムのプロパティを、それがアクティブになった後に、更新することを防止する。また、レルムは、アクティブ状態においてのみ実行可能である。

【0072】

図１１は、レルムのライフサイクル状態の可能にされた遷移を示す状態機械図である。図１１に示された各状態遷移は、子目標レルムのローカルＲＩＤを指定するレルム管理コマンドを、ＲＭＵ２０に対して、発行する親レルムによってトリガされる（Ｒｅａｌｍ．Ｉｎｖａｌｉｄａｔｅコマンド２１２はまた、目標レルム自体によって発行され得る）。前のレルムはそのローカルＲＩＤのために定義されておらず、レルム記述子レジスタ・グラニュール・コマンド２００が親レルムによって実行されるとき、これは、指定されたローカルＲＩＤを有する子レルムのレルム記述子として親レルムによって所有されている所与のメモリ領域の構成をトリガする。子レルムのグローバルＲＩＤは、親レルムのグローバルＲＩＤとレルム記述子レジスタ・グラニュール・コマンド２００において指定された新しいローカルＲＩＤとの連結に基づいて、設定され得る。指定された子レルムは、次いで、クリーン状態２０２に入る。クリーン状態において、親レルムは、子レルムのレルム記述子の様々なパラメータを更新することによって、子レルムのプロパティを設定することができる。これらのプロパティは、親レルムによって発行されたさらなるＲＭＵコマンドを使用し、修正することができる（指定された子レルムがクリーン状態にない場合、コマンドを修正するそのようなレルム記述子は拒否され得る）。また、信頼される仲介と関連付けられたレルムについて、コマンドを修正するレルム記述子はまた、そのパラメータが修正されている目標レルムのレルム記述子において識別された指定の信頼される仲介レルムによって発行された場合に、受け付けられ得る。親レルムが、子レルムのレルム記述子のパラメータの設定を終えたとき、親レルムは、子レルムのＬＲＩＤを指定するレルム初期化コマンド２０４を実行し、これは、クリーン状態２０２から新しい状態２０６への子レルムの遷移をトリガし、この時点で、レルム記述子のパラメータは、もはや親レルムによって修正不可能である。指定されたレルムが現在、クリーン状態にない場合、レルム初期化コマンド２０４は失敗することになる。

【0073】

レルムが新しい状態２０６にあるとき、レルムのローカルＲＩＤを指定するレルム・アクティブ化コマンド２０８の実行は、新しい状態２０６から、レルムが現在実行可能であるアクティブ状態２１０への遷移をトリガし、この後、対応するレルム内へのレルム・エントリは、もはや障害をトリガしないことになる。レルムは現在、完全に動作可能である。後述するように、いくつかの実例において、アクティブ化は、パラメータ署名のチェックに依存し得る。クリーン状態２０２、新しい状態２０６、及びアクティブ状態２１０のうちのいずれかにおける子レルムの親レルムによってトリガされた後続のレルム無効化コマンド２１２は、無効状態２１４への遷移をもたらすことになる。無効状態２１４を離れ、クリーン状態２０２に戻るために、親レルムは、レルム消去コマンド２１６を実行しなければならない。レルムによって所有されるページの数を追跡するリソース・カウントが、ゼロ以外の値を有する場合、レルム消去コマンド２１６は拒否される。したがって、レルム消去コマンド２１６が成功するために、親レルムは先ず、無効レルムによって所有されるあらゆるページのためにＧｒａｎｕｌｅ．Ｒｅｃｌａｉｍコマンドを発行しなければならない。Ｇｒａｎｕｌｅ．Ｒｅｃｌａｉｍコマンドは、目標メモリ・ページを指定し、目標ページの無効化をトリガしてそのページをアクセス不可能にし、そしてまた、ページの所有者レルムの参照数を１つ減らす。クリーン・コマンドが、その後に発行されてメモリ・ページを無効から有効に遷移させるとき、上書きが行われ得るので、Ｇｒａｎｕｌｅ．Ｒｅｃｌａｉｍ又はレルム消去コマンド２１６を実行するときに無効領域においてデータを実際に上書きする必要はない（後述の図１５を参照）。また、レルム消去コマンドに応答して、無効にされたレルムに関連する任意のキャッシュされたデータもまた、処理要素８、１０、１２のいずれか（ＲＭＵコマンドを実行する処理要素のみならず）のＴＬＢ１００又はキャッシュ１１０内で、無効にされ得る。グローバルＲＩＤは、キャッシュされたデータのそのような無効化をトリガするために使用され得る。

【0074】

したがって、所与のレルム識別子に関連するレルムの管理されたライフサイクルを提供することによって、これは、レルムがそれのパラメータが修正され得るクリーン状態に戻り得る前に（したがって、所与のレルム識別子が、異なるレルムによる使用のためにリサイクルされ得る前に）、古いレルムに関連するいずれかのデータが同じレルム識別子の再使用を介して他のレルムに漏らされることを防止するために、同じレルム識別子を使用した前のレルムに関連するデータはメモリ及び任意のキャッシュから消去されなければならないことを確実にする。レルムがクリーン状態２０２にあるとき、それのレルム記述子はまた、レルム記述子において記憶されたメモリ領域が他の目的のために割り当てられることを可能にするレルム記述子解放コマンド２１８を実行することによって、キャンセルすることができる（この時点で、レルムはすでにクリーンであるので、消去は必要とされない）。

【0075】

図１２は、レルム・グラニュール・テーブル１２８（又は所有権テーブル）のエントリの内容の実例を示す。各エントリは、メモリ・アドレス空間の所与のメモリ領域に対応する。所与のメモリ領域のサイズは、実装形態により、固定でも又は可変でもよい。所有権テーブル１２８が構造化される具体的なやり方は、実装形態の要件に応じて有意に変化し得、したがって、所与のエントリの対応するメモリ領域が識別される具体的なやり方は、変化し得る（たとえば、データは、対応する領域を識別する各エントリにおいて記憶され得、或いは、別法として、対応するエントリは、テーブル自体の中の対応する所有権エントリの位置に少なくとも部分的に基づいて識別され得る）。さらに、図１２は、所与のメモリ領域について指定され得るパラメータの指定の実例を示すが、他の実例は、より多くの情報を提供し得る、又は示された情報のタイプのうちの一部を省略し得る。

【0076】

図１２に示すように、各所有権テーブル・エントリは、対応するメモリ領域について、以下を指定することができる。
・そのメモリ領域の所有者レルムを識別するグローバルＲＩＤ。所有者レルムは、他のどのレルムがメモリ領域にアクセスすることを可能にされるかを制御する属性を設定する権利を有するレルムでもよい。
・どのＲＭＵコマンドがメモリ領域で実行されることを可能にされるかを制御するために使用される対応するメモリ領域のライフサイクル状態。
・メモリ領域が所有者レルムによって所有されるようになった時点でＭＭＵ２６によってメモリ領域がマップされた先のマップされたアドレス。マップされたアドレスは、仮想アドレス又は中間物理アドレスでもよい。所有権テーブルにおいてこのアドレスを指定することによって、これは、所与のメモリ領域の所有権をレルムが取得した後に、アドレス変換テーブルを再マッピングすることによってレルム・インフラストラクチャによって提供されるセキュリティを回避しようとする潜在的な企てに対して保護することができる。
・所有者に加えてどのレルムがメモリ領域にアクセスすることができるかを指定する可視性属性。たとえば、図１３に示すように、可視性属性は、現在のレルムの親レルムは領域にアクセスすることを許可されるか否かを制御する親可視性ビットと、任意のレルムが対応するメモリ領域にアクセスすることができるかどうかを指定することができるグローバル可視性ビットとを指定することができる。一般に、レルム保護方式は、現在のレルムの子孫レルムはその親又は先祖レルムによって所有されるメモリ領域にアクセスすることを常に許可されると仮定し得る（特権レベルに基づく保護を提供する変換テーブル１２０に基づいてアクセスが許されるか否かに依存する）が、所与のレルムは、その親又は所与のレルムの直接の子孫ではない任意の他のレルムがメモリ領域にアクセスすることができるかどうかを制御し得る。いくつかの実施例において、親及びグローバル可視性ビットの両方が、所有者レルム自体によって設定され得る。別法として、親可視性ビットが所有者レルムによって設定され得る一方で、グローバル可視性ビットは、所有者レルムの親レルムによって設定されることが可能であることがある（メモリ領域の親可視性ビットがそのメモリ領域の親可視性を与えるようにすでに設定されてあることを条件として）。これは、他のどのプロセスがそれのデータにアクセスし得るかを所有者レルムがどのように制御し得るかの１つの実例にすぎない、ことが理解されよう。

【0077】

図１４は、そこに所与のメモリ領域が存在し得る異なるライフサイクル状態を示すテーブルであり、そして、図１５は、それぞれのライフサイクル状態の間の遷移をトリガするコマンドを示す状態機械である。図１１に示されたレルム・ライフサイクル状態と類似のやり方で、１つのレルムの所有権から別のレルムの所有権へと渡るメモリ領域が、その領域内のデータが消去される（たとえば、ゼロに設定される）無効化プロセスを先ず経なければならないということを確保するために、メモリ領域ライフサイクル状態の間の遷移は、管理される。したがって、無効状態２２０から、ソフトウェアがメモリ領域にアクセスすることができる有効状態２２２に遷移するために、クリーン・コマンド２２４は、処理要素８で実行するソフトウェアによってトリガされ、ＲＭＵ２０によって実行される必要がある。クリーン・コマンド２２４は、指定のメモリ領域（ページ）を識別し、対応するメモリ領域のメモリ・アドレスを通ってそのメモリ領域内の各場所においてデータを無効化する／ゼロに設定するようにＲＭＵを制御する。目標とされたメモリ領域が無効以外のいずれかの状態にある場合、クリーン・コマンドは拒否される（たとえば、障害がトリガされる）。

【0078】

いくつかのシステムでは、単にメモリ領域ライフサイクル状態として有効状態２２２及び無効状態２２０を提供することが十分であることがある。しかしながら、図１５の実例では、処理回路３２で実行するソフトウェア（任意のＲＭＵソフトウェア以外の）によってトリガされるＲＭＵプライベート・メモリ領域へのアクセスが拒否されることになるように、所与のメモリ領域はまた、ＲＭＵ２０自体によって排他的アクセス向けに確保された「ＲＭＵプライベート」メモリ領域として指定され得る。これは、前述のように、レルム記述子、レルム記述子ツリー・エントリ、レルム実行コンテキスト及びページングのためのメタデータなどのレルム管理データを記憶するために特に有用になり得る。ＲＭＵによって排他的アクセス向けに確保されたＲＭＵプライベート・メモリ領域として所与のメモリ領域を指定するために属性を提供することによって、これは、レルム方式によって提供されるセキュリティ保護をソフトウェア・プロセスが回避することをさもなければ可能にすることができたであろうレルム管理データへのアクセスを、メモリ領域自体の所有者プロセスを含む、ソフトウェア・プロセスが行うことを防止することができる。

【0079】

したがって、クリーン・コマンド２２４は、これが通常のクリーン・コマンドであるかプライベート・クリーン・コマンドであるかを指定するプライバシ指示を、それのパラメータのうちの１つとして、指定することができる。別法として、２つの完全に別個のコマンドが、これらの目的のために提供され得る。クリーン・コマンドが通常のクリーン・コマンドであるとき、これは、前述のような有効状態２２２への遷移をトリガする。しかしながら、クリーン・コマンドがプライベート・クリーン・コマンド２２４であるとき、これは、ＲＭＵＣｌｅａｎ状態２２６への遷移をトリガし、ＲＭＵＣｌｅａｎ状態２２６では、メモリ領域はＲＭＵプライベート・メモリ領域として指定される。いくつかの実例では、全タイプＲＭＵデータは、ＲＭＵクリーン状態に対応する単一のタイプのＲＭＵプライベート・メモリ領域内に記憶され得る。

【0080】

しかしながら、頑強性が、指定の形のレルム管理データにそれぞれ対応する複数のタイプのＲＭＵプライベート・メモリ領域を指定することによって、改善され得る。たとえば、図１４及び１５では、指定の目的のために指定されたＲＭＵプライベート領域にそれぞれ対応する、いくつかのＲＭＵＲｅｇｉｓｔｅｒｅｄ状態２２８が、定義される。この実例では、ＲＭＵＲｅｇｉｓｔｅｒｅｄ状態２２８は、ＲＭＵＲｅｇｉｓｔｅｒｅｄＲＤＴ（レルム記述子ツリーのＲＤＴＧを記憶するための）、ＲＭＵＲｅｇｉｓｔｅｒｅｄＲＤ（レルム記述子を記憶するための）、ＲＭＵＲｅｇｉｓｔｅｒｅｄＲＥＣ（レルム実行コンテキスト・データを記憶するための）及びＲＭＵＲｅｇｉｓｔｅｒｅｄＭＤＴ（前述のようなエクスポート／インポート動作中に使用されるページング・メタデータを記憶するための）を含む。異なる形の登録コマンド２３０が、ＲＭＵＲｅｇｉｓｔｅｒｅｄ状態２２８のうちの対応する１つにメモリ領域を遷移させるために、ＲＭＵＣｌｅａｎ状態におけるメモリ領域のＲＭＵによって実行され得る。指定された目的（ＲＤＴ、ＲＤ、ＲＥＣ又はＭＤＴ）に対応しないＲＭＵプライベート・メモリ領域にデータを記憶するためのコマンドは、拒否され得る。したがって、ＲＭＵＲｅｇｉｓｔｅｒｅｄ状態の第１のライフサイクル状態において、第１のタイプのレルム管理データを記憶するための第１のタイプのＲＭＵコマンドが可能にされ得、そして、第２のライフサイクル状態において、第２のタイプのレルム管理データを記憶するための第２のタイプのＲＭＵコマンドが可能にされ得、目標とされたメモリ領域が第２のライフサイクル状態にあるときには第１のＲＭＵコマンドが拒否され、そして、目標とされたメモリ領域が第１のライフサイクル状態あるときには第２のＲＭＵコマンドが拒否される。これは、たとえば、子レルムの動作を中断させようと試みるために、レルム記述子エントリをレルム実行コンテキスト領域に記憶しようと試みる又はその逆の、悪意ある親レルムを回避することによって、さらなるセキュリティを可能にし得る。それぞれのＲＭＵレジスタ状態２２８から、対応する形態の解放コマンド２３２は、対応するメモリ領域を無効状態２２０に返し得る。さらなるクリーン・コマンドは、領域が汎用データに再割り当てされ得る前に、前に定義されたＲＭＵプライベート領域からのデータの消去をトリガし得る。

【0081】

したがって、要約すると、所与の所有者レルムによってまだ所有されているが、それがＲＭＵによって排他的アクセス向けに確保されていることを意味する所有権テーブルにおいて指定された属性を有する、少なくとも１つのＲＭＵプライベート・メモリ領域が、定義され得る。この実例では、ＲＭＵプライベート状況を制御する属性は、所有権テーブル内の対応するエントリにおいて指定されたライフサイクル状態であるが、それはまた、他のやり方で識別され得る。ＭＭＵは、所与のメモリ領域が少なくとも１つの状況属性によってＲＭＵプライベート・メモリ領域として指定されたときに１つ又は複数のソフトウェア・プロセスによるその所与のメモリ領域へのアクセスを防止し得る。したがって、ＲＭＵ自体によってトリガされていない任意のソフトウェアでトリガされたアクセスは、それがＲＭＵプライベート・メモリ領域を目標とするとき、拒否され得る。これは、所有者レルム自体によるＲＭＵプライベート・メモリ領域へのアクセスの防止を含む。

【0082】

所有者レルムがそのメモリ領域内のデータにアクセスすることさえできない場合に、ＲＭＵプライベート・メモリ領域の所有者レルムを定義することが何故有用であるのかと疑問に思う人があるかもしれない。たとえば、ＲＭＵのみによってデータへのアクセスを行使するための代替手法は、ＲＭＵのための特別なレルムを定義すること、並びに、その特別なＲＭＵ所有者レルムにプライベートなものとして維持されることになるデータを記憶するためのメモリ・アドレス空間のページを割り当てることであろう。しかしながら、レルムを無効にするとき、そのレルムに関連するすべての制御データを無効化するという要件が存在することがあり、そして、この制御データが、無効にされたレルムではなくて特別なＲＭＵ所有者レルムに関連していた場合、これは、無効にされたレルムのデータの消去をより複雑にする可能性があるということを本発明者は認識した。

【0083】

対照的に、ＲＭＵプライベート属性を使用することによって、所与のレルムの制御データを記憶するメモリ領域は、たとえ所有者がそれにアクセスすることができなくても、そのレルムによってまだ所有されており、これは、どのメモリ領域がその所有者レルムがキャンセルされたときに無効にされる必要があるかを識別することがより単純であるということを意味する。所与のレルムが無効にされるとき、親レルムは、指定された無効にされたレルム（又はその子孫）によって所有されているメモリ領域が無効にされる、及びアクセス不可能にされる、及び再請求コマンドをトリガした親レルムの所有権に返されるようにトリガする一連の再請求動作を単純に実行することができる（たとえば、次いでＲＭＵによる作用を受ける再請求コマンドを実行することによって）。再請求動作は、無効にされたレルムにアクセス可能なページに影響し得るのみならず、無効にされたレルムによって所有されるＲＭＵプライベート・メモリ領域も含み得る。

【0084】

そのレルムによって所有されるＲＭＵプライベート・メモリ領域内のレルムの制御データを記憶することのもう１つの利点は、エクスポート動作を実行するときである。レルムのメモリ・フットプリントをゼロまで減らすために、エクスポート動作中に、そのレルムに関連する管理構造体が、通常のメモリに加えて、エクスポートされ得る。それらの構造体がレルムによって所有されることを要求することは、このエクスポート動作の管理を単純化する。

【0085】

一般に、任意の種類のレルム管理データが、ＲＭＵプライベート領域において記憶され得るが、具体的には、レルム管理データは、以下のうちのいずれかを含み得る。所与のレルムのプロパティを定義するレルム記述子、所与のレルムのレルム記述子を記憶するメモリ領域を識別するレルム記述子ツリー・エントリ若しくはさらなるレルム記述子ツリー・エントリ、所与のレルム内の少なくとも１つのスレッドの実行に関連するアーキテクチャの状態を示すレルム実行コンテキスト・データ、及び所与のレルムに関連する所定の動作の中間点において使用される一時的作業データ。

【0086】

一般に、ＲＭＵプライベート領域は、所与のレルムに関連する指定のレルム制御データを記憶するために使用され得るが、それはまた、レルムがアクティブになると実行されるある指定の他の動作の周囲のセキュリティを向上させるために使用され得る。たとえば、データが暗号化又は解読される前述のページング・エクスポート又はインポート動作を実行し、メタデータを使用するチェックが実行されて、そのデータが再びインポートされるときにそのデータがまだ有効であることをチェックするとき、そのような動作は、多数の周期を取り得、そのような長く続く動作は、途中で中断される可能性が高い。再び最初から動作を開始する必要のないように、そのようなデータを他のプロセス（所有者レルム自体を含む）にアクセス可能にすることなく、中断されたときにもそのような長く続く動作に関連するメタデータ又は他の一時的作業データがキャッシュ／メモリ内に保持されることを可能にすることが望ましくなり得る。ＲＭＵプライベート領域としてメモリ・システムの領域を一時的に指定することによって、この一時的作業データを保護することができる。したがって、図１４に示すように、ページ状態はまた、この一時的作業データがメモリ領域に記憶されるときに使用することができるＲＭＵＥｘｐｏｒｔｉｎｇ及びＲＭＵＩｍｐｏｒｔｉｎｇ状態を含むことができ、そして、これらの状態のうちの１つが選択されるとき、次いで、ＲＭＵのみがそのデータにアクセスすることができる。

【0087】

ＲＭＵプライベートとして対応するメモリ領域を一時的に指定することから恩恵を受ける得る動作の他の実例は、以下を含み得る。所与のレルムによって所有される少なくとも１つのメモリ領域と所与のレルム以外のレルムによって所有される少なくとも１つのメモリ領域との間のデータの移転中の暗号化又は解読されたデータの生成又は検証と、別のレルムへのメモリ領域の所有権の移転と、無効にされたメモリ領域に記憶されたデータをアクセス不可能にさせるために実行される破壊的再請求動作。たとえば、アドレス空間の所与のページのすべての内容を消去するための再請求動作は、途中で中断され得、したがって、消去が完了するまで他のプロセスがそのページにアクセスすることができないことを確実にするために、そのページは、一時的にＲＭＵプライベートとして指定され得る。一般に、ＲＭＵによって実行される任意の長いレイテンシ動作は、長く続く動作を開始し、次いで、長く続く動作が完了するときにそれを変換し戻す前に、いくつかのメモリ領域のライフサイクル状態をＲＭＵプライベート状態に変換することによってそれの一時的作業データを保護させることから恩恵を受け得る。

【0088】

領域が、ＲＭＵプライベートとして指定されるとき、それは、レルム管理動作を実行するために使用されるＲＭＵ２０によるアクセスのために確保される。レルム管理動作は、以下のうちの少なくとも１つを含み得る。新しいレルムを作成することと、既存のレルムのプロパティを更新することと、レルムを無効にすることと、所与のレルムによる所有権のメモリ領域を割り当てることと、所与のメモリ領域の所有者レルムを変更することと、所与のメモリ領域の状態を変えることと、所与のメモリ領域の所有者レルムによってトリガされたコマンドに応答して所与のメモリ領域へのアクセスを制御するためのアクセス制御情報を更新することと、１つ又は複数のソフトウェア・プロセスの処理中にレルム間の遷移を管理することと、所与のレルムへの所与のレルムによって所有されるメモリ領域と異なるレルムによって所有されるメモリ領域との間の所与のレルムに関連するデータの移転を管理することと、所与のレルムに関連するデータの暗号化又は暗号解読。ＲＭＵは、レルム管理動作の少なくとも一部分を実行するためのハードウェア・ユニットでもよく、又はレルム管理動作の少なくとも一部分を実行するためにレルム管理ソフトウェアを実行する処理回路３２を備えてもよく、或いはその両方の組合せでもよい。

【0089】

図１５は、それが有効にアクセスされ得る、又は対応するページを無効化し得るように、所与のページをクリーニングするために所与のレルムによってトリガすることができる状態遷移を示す。図１６は、これを拡張して、１つのレルムから別のレルムに所与のページの所有権を移転するために使用することができるさらなるコマンドを示す。親レルムによる領域請求コマンド２３０の実行は、そのメモリ領域が、現在、無効状態２２０にあり、親レルムによって所有される場合に、対応するメモリ領域が指定された子レルムに移転されることを可能にする。目標メモリ領域が所与の子レルムの親レルム以外の任意のレルムによって所有されるとき、又はメモリ領域が有効である若しくはＲＭＵプライベート・ライフサイクル状態２２６、２２８のうちの１つにある場合、領域請求コマンド２３０は拒否される。これは、それ自体がアクセス権を有さない又はＲＭＵ２０によって使用中であるページの所有権を親レルムが任意に譲渡するのを防止する。ページが子レルムに譲渡された後は、次いで、その子レルムは、図１５に示すのと同じやり方で有効状態２２２に遷移するためにクリーン・コマンドを実行することができる。簡潔にするために、ＲＭＵプライベート領域の使用は図１６には示されていないが、任意の所与のレルム内で、プライベート・クリーン・コマンドは、別法として、前述のようなＲＭＵクリーン状態２２６にメモリ領域を遷移させ得る。

【0090】

グラニュール請求コマンド２３０は、すでに確立された子レルムに所有権を移転するために使用される。加えて、親レルムが、子に譲渡された領域にデータを書き込むことができるように、親レルムは、新しい状態にある新しい子レルムに所有権を譲渡するようにＲＭＵ２０をトリガするグラニュール追加コマンド２３２を実行することができる。たとえば、これは、新しい子レルムが第１の時間に実行することができるように、新しい子レルムのプログラム・コードをインストールするために使用することができる。したがって、追加コマンド２３２は、対応するメモリ領域が子レルムに割り当てられたライフサイクル状態に関して、請求コマンド２３０とは異なる。追加コマンド２３２は、図１１に示された新しい状態２０６に子レルムがあるときにのみ可能にされ得る。子レルムは、所有権テーブル１２８の対応するエントリを更新するようにＲＭＵをトリガするグラニュール解放コマンド２３４を実行すること、並びに子レルムのレルム記述子内のリソース・カウントなどのプロパティを更新することなどによって、その親に所与のメモリ領域の所有権を解放して返すことができる。指定されたメモリ領域が、グラニュール解放コマンド２３４を発行した現在のレルムによって所有されていない場合、又はその領域が無効以外の状態にある場合（それが親レルムによる所有権に返され得る前に、データの破壊的クリーニングを確保することが必要とされる）、グラニュール解放コマンド２３４は拒否され得る。

【0091】

親レルムが子レルムを初期化する、前述の階層的レルム構造を使用することの１つの利点は、これがレルム及びその子孫の無効化を大きく単純化するということである。所与の仮想マシン・レルムが無効にされようとする場合、そのとき、その仮想マシンの下で実行する任意のアプリケーションのレルムを無効化することもまた望ましくなり得ることは、比較的一般的である。しかしながら、無効にされようとするそれぞれのプロセスに関連する相当量のプログラム・コード、データ及び他の制御情報が存在し得る。データ消去の一部のみが実行されたとき、無効にされたレルムに関連するデータへのアクセスを継続することが不可能であるように、そのような無効化が微細に生じることを確実にすることが望ましくなり得る。各レルムが、前述のようなレルム階層なしに、他のレルムから完全に独立して確立された場合、対応するレルムＩＤによって識別される各レルムを別個に無効化するためにいくつかの別個のコマンドを提供することが必要になり得るので、これは、そのような微細な無効化を難しくし得る。

【0092】

対照的に、ルート・レルム以外の各レルムが、親レルムによってトリガされたコマンドに応答して初期化された子レルムであるように、ＲＭＵがレルムを管理するレルム階層を提供することによって、その場合、目標レルムの無効化を要求するコマンドが受信されるとき、ＲＭＵ２０は、より効率的動作で、目標レルム及び目標レルムの任意の子孫レルムを処理回路にアクセス不可能にさせることができる。

【0093】

具体的には、目標レルムの無効化に応答して、ＲＭＵは、目標レルムが無効であることを示すために目標レルムに関連するレルム管理データ（たとえば、レルム記述子）を更新し得るが、目標レルムの任意の子孫レルムに関連する任意のレルム管理データを更新する必要はない。子孫レルムに関連するレルム管理データは、変更されないままにすることができる。これは、所与のレルムへのアクセスがその親を介して制御され、したがって、親レルムが無効にされた場合、次いで、これは親レルムの子孫にアクセスすることもまた不可能であることを意味するので、レルム管理データが変わっていなくても、目標レルムを単純に無効化することは、任意の子孫レルムを実際にアクセス不可能にさせ得るからである。それぞれのレルムが、それの指定の子を識別するために親レルムによって定義されたローカルＲＩＤを使用するレルム・エントリ命令（後述のＥＲＥＴ命令）を使用して入られ、これは、所与の子レルムの親レルムによって所有されるメモリ領域に記憶されたレルム記述子を通過するために使用されるとき、その場合、親レルム以外のプロセスは、子レルムのレルム管理データにアクセスするためにＲＭＵをトリガすることができない。したがって、親レルムが無効にされた場合、次いで、ＲＭＵは、所与の子レルムのレルム管理データにアクセスすることができず、所与の子レルムがアクセス不可能になることを確実にする。

【0094】

レルムが無効にされた後、そのレルムの親レルムは、無効にされた目標レルムによって所有された各メモリ領域を再請求するための再請求動作を実行するようにＲＭＵをトリガし得る。たとえば、図１６に示すように、子レルムによって所有されているメモリ領域の再請求コマンド２３６は、メモリ領域の無効状態２２０への復帰をトリガすることができ、メモリ領域の所有権を親レルムに移転し戻すこともできる。しかしながら、この再請求動作は、他のレルムの進行中の処理のバックグラウンドで実行することができ、無効にされたレルムの任意の子孫レルムがアクセス不可能にされることを可能にするために瞬時に実行される必要はない。図１１に示すような所与のレルムのレルム状態をアクティブから無効に変えるための単一のアクションは、その無効にされたレルムの任意の子孫レルムに関連するすべてのデータもまたアクセス不可能であることを確実にするのに十分である。任意の親レルムは、それが所有するページをそれの子に譲渡することだけでき、子はそれが所有するページを孫レルムに譲渡することのみできるので、無効にされたレルムの任意のさらなる子孫レルムもまたその範囲内のページを所有することになるので、無効にされたレルム（図１６を参照）のレルム記述子に定義された保護されたアドレス範囲は、どのページを再請求すべきかを識別するために使用することができるので、これはまた、どのページが無効にされる及び所与のレルムを無効化したときに再請求される必要があるかを追跡することが比較的簡単であることを意味する。

【0095】

したがって、要約すると、レルム階層の使用は、レルムの管理及び無効化を大きく単純化する。そのような無効化、並びにメモリ内のデータの上書きと同時に、無効化はまた、無効化をトリガした処理要素８内のみならず、別のＣＰＵ又はＧＰＵなどの他の処理要素内にも保持される目標レルム及び目標レルムの任意の子孫レルムのキャッシュされたレルム管理データの無効化をトリガし得る。したがって、他の処理要素は無効にされたレルムへのアクセスを有し続けないことを確実にするために、他の処理要素への無効化のブロードキャストが存在し得る。そのような無効化をトリガするとき、所与の子レルムのグローバルＲＩＤが共通の接頭辞部分をその親レルムのグローバルＲＩＤと共用するように、キャッシュされたレルム管理データが、対応するレルムを一意に識別するグローバル・レルム識別子に関連付けられること、及び前述のようなグローバル・レルム識別子を形成することが有用になり得る。これは、所与のレルムが指定されたレルムＩＤの子孫であるかどうかを迅速に比較するためにビット・マスキング又は他の類似の動作が使用されることを可能にする。所与のレルムが、先祖レルムの無効化を介してアクセス不可能にされた場合、次いで、指定された目標レルムに入ろうとする試みは不可能である（そのレルムのためのＥＲＥＴ命令を実行するための親レルムが存在しないので）が、異なるレルム・エントリ機構を使用する他の実装形態においてでも、子孫レルムのレルム記述子がもはや位置確認不可能である場合、レルム・エントリは、失敗し、故障状態をトリガし得る。

【0096】

図１７Ａは、所与のメモリ・アクセスが許可されたかどうかを判定するために、ＭＭＵ２６及びＲＭＵ２０によって実行されるチェックの一実例を表す。ＭＭＵ２６は、所与のゲスト・オペレーティング・システムによってセットされたステージ１ページ・テーブル１２０－１の制御のもとで、仮想アドレス（ＶＡ：Ｖｉｒｔｕａｌ Ａｄｄｒｅｓｓ）を中間物理アドレス（ＩＰＡ：Ｉｎｔｅｒｍｅｄｉａｔｅ Ｐｈｙｓｉｃａｌ Ａｄｄｒｅｓｓ）に変換するステージ１、及び、ハイパーバイザ３８によってセットされたステージ２ページ・テーブル１２０－２に基づいて、ステージ１変換によってもたらされた中間物理アドレスをメモリ１６にアクセスするために使用される物理アドレス（ＰＡ）に変換するステージ２アドレス変換といった、アドレス変換の２つのステージをサポートする。ハイパーバイザは、様々な仮想マシンに対して多数のステージ２ページ・テーブルのセットを定義することができ、メモリ・アクセス要求を与えられた仮想マシンＩＤ（ＶＭＩＤ：Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ ＩＤ）２５０は、どの特定のステージ２ページ・テーブルを使用するか識別することができる。同様に、オペレーティング・システムは、様々なアプリケーションのための多数のステージ１ページ・テーブルのセットを定義することができ、アドレス空間識別子（ＡＳＩＤ：ａｄｄｒｅｓｓ ｓｐａｃｅ ｉｄｅｎｔｉｆｉｅｒ）２５２は、どのステージ１ページ・テーブルを使用するか識別するために使用することができる。ＶＭＩＤ２５０及びＡＳＩＤ２５２は、メモリ・アクセス要求と関連付けられた現在の変換コンテキストを識別する変換コンテキスト識別子２５４と総称することができる。メモリ・アクセス要求はまた、トランザクションが読取り要求（Ｒ）か書込み要求（Ｗ）かを示す属性、又は、メモリ・アクセス要求を発行したプロセスと関連付けられた例外レベル（Ｘ）を示す属性、といった様々な属性２５６を指定する。

【0097】

メモリ・アクセスを受け取ると、ＭＭＵ２６は、ステージ１ページ・テーブルからの情報に基づいて、トランザクション属性が有効であるかどうか判定することができる。たとえば、ステージ１ページ・テーブルは、あるアドレスに対して読取りトランザクションのみが許可されることを指定できる、又は、所与のアドレスに対して読み取り及び書き込みの両アクセスを可能とすることができる（いくつかの実装形態では、アドレス空間のうち書込み領域のみ定義することを可能とすることもできる）。また、ステージ１ページ・テーブルの属性は、所与の例外レベル又はそれよりも高いレベルで動作するプロセスへのアクセスを制限することができる。トランザクション属性が有効で、アクセスがステージ１ページ・テーブルによって許可された場合、ＭＭＵは対応する中間物理アドレス（ＩＰＡ）を戻すことができる。次いで、ＩＰＡはＶＭＩＤ２５０と共にステージ２ページ・テーブルにインデックス付けを行い、ステージ２ページ・テーブルは再度トランザクションの属性を確認し、有効であれば物理アドレスを戻す。すべてのトランザクションが、アクセス変換の２つのステージを経る必要があるわけではないことに留意されたい。たとえば、入力メモリ・トランザクションがＥＬ３若しくはＥＬ２、又はセキュアなドメイン内のＥＬ１若しくはＥＬ０において発行された場合、ステージ１ＭＭＵの出力は物理アドレスとして扱われ、ステージ２ＭＭＵはバイパスすることができる。

【0098】

物理アドレスを入手すると、次に、ＲＭＵテーブル１２８（レルム・グラニュール・テーブル）においてその物理アドレスを検索し、ＭＭＵによって実施されたレルム保護によりメモリ・アクセスを進めることができるかどうか判定することができる。レルム・チェックについては以下の図１８でより詳細に説明する。ステージ３におけるＲＭＵチェックが成功した場合、次に有効にされた物理アドレスが出力され、メモリ・アクセスを進めることが許可される。ステージ１若しくはステージ２のアドレス変換における任意のチェック、又はステージ３において行われたＲＭＵによって実施されたレルム保護が失敗した場合、メモリ・アクセスは拒否される。したがって、レルム管理ユニットによって行われる保護は、ページ・テーブル１２０に基づく任意の既存のアドレス変換チェックに加えて、実行されるべきチェックの追加層と考えることができる。図１７Ａで表されたチェックは、比較的実行が遅くなる可能性がある。その理由は、メモリ内に、アクセスし、メモリ・アクセス要求又は現在の変換コンテキスト又はそこからアクセスがなされるレルムのパラメータと比較する必要がある多くのテーブルが存在する可能性があるためである。こうしたチェックをメモリ・アクセスごとに実行することは可能であろうが、所与のメモリ・アクセス要求に対してチェックが首尾よく実行されたとき、ＴＬＢ１００内にデータを速やかにキャッシュすることが可能であり、その結果、次回に類似のメモリ・アクセス要求が発行されたとき、すべてのチェックを再度繰り戻すことなく許可することができる。したがって、ＴＬＢ１００において失敗がありヒットしないときにのみ、こうした許可チェックを実行するのが好ましいであろう。

【0099】

図１７Ｂは、すでに有効にされたメモリ・アクセスに関するデータをキャッシュするためのＴＬＢ構造１００の一実例を表す。図１７Ｂは１つのＴＬＢを表しているが、レベル１のＴＬＢがより高速なアクセスのために変換エントリのより小型のサブセットを記憶し、レベル２又はそれ以上のレベルのＴＬＢが、レベル１のＴＬＢに失敗が発生した場合に、アクセス可能な変換エントリのより大きなセットを記憶するといった状態で、いくつかのシステムでは、キャッシュ階層に複数のレベルのＴＬＢを含むことができることが理解されよう。ＴＬＢ１００（又は「変換キャッシュ」）は、いくつかのエントリ２６０を有し、各エントリは対応するメモリ領域のためのアドレス変換データを指定する。各エントリ２６０は、データが対応する物理アドレス２６４を提供する仮想アドレスに対応した仮想的にアドレスされたタグ２６２を含む。この実例では、ＴＬＢはステージ１及びステージ２のＴＬＢが結合されたものであり、そのため、仮想アドレスは、中間物理アドレスを経由する必要なしにＴＬＢを使用して物理アドレスに直接変換することができる（対応するステージ１及びステージ２の変換は、正しい物理アドレスの位置を突き止めるためにＴＬＢがない（ＴＬＢ ｍｉｓｓ）中で実行されるであろうが、ＴＬＢは介在するＩＰＡを記憶する必要はなく、ＶＡを直接ＯＡにマッピングすることができる）。他の実例では、分離したステージ１（Ｓ１）及びステージ２（Ｓ２）のＴＬＢを使用することが可能であるが、そのケースにおいは、ＶＡ－ＰＡペア２６２、２６４は、ＶＡ－ＩＰＡペア又はＩＰＡ－ＰＡペアで置き換えることができる。ＴＬＢエントリ２６０はまた、変換コンテキスト識別子２５４（ＡＳＩＤ２５２及びＶＭＩＤ２５０から構成されている）でタグ付けされる。この実例では、２つの別々の変換コンテキスト識別子が設けられるが、他の実例では、１つの統合された変換コンテキスト識別子を使用することが可能であり、又は、分離したＳ１／Ｓ２のＴＬＢのケースでは、Ｓ１のＴＬＢはＡＳＩＤを使用し、Ｓ２のＴＬＢはＶＭＩＤを使用することができる。変換コンテキスト識別子により、同一の仮想アドレスを指定して、異なる物理アドレスを提供するＴＬＢ１００の異なるエントリにアクセスをマッピングさせる、異なるオペレーティング・システム又はアプリケーションが可能となる。

【0100】

ＴＬＢ１００におけるヒットには、メモリ・アクセス要求に対して指定されたアドレス２５８の対応する部分をマッチングさせるためのタグ２６２だけでなく、メモリ・アクセスが発行された現在の変換コンテキストがマッチングした場合には、同一のエントリに記憶された変換コンテキスト識別子も必要となる。タグ２６２と変換コンテキスト識別子２５４との比較は、所与のメモリ・アクセスに対する正しい物理アドレス２６４の位置を突き止めるのに十分であると考えられるかもしれない。しかし、この比較が検索で実行される唯一の比較である場合には、ＴＬＢでヒットしたメモリ・アクセスが、レルム管理ユニット・テーブル１２８のさらなるチェックなしに受け取られると、潜在的なセキュリティの脆弱性が存在する。それは、以前に実行されたプロセスと同一のＶＭＩＤ２５０又はＡＳＩＤ２５２を有し、ＭＭＵを欺いて、実際は異なるレルムから所与のメモリ領域にアクセスするために以前に受け取られたレルムへ来た、メモリ・アクセスを受け取らせる新しいプロセスが作成されることが可能なためである。

【0101】

この問題に対処するために、ＴＬＢ１００は、各ＴＬＢエントリ２６０内で、対応するメモリ領域を有する所有者レルムのグローバルＲＩＤ２７０、並びに、他のどのレルムが対応するメモリ領域にアクセスすることを許可されるかを制御するために所有者レルムによってセットされた可視性属性２７２を指定することができる。所与の変換キャッシュ１００の検索が、所与の目標メモリ領域に対する現在の変換コンテキスト及び現在のレルムから発行されたメモリ・アクセスに応答して実行されたときに、変換キャッシュ１００に失敗が発生した場合、ＴＬＢ制御回路２８０は、アクセスが許可されるかどうかチェックするために、テーブル・ウォーク・ユニット１０２をトリガして適切なページ・テーブル１２０及びＲＭＵテーブル１２８にアクセスする。ページ・テーブル又はＲＭＵテーブル１２８のどちらかが、対応するメモリ領域へアクセスすることから、変換コンテキスト、例外レベル及びレルムの現在の組合せを除外すると、そのメモリ・アクセスに応答して変換キャッシュに割り当てられるデータは何もない。特に、検索が失敗し、現在のレルムが目標メモリ領域の所有者レルムによって目標メモリ領域にアクセスすることから除外されると、アドレス変換データを変換キャッシュに割り当てることが妨害される。したがって、対応するメモリ・アクセスがＭＭＵページ・テーブル１２０及びＲＭＵテーブル１２８の両方のチェックを通過するとき、エントリはＴＬＢ１００に割り当てられる。

【0102】

次に、変換キャッシュが所与のアドレスにアドレス変換を提供するエントリ２６０をすでに含んでいるかどうかチェックするために、その変換キャッシュを検索するとき、ＴＬＢ制御回路２８０は、対応するエントリ２６０で指定された変換コンテキスト識別子２５４と、メモリ・アクセス要求と共に受け取られた現在の変換コンテキストのための変換コンテキスト識別子２５４との間の第１の比較、及びまた、そのエントリ２６０によって指定されたグローバルＲＩＤ２７０と、メモリ・アクセス要求を発行した現在のレルムと関連付けられた現在のグローバルＲＩＤとの間の第２の比較に基づいて、メモリ・アクセスが変換キャッシュ１００の所与のエントリとマッチングするかどうかを判定する。ＴＬＢエントリは、メモリ領域にアクセスする許可を得ているものとして以前に確認されたレルムから、依然としてアクセスされるという追加チェックを提供することにより、たとえ悪意ある監督プロセスが、所有者レルムによってデータにアクセスすることが可能な以前に存在したプロセスと同一のＡＳＩＤ２５２又はＶＭＩＤ２５０を有する別のプロセスを生成したとしても、グローバル・レルム識別子２７０は、図１８に関して説明したように、レルム消去（ｓｃｒｕｂｂｉｎｇ）コマンド２１６の処理を受けることなく別のプロセッサに再割り当てすることができないので、これにより、現在のレルムのグローバルＲＩＤは有効であると信頼でき、ＡＳＩＤ又はＶＭＩＤに対して可能であるように「偽物」であろうはずがないと意味することを保証できる。したがって、現在のレルムのグローバルＲＩＤが、依然として所有者ＧＲＩＤ２７０及び可視性属性２７２によって示される許可を満足させる場合、これは以前に実行されたレルム・テーブル・チェックが依然として有効であることを示す。

【0103】

レルム識別子の第２の比較でミスマッチを検出すると、たとえタグ比較及び変換コンテキスト比較がマッチしたとしても、エントリが割り当てられた以降に変換コンテキストＩＤ２５４とレルムＩＤ２７０との間のマッピングに変化が生じたことを示すので、アクセス要求はＴＬＢ内で失敗したと考えられる。これはアクセスが拒否されるであろうということを必ずしも意味しない。というのは、ページ・テーブル及びＲＭＵテーブルの別のウォークは、テーブル・ウォーク・ユニット１０２によってトリガされる可能性があり、レルム・チェックが成功すると、異なるエントリ２６０をＴＬＢ１００に割り当て、新たに割り当てられたエントリからの情報に基づいてメモリ・アクセスをサービスする可能性があるからである。

【0104】

図１８は、所与のメモリ・アクセスがＭＭＵ２６によって許可されるかどうかを判定する方法を示す流れ図である。ステップ３００において、メモリ・アクセス要求が受け取られ、これはＴＬＢ１００内で検索される。メモリ・アクセス要求は、少なくともアクセスされる仮想アドレス、現在の変換コンテキストを示す１つ又は複数の変換コンテキスト識別子、及び現在のレルムを識別するグローバル・レルム識別子を指定する。たとえば、グローバルＲＩＤは、レルムへのエントリ時に現在のレルムのグローバルＲＩＤで書き込み可能な処理要素８の状態レジスタから読むことができる。

【0105】

メモリ・アクセス要求に応答して、ＴＬＢ制御回路２８０はＴＬＢの検索を実行する。検索は少なくともＴＬＢのいくつかのエントリにアクセスする。いくつかの手法では、完全に連携されたキャッシュ構造を使用することが可能であり、このケースにおいては、少なくともレベル１のＴＬＢのすべてのエントリは検索され、ヒットしたか失敗したかを識別するために現在の要求のパラメータと比較することができる。他の手法では、１組の連携された（ｓｅｔ－ａｓｓｏｃｉａｔｉｖｅ）キャッシュ割り当てポリシーを使用することができ、このケースにおいては、ＴＬＢの所与のレベルのエントリのサブセットのみを検索し、メモリ・アクセスの目標アドレスを使用してインデックス付けする必要があるだけである。アクセスされたエントリのセットのそれぞれに対して、ＴＬＢ制御回路２８０はいくつかの比較（並行又は逐次のどちらか）を実行する。この比較には以下が含まれる。
・メモリ・アクセス要求のアドレスが、アクセスされたエントリに記憶されたタグ２６２とマッチングするかどうかを比較するためのタグ比較３０２。
・アクセスされたエントリに記憶された変換コンテキスト識別子をメモリ・アクセス要求の変換コンテキスト識別子と比較するための第１の（コンテキスト）比較３０４。
・メモリ・アクセス要求のグローバルＲＩＤをアクセスされたエントリ・セットのそれぞれに対する所有者ＲＩＤ２７０及び可視性属性２７２と比較するための第２の（レルム）比較３０６。
ステップ３０８において、制御回路２８０は、比較３０２、３０４、３０６のすべてに対してマッチを戻したＴＬＢ内にエントリが存在するかどうかを判定し、存在する場合はヒットが識別され、ステップ３１０において、マッチング・エントリ内で指定された物理アドレス２６４が戻され、その物理アドレスに基づいてメモリ・アクセスが続行することを許可される。ヒットしたケースでは、ページ・テーブル又はＲＭＵテーブルの何等の検索を実行する必要はない（メモリ・アクセスに対する所有権テーブル検索は省略可能である）。ページ・テーブル及びＲＭＵテーブルによって提供される保護は失敗時にのみ呼び出される。

【0106】

３つの比較３０２、３０４、３０６のすべてとマッチするエントリがない場合、失敗が検出される。さらなるＴＬＢレベルが提供されると、ステップ３００～３０８への対応する検索は、レベル２又は後続のレベルＴＬＢで実行することができる。検索が最後のレベルＴＬＢで失敗すると、様々なページ・テーブル及びＲＭＵテーブルのウォークが実行される。したがって、ステップ３１１では、ステージ１のページ・テーブル・ウォークが実行され、ステップ３１２では、ステージ１のページ・テーブル障害が発生した（たとえば、指定された仮想アドレスに対して定義されたアドレス・マッピングが存在しないため、又は、アクセス要求の現在のパラメータが、目標の仮想アドレスに対して指定されたアクセス許可を破ったため）かどうか判定される。ステージ１の障害が発生すると、ステップ３１４では、メモリ・アクセスが拒否され、メモリ・アクセスに応答するＴＬＢ１００に対するアドレス・マッピング・データの割り当てが阻止される。

【0107】

他方、アクセス要求がステージ１のページ・テーブル・チェックを通過すると、ステップ３１５でステージ２のページ・テーブル・ウォークがトリガされ、ステージ１のプロセスで戻された中間物理アドレス用のマッピング・データが入手され、ステップ３１６でステージ２のページ・テーブル障害が発生した（この場合も、アドレス・マッピングが定義されなかったため、又は、アクセスがステージ２のアクセス許可によって許可されなかったため）かどうか判定される。ステージ２の障害が発生すると、再度ステップ３１４でアクセス要求が拒否される。

【0108】

ステージ２の障害が発生しないと、ステップ３１８で、ＲＭＵテーブル検索がステージ２によって戻された物理アドレスに基づいてトリガされ、ステップ３２０で、レルム障害が検出されたかどうか判定される。以下のイベントのいずれかが発生した場合、レルム障害がトリガされることがある。
・対応するメモリ領域に対するライフサイクル状態が、レルム所有権テーブル１２８内で無効であると示された場合。これは、図１５に示すクリーニング動作２２４を経ていないメモリ・アドレス空間のページが、異なるレルムによるアクセスからそのメモリ領域内の別のレルムによって以前に記憶された任意のデータを保護するために、アクセスすることができないことを保証する。
・現在のレルムは、所有者レルムによってそのメモリ領域にアクセスするための対応するメモリ領域として許可されない。所与のレルムが所与のメモリ領域にアクセスすることを許可されないいくつかの理由があろう。所有者レルムが、メモリ領域は所有者自身及びその子孫のみが見ることができると指定した場合、別のレルムはそのレルムにアクセスする許可は得られないであろう。また、現在のレルムが所有者レルムの親レルムであり、所有者レルムは、親レルムにその領域にアクセスすることを許す親可視性属性を定義していない場合、メモリ・アクセスは拒否されるであろう。また、所有者レルムそれ自体は、メモリ領域が上で説明したように目下のところＲＭＵプライベートとしてセットされている場合、メモリ領域にアクセスすることはできないであろう。ＲＭＵチェッキング・ステージにおいて、所有者レルムの子孫レルムはメモリ領域にアクセスすることを許可されよう（メモリ領域がＲＭＵプライベート領域でない限り）。したがって、このチェックにより所有者レルムによってセットされるアクセス許可が強化される。
・仮想アドレス、又は、そこからＳ１／Ｓ２変換により現在のメモリ・アクセスのための物理アドレスがマッピングされる中間物理アドレスが、図１２で表したように、対応するメモリ領域のための所有権テーブル１２８で指定されたマッピングされたアドレスとマッチしない場合、メモリ・アクセスは拒否される。これにより、悪意ある親レルムが所与のメモリ領域の所有者を子レルムに割り当てる状況を防ぐが、ページ・テーブル１２０における変換マッピングを変化させ、その結果、その子レルムによって所有されたページを指すために以前使用された同一の仮想アドレスを使用して、子レルムによってトリガされた後続のメモリ・アクセスが、今度は子レルムそれ自体によって実際に所有されていない異なる物理アドレスにマッピングすることになる。対応するメモリ領域の物理アドレスから、所有権が主張されたときにその物理アドレスを生成するために使用されたマッピング・アドレスへ戻って、所有権テーブルにリバース・マッピングを提供することにより、検出対象であるアドレス・マッピングの変更によりセキュリティ侵害が発生する可能性があり、その結果メモリ・アクセスが失敗することになる。
他のタイプのチェックも実行できることは理解できよう。レルム・チェックが成功した場合、ステップ３２２で物理アドレスが戻され、メモリ・アクセスが物理アドレスを使用して続行可能となり、ページ・テーブル１２０及び所有者レルムから入手された物理アドレス、並びに、要求された仮想アドレス及び変換コンテキストに対応する所有権テーブル１２８から入手された可視性属性を示す、新しいエントリがＴＬＢに割り当てられる。

【0109】

レルムとの間のエントリと退出に関して、処理要素８及び／又はＲＭＵ２０は、レルム・エントリ又は退出の安全な取り扱いを保証するために、いくつかの動作を実行する必要がある。たとえば、レルム・エントリに際して、目標レルムが正しいライフサイクル状態にあることをチェックするために（たとえば、セキュリティ手段が、存在しないレルム又は所有されたページからのデータ消去を経ていないレルム入力を試みることによって回避されることを防止するために）、いくつかのチェックを実行する必要がある。また、レルムから出るに際して、より高い特権を有するレベルのプロセスが、より低い特権のレベルでレルムによって使用される状態データにアクセスできないように（本来であれば、レルム保護によって提供されるセキュリティ手段が回避されることが可能となる）、処理要素のレジスタに記憶されたアーキテクチャの状態をマスク化するのが望ましいであろう。レルム・エントリ及び退出を取り扱うための１つの手法は、ＲＭＵ２０をトリガしてレルムの入力又は退出のための適切な動作を実行させる専用のレルム・エントリ又は退出命令を提供することであろう。

【0110】

別の手法は、レルムに入力し退出するために、例外エントリ及び戻しのためにすでに提供された仕組みを再利用することであり得る。これにより、レルム・エントリ及び退出をサポートするのに必要なソフトウェアを変更する量が削減され、アーキテクチャ及びハードウェアが単純になる。これは特に有用である。というのは、レルム境界はともかくも例外レベルの境界と一致することが多く、たとえ、新しい命令がエントリ及び退出を制御するために提供されたとしても例外を取り扱うための振る舞いはなお必要であろうし、そのため、例外機構を拡張してエントリ及び退出をさらに制御しても、全体的に費用は安くなるであろう。

【0111】

したがって、現在のレルムで処理された例外から現在のレルム（ここでは、他のプロセスも同一の例外レベル、又はそれよりも低い特権を有する例外レベルで取り扱うことができる）で同様に処理された別のプロセスへ処理を通常戻す、例外リターン（ＥＲＥＴ）命令は、現在のレルムから宛先レルムへレルム・エントリをトリガするために再使用することができる。例外リターン命令の第１の変形体に応答して、処理回路は、現在の例外レベルからより低い特権を有する例外レベルへ（レルムを変更することなく）処理を切り替えることができ、一方、例外リターン命令の第２の変形体に応答して、処理回路は、現在のレルムから、現在のレルムと同じ例外レベル又はそれよりも低い（より低い特権を有する）例外レベルで動作することができる宛先レルムへ処理を切り替えることができる。例外リターン命令を使用してレルム・エントリをトリガすることにより、アーキテクチャ及びハードウェアのオーバーヘッドを大いに単純化し、レルムの使用をサポートするためのソフトウェア変更要求を削減することができる。

【0112】

例外リターン命令を使用する別の利点は、典型的には例外から戻る際に、処理回路が例外リターン命令に応答して微細な１組の動作を実行することができることである。例外から戻る際に必要となる１組の動作は、これらの動作中ずっと途中で分割できないように微細に実行することが可能であり、そのため、命令が失敗し微細な１組の動作のどれもが実行されないか、命令が首尾よく実行され微細な１組の動作のすべてが実行されるかのどちらかである。例外リターン命令の第２の変形体に対して、処理回路は、第１の微細な１組の動作とは異なる第２の微細な１組の動作を同様に実行することができる。例外リターン命令が微細に完了するのを保証するために、プロセッサにすでに提供された機構は、レルム・エントリが部分的に実行されるだけの、セキュリティの脆弱性につながり得る状況を避けるために、レルム・エントリに再使用することができる。たとえば、第２の微細な動作の組は、レルム実行コンテキスト状態を利用可能とし、実行されている現在のレルムを変更し、前回同一のレルムが実行されたとき、処理が以前に実行されたプログラム・カウンタ・アドレスへの分岐を制御することを含むことができる。

【0113】

例外リターン命令の第１及び第２の変形体は、同一の命令符号化を有してもよい。したがって、例外リターン命令それ自体の変更は、レルム・エントリをトリガするためには必要ではない。これにより、レガシー・コードとの互換性が向上する。所与の例外リターン命令が、第１の変形体又は第２の変形体に従って実行されるかどうかは、その命令が状態レジスタに記憶した制御値によって決まる（たとえば、制御値の第１及び第２の値は、それぞれ例外リターン命令の第１及び第２の変形体を表すことができる）。したがって、例外リターン命令が実行されるとき、現在のアーキテクチャの状態が、プロセッサを同じレルム内のより低い特権レベルに戻すか、それとも新しいレルムへエントリをトリガするか制御する。

【0114】

この手法により、特に、状態レジスタの値が、レルム・スイッチは適当であることを示す一定のイベントに応答して、（ソフトウェア命令に応答して制御値を任意に設定できることに加えて）ハードウェアによって自動的にセットすることができるので、レルム・エントリをより少ないソフトウェア変更で制御できるようになる。たとえば、所与のレルムへの退出をトリガする例外状態が発生したとき、処理回路は制御値を所与のレルム用の第２の値にセットし、それにより、たとえ、例外を取り扱うための例外ハンドラ・コードがレルムを念頭に置いて書かれたものではない以前のレガシー・コードと全く同一だとしても、後続の例外リターン命令は自動的に処理を例外が発生したレルムに戻す。或いは、いくつかのアーキテクチャでは、レルムから退出するとき、状態レジスタの制御値は依然として、そのレルムにレルム・エントリをトリガする前にセットされた第２の値を含み、そのため、制御値を状態レジスタに明確にセットすることは必要ないということが期待できるであろう。

【0115】

少なくとも１つのレルム識別子レジスタが設けられ、例外リターン命令の第２の変形体に応答して、処理回路は、レルム識別子レジスタに記憶されたレルム識別子から宛先レルムを識別することができる。それぞれが例外レベルの１つと関連付けられた多くのレルム識別子レジスタが存在できるように、レルム識別子レジスタは横一列に並べることができ、例外リターン命令の第２の変形体に応答して、処理回路は、現在の例外レベルと関連付けられたレルム識別子レジスタに記憶されたレルム識別子から宛先レルムを識別することができる。レルム識別子レジスタを使用して目標レルム識別子を記憶することにより、これをＥＲＥＴ命令の命令符号化に含む必要はなく、これにより、既存のＥＲＥＴ命令のフォーマットを、レルム・エントリをトリガするために使用することができ、その結果、必要なソフトウェア変更の量が削減される。レルム識別子レジスタのレルム識別子は、親レルムによってその子レルムを参照するために使用されるローカル・レルム識別子とすることができ、そのため、レルム・エントリは親レルムから子レルムへの通過に限定することができ、第１のレルムから、第１のレルムの直接の子ではない別のレルムへ行くことは可能ではない。例外リターン命令の第２の変形体に応答して、処理回路は、ＲＩＤレジスタで識別されたレルムＩＤと関連付けられたレルムが無効なレルム（それに対してレルム記述子が定義されていない、又はレルム記述子がアクティブ以外のライフサイクル状態を定義しているＲＩＤ）であるとき、障害状態をトリガすることができる。

【0116】

例外リターン命令の第２の変形体に応答して、処理回路は、例外リターン命令のために指定されたレルム実行コンテキスト（ＲＥＣ：Ｒｅａｌｍ Ｅｘｅｃｕｔｉｏｎ Ｃｏｎｔｅｘｔ）メモリ領域から、宛先レルムで処理されるスレッドと関連付けられたアーキテクチャの状態を記憶することができる。状態復元は、例外リターン命令の第２の変形体に応答して、直ちに実行することができ（たとえば、微細な１組の動作の一部として）、又は、後に実行することもできる。たとえば、状態復元はゆっくりとした方法で実行することができ、その結果、宛先レルムで処理を開始するために必要な状態は直ちに復元することができるが（たとえば、プログラム・カウンタ、処理モード情報など）、汎用レジスタなど他の状態は、後に必要なとき、又は新しいレルムの進行中の処理のバックグラウンドで徐々に復元することができる。したがって、処理回路は、すべての必要なアーキテクチャの状態がＲＥＣメモリ領域から復元される前に、宛先レルムの処理を開始することができる。

【0117】

例外リターン命令の第１の変形体に応答して、処理回路は、リンク・レジスタに記憶されたプログラム命令アドレスへ分岐することができる。対照的に、例外リターン命令の第２の変形体に対して、処理回路は、レルム実行コンテキスト（ＲＥＣ）メモリ領域で指定されるプログラム命令アドレスへ分岐することができる。リンク・レジスタは、例外リターン命令の第２の変形体が、新しいレルムに対して任意のアーキテクチャの状態を直接識別するためには使用されないので、リンク・レジスタは、代わりにポインタを、そこから新しいレルムのアーキテクチャの状態が復元されるＲＥＣメモリ領域へ提供するために再使用することができる。これにより、ＲＥＣポインタを復元するためにさらなるレジスタを提供する必要が避けられる。

【0118】

したがって、所与のレルムにレルム・エントリを引き起こさせることを意図した例外リターン命令を実行する前に、ＲＩＤレジスタを宛先レルムのレルム識別子にセットし、宛先レルムと関連付けられたＲＥＣメモリ領域のポインタを記憶するためのリンク・レジスタをセットするために、いくつかの追加の命令を含むことができる。ＲＥＣポインタは、宛先レルムのレルム記述子から親レルムによって入手可能である。

【0119】

例外リターン命令の第２の変形体に応答して、ＲＥＣメモリ領域が宛先レルム以外の所有者レルムと関連付けられるか、例外リターン命令に対して指定されたＲＥＣメモリ領域が無効なとき、障害状態を処理回路によってトリガすることができる。第１のチェックは、親レルムが子レルムを欺いて子レルム自体が作成したものではないプロセッサ状態を実行させることを防止する。というのは、子レルムによって所有されたメモリ領域のみが、そのレルムを入力する際にアクセス可能なＲＥＣメモリ領域を記憶することができるからである（上で説明したように、ＲＥＣメモリ領域はＲＭＵプライベートとしてセットされる）。ＲＥＣメモリ領域の有効性の第２のチェックは、ＲＥＣメモリ領域はレルムを入力するために一度だけ使用することができ、その後、同一のＲＥＣデータでレルムを入力しようとする後続の試みは拒否されるであろうということを保証するのに有用であろう。たとえば、各ＲＥＣは、無効か有効であるライフサイクル状態を有しているであろう。現在のレルムで所与のスレッドの処理中に発生する例外に応答して、そのスレッドのアーキテクチャの状態は対応するＲＥＣメモリ領域に保存され、その対応するＲＥＣメモリ領域は、次いで無効から有効へ移行することができる。例外リターン命令の第２の変形体を首尾よく実行したことに応答して、ＲＥＣメモリ領域は次いで有効から無効へ逆に移行することができる。これにより、親レルムが悪意を持って子レルムに、期限切れのＲＥＣメモリ領域のポインタ、異なるスレッドと関連付けられたＲＥＣメモリ領域、又は宛先レルムと関連付けられてはいるが、レルムからの前回の退出時にアーキテクチャの状態を記憶するために使用された正しいものではないいくつかの他のＲＥＣを指定することにより、不正に振る舞わせることが避けられる。

【0120】

対応する方法において、レルムからの退出は、例外取扱いのために提供された機構を再使用することができる。したがって、第１のレルムによって取り扱うことができない第１のレルムの処理中に発生した例外状態に応答して、処理回路は、第１のレルムを初期化した親レルムへレルム退出をトリガすることができる。例外発生／レルム退出に際して、同一のレルム内で取り扱いが可能な例外発生に対しては実行できないいくつかの追加的な動作を実行することができる。たとえば、これにはアーキテクチャの状態のマスク化又は消去、及び、ＲＥＣに対して状態ストレージをトリガすることが含まれる。

【0121】

しかし、いくつかのケースにおいて、例外が発生する第１のレルムの親レルムによって取り扱うことができない例外が発生する場合がある。したがって、この場合には、親を超えてさらなる先祖レルムへ切り替えることが必要となろう。所与のレルムから２世代以上古い先祖レルムへ直接切り替える機能を提供することは可能かもしれないが、これにより、例外エントリ及び戻し又はレルム退出及びエントリを取り扱うために必要な状態レジスタの複雑性が増大するであろう。

【0122】

むしろ、第１のレルムの親レルムが処理できる最も高い特権を有する例外レベルというよりは、より高い特権レベルを有する目標例外レベルで例外状態が処理されるとき、ネストされたレルム退出を実行することができる。ネストされたレルム退出には、発生した例外の目標例外レベルで処理することができる第２のレルムに到達するまで、子レルムから親レルムへの２つ以上の連続したレルム退出が含まれる。したがって、一度に一段階ずつレルム階層を上げることにより、アーキテクチャを単純化することができる。それぞれの連続するレルム退出において、プロセッサ状態のサブセットを対応するレルムと関連付けられたＲＥＣに保存するように実行する動作が存在する場合がある。

【0123】

図１９は、親レルムによって初期化することができるサブレルムの概念を示す。図１９に示すように、特定の例外レベルで動作する所与の親レルム６００は、その親と同一の例外レベルで動作するサブレルム６０２を初期化することができる。完全レルム６００は、所与のソフトウェア・プロセス（又は２つ以上のプロセスの集合）に対応するが、サブレルムは、所与のソフトウェア・プロセス内の所定のアドレス範囲に対応する。完全レルムはサブレルムの親であるので、上で説明したように、サブレルムは、親完全レルムによって所有されたメモリ領域に記憶されたデータにアクセスする権利を有することができるが、サブレルムは、サブレルム６０２によって所有されたメモリ領域に記憶されたアクセス・データからその親完全レルムを除外する権利を有することができる。これは、所与のソフトウェア・プロセスのある部分をそのソフトウェア・プロセスの他の部分よりもより安全にするのを可能にするのに有用である。たとえば、モバイル・バンキング・アプリケーションのパスワードをチェックするため、又は、他の機密情報にまつわる情報を処理するためのコードの一部は、同一のアプリケーション又はオペレーティング・システムの他の部分が、その機密情報にまつわる情報にアクセスできないように、サブレルムに割り当てることができる。

【0124】

サブレルムは一般に、以下に説明するようにいくつかの相違はあるものの、完全レルムと同じ方法で取り扱うことができる。サブレルムとの間でのエントリ及び退出は、例外リターン命令及び例外イベントを使用して、上で説明したのと同じ方法で取り扱うことができる。したがって、サブレルムは、同じ親の完全子レルム用と同じ方法で構成された子レルムＩＤを有することができ、上で説明したようなレルム記述子ツリー内のレルム記述子を備えることができる。サブレルムへのエントリは、ＥＲＥＴ命令を実行する前に、ＲＩＤレジスタに適切な子サブレルムＲＩＤを配置したＥＲＥＴ命令を単純に実行することによりトリガすることができる。したがって、同じタイプの（第２の変形体の）ＥＲＥＴ命令を使用して、完全レルム又はサブレルムのどちらにでもエントリをトリガすることができる。

【0125】

サブレルムが完全レルムと異なる１つの点は、サブレルムは自身の子レルムを初期化することが許されていないということであろう。したがって、新しいレルムを初期化するためのレルム初期化コマンドは、現在のレルムがサブレルムの場合、拒絶されるであろう。ＲＭＵは、現在のレルムのレルム記述子内のレルム・タイプ値を使用して、現在のレルムは完全レルムかサブレルムかを判定することができる。現在サブレルムにいるとき、レルム初期化をできないようにすることにより、さらなるレルムを初期化する際にサブレルムによって使用するための追加の状態レジスタを備える必要がないため、アーキテクチャが単純化される。

【0126】

同様に、現在サブレルムにいるとき、レルム・エントリ命令の実行はできないであろう。レルム・エントリ及び退出（及び例外エントリ及び戻し）を処理するための異なる例外状態について重複される横一列に並べられたレジスタは、いくつのサブレルムを所与のプロセスが作成することになるかは設計時には知られていないことがあるので管理するのが難しくなる、各サブレルムについてさらなる回数横一列に並べられることを必要としないことを意味するので、これは、アーキテクチャを簡単にする。同様に、より低い特権レベルで動作するプロセスへのスイッチをトリガする例外戻しイベントは、現在のレルムが完全レルムではなくサブレルムのとき使用できなくなる。上で説明した実例において、単一タイプのＥＲＥＴ命令は、レルム・エントリ命令としても例外リターン命令としても機能するが、これはすべての実施例にとって重要ではなく、個々の命令が提供されたとき、レルム・エントリ命令も例外リターン命令も、現在のレルムがサブレルムの場合、使用できなくなる。

【0127】

同様に、サブレルムにあるとき例外が発生した場合、例外を直接サブレルムから除去するよりは、処理回路は、例外を取り扱う前に、サブレルムからサブレルムを初期化した親完全レルムへ退出をトリガすることができる。したがって、例外は親完全レルムへの戻しをトリガする。親完全レルムへの例外戻しは、ＲＥＣへ対する状態マスク化、消去及び保存動作を含むことができるが、例外がより高い例外レベルでサブレルムからレルムへ直接除去されるのを防ぐことにより、例外制御レジスタをサブレルムのためにさらに一列に並べる必要が避けられ、アーキテクチャが簡略化される。

【0128】

サブレルムの場合、レルムを処理することができる最大特権レベルを示す境界例外レベルは、その親完全レルムに対する境界例外レベルに等しい。対照的に、子完全レルムの場合、境界例外レベルは、その親レルムの境界例外レベルよりもより低い特権を有する例外レベルである。

【0129】

レルムが親レルムによって初期化されると、親レルムは、新しいレルムが子完全レルムになるか子サブレルムになるか選択することができ、それに応じて、適切なレルム・タイプのパラメータをレルム記述子にセットすることができる。いったん、レルムが動作すると、図１１に関して上で説明した管理されたレルム・ライフサイクルによりレルム記述子の変更が禁止されるため、親レルムはもはやレルム・タイプを変更することができない。

【0130】

要約すれば、完全レルムと似ているが、例外取扱い、レルム初期化及びレルム・エントリ機能がサブレルム内で使用不能となる状態で管理されるサブレルムを導入する機能により、完全レルムのソフトウェア・プロセス内で所与のアドレス範囲に対応するコードのより小さな部分が、そのソフトウェアの他の部分から分離され、機密情報にまつわるコード又はデータのある部分に対して追加的なセキュリティを提供することができるようになる。

【0131】

パラメータ署名
前述のアクセス制御モデルは、同じ特権レベルにある他のソフトウェア、より高い特権レベルにある他のソフトウェア、及び他のレルムを含む、システムの任意の他のエージェントからレルムを保護する。レルムを作成するとき、それは、レルムの最初の内容を表す内容（メモリ・ページ）を投入される。最初の内容が、測定される。レルムはまた、セキュリティ構成、たとえば、レルムがデバッグ・モードで開始されるか否か、独自の内部ブート・プロセスを保護するために及びそれのデータをプライベートにしておくためにレルムによって通常は使用されるレルム秘密の導出のための範囲パラメータなど、を割り当てられる。レルムの作成、それの測定、及びそれのセキュリティ構成の行使（レルム秘密の導出を含む）のプロセスは、レルム管理ユニットによって管理される。

【0132】

レルムが、作動及び実行していると、いくつかの外部ユーザ（たとえば、レルム内部で実行しているサーバ・アプリケーションに接続するクライアント）は、レルムに接続し、証明書報告を要求し得る。証明書報告は、レルムは信頼できるシステムで実行しており、期待されるソフトウェア（レルム測定）を最初に投入されたことと、レルムは期待どおりに構成された（たとえば、デバッグが有効にされて開始されなかった）こととを外部ユーザが確認することを可能にする。これは、データが、単にプロビジョニング済みである、又は証明の成功の後に利用可能にされる、適用例について有用になり得る。

【0133】

しかしながら、レルムが作動及び実行している後の証明書の提供は、以下の例示的使用事例については十分ではないことがある。
・ それが、レルム、又はシステムの再開の後に利用可能なままであるように、データが、システムに永続的に記憶される必要がある場合、
・ データが、負荷バランシング、冗長性などのために「同じ」レルムの複数のインスタンスに利用可能にされる必要がある場合、
・ レルムが、それが証明される前に、いくつかのブート秘密へのアクセスを必要とする場合、たとえば、「同じ」レルム、又はシステムの再開の後を含む、保護されたファイル・システムに記憶されたブート画像へのアクセス。
ここで、「同じ」レルムは、同じ最初の内容を投入された、及び同じセキュリティ構成を使用する、１つ又は複数のレルム・インスタンスを意味する。

【0134】

これらの問題点は、署名されたレルム・パラメータの概念を導入することによって、対処され得る。レルムのセキュリティ構成は、期待される測定を含むように拡張される。レルムのセキュリティ構成は、パラメータ署名者によって、署名される。パラメータ署名者ＩＤが、署名と共に含まれる。たとえば、非対称暗号を使用して、パラメータは、パラメータ署名者によって所有されるプライベート鍵を使用して、署名され得、対応する公開鍵のハッシュは、パラメータ署名者ＩＤとして使用され得る。

【0135】

署名されたパラメータが、使用される場合、実際のセキュリティ構成の署名は、レルムがアクティブ化され得る前に、期待される署名とマッチしなければならないように、レルムの作成のルールは拡張され、署名者ＩＤが、レルム秘密を導出するための鍵導出に含まれる。これらのルールは、レルム管理ユニット２０によって行使され、ソフトウェアによって回避することはできない。

【0136】

これは、以下の場合に、レルムが、単に、アクティブ化され、それの秘密にアクセスし得ることを意味する。（ｉ）それのセキュリティ構成が、正しく署名されてある場合と、（ｉｉ）署名者が正しいエンティティである場合。これらの２つの条件のうちのいずれかが、満たされない場合、次いで、レルムは開始しないことになる、或いは、レルムは開始するが、それの秘密にアクセスすることはできない。

【0137】

たとえば、図２０は、所与のレルムのアクティブ化と同時に、レルムのセキュリティ構成パラメータが、レルムが所与のハードウェア・プラットフォームでインストールされたことを要求するパーティによって期待されるように、設定されてあるかどうかを確認するためにそのようなパラメータ署名を使用する一実例を示す。

【0138】

図２０の最上部に示すように、レルムが作成されるとき、レルムの使用を要求するパーティは、目標レルムを開始することと、ある特定のセットのレルム・セキュリティ構成パラメータ４００を有する目標レルムを確立することとを親レルムに要求する。たとえば、最初のレルム・パラメータは、いくつかの外部パーティ、たとえば、バンキング・プロバイダ、医療提供者、又は、そのプロバイダとのインタラクションのために安全なレルムをハードウェア部分がインストールすることを望む他のパーティ、によって、親レルムに送られるコマンドにおいて指定され得る。最初のセットのレルム・セキュリティ構成パラメータ４００は、レルム・パラメータ更新コマンドを使用し、親レルムによって目標レルムのレルム記述子に追加されることになることが期待され得る。

【0139】

たとえば、最初のレルム・パラメータは、前述のレルム記述子の内容、たとえば、レルム・タイプ４０２、並びに他のセキュリティ構成パラメータ、たとえば、第１のメモリ１６（レルム所有権保護を受ける）から第２の外部メモリ６へのデータのエクスポートが有効にされるかどうかの指示４０６、又はデバッギングがそのレルムについて有効にされるかどうかの指示４０８、のうちのいくつかを含み得る。他のレルム・セキュリティ構成パラメータ、たとえば、保護されたアドレス範囲、及びルート鍵を導出するための鍵材料は、親レルムに与えられた最初のセットのパラメータに含まれなくてもよく、その代わりに、レルムの作成と同時にＲＭＵによって生成され得る、後述するように信頼される仲介レルムによってレルムに提供され得る、又はレルム自体によって生成され得る。

【0140】

最初のレルム・パラメータ４００はまた、レルムについて確立されることが期待されるセキュリティ構成パラメータのサブセットの署名に対応する期待される署名４１０を含む。期待される署名４１０は、期待されるセキュリティ構成パラメータに基づいてパラメータ署名者（たとえば、レルムのインストールを要求するパーティ）によって計算され、作成されているレルムのセキュリティ構成パラメータと共に親レルムに与えられる。最初のレルム・パラメータはまた、パラメータ署名者を識別する署名者ＩＤ４１２の指示を含む。期待される署名４１０及び署名されたＩＤ４１２は、目標レルムがクリーン状態にある間に、目標レルムを構成するときに親レルムによって目標レルムのレルム記述子において記録され得る。

【0141】

たとえば、期待される署名４１０は、期待されるレルム・パラメータのハッシュ関数に基づいてハッシュ値を生成することと、パラメータ署名者と関連付けられたプライベート鍵を使用するハッシュ関数を暗号化することとによって、パラメータ署名者によって生成され得る。署名者ＩＤ４１２は、非対称暗号方式で署名４１０を生成するために使用されるプライベート鍵に対応するパラメータ署名者の公開鍵でもよい。

【0142】

期待される署名４１０は、１サブセットの期待されるレルム・セキュリティ構成パラメータ自体について計算され得るだけではなく、レルムがアクティブ化される時点において目標レルムによって所有されるメモリ領域に記憶されることが期待される期待レルム内容（データ及びコード）の関数として計算され得る測定値にも基づき得る。

【0143】

期待される署名４１０は、レルムのすべてのセキュリティ構成パラメータを包含しなくてもよい。所与のレルムのレルム記述子において設定されることになるいくつかのセキュリティ構成パラメータは、期待される署名４１０の計算から排除され得る。これらは、期待される署名自体４１０及び署名者ＩＤ４１２を含み得る。また、レルム記述子内のレルムのパラメータのうちのいくつかは、レルムが作成されることを必要とする外部パーティによって期待されるセキュリティ構成設定ではなくて、特定の物理プラットフォームのローカル特徴に依存し得る。たとえば、保護されたアドレス範囲のために定義された特定のアドレスは、所与の物理インスタンスでのレルムのために確立された特定のアドレス・マッピングに依存し得る、或いは、いくつかのハードウェア・インスタンス固有の鍵が、特定の物理インスタンスのＲＭＵ２０によって生成され得、したがって、パラメータ署名者によって予測可能にならないことがあり、したがって、パラメータ署名の影響を受けないことがある。

【0144】

処理回路による処理のために利用可能にするために目標レルムをアクティブにするときに、ＲＭＵ２０は、レルム作成においてパラメータ署名者によって提供される期待される署名４１０に基づいて目標レルムのレルム記述子に表された実際のレルム・パラメータ４２０を確認する。この時点で、ＲＭＵは、（ｉ）レルムの実際のセキュリティ構成パラメータ４２０のサブセット（再び、前述のようなある種のパラメータを除外する）、及び（ｉｉ）目標レルムによって所有されるメモリ領域の実際のレルム内容の測定値４２１の関数としてパラメータ署名４２２を決定する。たとえば、ある特定のハッシュ関数４２４が、パラメータ署名４２２を生成するために、レルム・セキュリティ構成パラメータ４２０及び測定値４２１に適用され得る。ハッシュ関数４２４は、期待されるレルム・パラメータ及び期待されるレルム内容に基づいて、期待される署名４１０を生成するために、パラメータ署名者によって使用された、ハッシュ関数に対応し得る。

【0145】

ＲＭＵ２０はまた、目標レルムのレルム記述子から期待される署名４１０及び署名者ＩＤ４１２を取得し、期待される署名４１０及びパラメータ署名４２４はマッチするかどうかを確認する。たとえば、期待される署名４１０が、プライベート鍵を使用して期待されるパラメータを暗号化することによってパラメータ署名者によって計算された場合、次いで、ＲＭＵ１０は、署名者ＩＤ４１２によって表されるような署名者の公開鍵を使用して期待される署名４１０を復号し、次いで、復号された署名を実際のレルム・パラメータから生成されたパラメータ署名４２２と比較することができる。別法として、他の暗号技法が、実際のパラメータ４２０から導出されたパラメータ署名４２２が期待される署名とマッチするかどうかを確認するために可能である。

【0146】

一般に、マッチが、セキュリティ構成パラメータ４２０から導出された実際のパラメータ署名４２２とレルムの作成時に提供された期待される署名４１０との間で検出された場合、次いで、目標レルムのアクティブ化は、進めることを可能にされる（任意の他のセキュリティ・チェックが満たされていると想定して）。他方で、ミスマッチが、パラメータ署名４２２と期待される署名４１０との間で検出された場合、次いで、アクティブ化は、レルムがアクティブ化されることを全く可能にされないように、障害を生成することによって、或いはレルムのアクティブ化を可能にするが、レルムが正しく機能することを阻み得るレルム内容を保護するための秘密鍵へのアクセスを拒否することによって、制約され得る。いずれにしても、署名照合を使用することによって、ＲＭＵは、レルムのインストールを要求するパーティによってそれに与えられるものからレルム・パラメータを悪意を持って変更する親レルムを規制するために、期待したパラメータ・サインが、レルムによってインストールされるべきである、期待されるパラメータとレルム・アクティブ化時の実際のパラメータがマッチすることを行使し得る。

【0147】

署名者ＩＤ４１２はまた、目標レルムのレルム秘密を導出するための鍵材料に含まれる。これは、所与のレルムが確立され、それのレルム・パラメータが、不正な署名者によって提供される署名に基づいて真正として確認された場合、次いで、そのレルムは、アクティブ化され得るが、それは、正しい署名者と関連付けられた鍵によって保護されたデータにアクセスするための正しい鍵を有さないことになることを意味する。

【0148】

暗号署名は、通常は、いくつかの情報を提供するパーティのＩＤがいくつかの知られているＩＤとマッチすることを確認するために使用されることになるので、パラメータ署名を使用するこの手法は、比較的まれである。しかしながら、図２０に示すシナリオにおいて、レルム作成を要求するパーティの実際のＩＤは、知られているＩＤに対して確認されない。実際には、レルム作成において与えられた期待される署名が、レルム・アクティブ化時の実際のパラメータから生成された実際の署名とマッチする場合に、任意のパーティが、所与のレルムの作成を要求する及びそれのレルムがアクティブ化されることを可能にすることを可能にされ得る。したがって、攻撃者が、期待されるものとは異なる署名を提供し、実際のパラメータが、その異なる署名とマッチするやり方でセットアップされる場合、レルムは、アクティブ化されることを可能にされることになる。しかしながら、レルムの鍵材料における署名者の公開鍵の包含は、真のパラメータ署名者によって保護されたデータにアクセスすることを可能にされている攻撃者によって構成されるレルムから保護し、したがって、セキュリティは、さらに行使される。署名チェックの目的は、レルムのインストールを要求するパーティのＩＤを確認するためではなくて、不適切にパラメータを修正する親レルムから保護するために、レルムのインストールを要求するときに署名と共に提供されたパラメータとアクティブ化時に定義されたパラメータがマッチすることをチェックするため（レルムのインストールを要求したのが誰であっても）である。

【0149】

図２０に示すように、レルム・パラメータはまた、所与のレルムのためにインストールされているソフトウェアのバージョンを表し得るエポック指示４３０をオプションで含み得る。エポック４３０は、期待される署名４１０及びパラメータ署名４２２によってカバーされる。また、エポック４３０は、レルム秘密を導出するための鍵材料に含まれる。これは、インストールされた及びレルム・ソフトウェアのどのバージョンが前の又は後のレルム／バージョンによって確立された秘密を導出又は使用することを可能にされるかのチェックを可能にするレルム・ソフトウェアのバージョンの検証を可能にする。したがって、セキュリティ脆弱性が、所与のエポック値を有する特定のバージョンのレルム・ソフトウェアで後で識別された場合、その問題を解決するための更新は、後のエポック値を与えられ得る。レルム秘密導出は、レルムがそれ自体より前の又は同じ任意のセキュリティ・エポックの秘密を導出又は使用することを可能にされるが、独自のエポックより新しい任意のセキュリティ・エポックの秘密を導出することができないようになり得る。レルム署名によってカバーされるパラメータにエポックを含むことによって、これは、レルム作成時に最初のレルム・パラメータを与えられることとレルムのアクティブ化との間のエポックの更新を試みる親レルムから保護する。

【0150】

図２１は、パラメータ署名に基づいてレルム・パラメータを確認する方法を示す流れ図である。ステップ４４０において、アクティブ化されることになる目標レルムの親レルムは、目標レルムを指定するレルム・アクティブ化コマンドを発行する。ステップ４４２において、ＲＭＵ２０は、目標レルムが新しい状態にあるかどうかをチェックし、そして、新しい状態にない場合には、次いで、ステップ４４４において、障害がトリガされる。レルムが、新しい状態にある場合、次いで、ステップ４４６で、ＲＭＵが、パラメータ署名が有効にされるかどうかをチェックする。いくつかのシステムでは、パラメータ署名は、システム全体について有効又は無効にされ得る。他の実装形態において、パラメータ署名は、個々のレルムについて有効又は無効にされ得る（たとえば、親レルムが更新することを可能にされない、レルム記述子のセキュリティ構成パラメータを使用して）。パラメータ署名が、無効にされた場合、次いで、ステップ４４８で、目標レルムのアクティブ化は、パラメータ署名にかかわらず、可能にされる。

【0151】

しかしながら、パラメータ署名が、有効にされた場合、次いで、ステップ４５０において、ＲＭＵが、目標レルムのレルム記述子からレルム・パラメータの期待される署名４１０を取得する。ステップ４５２において、ＲＭＵは、目標レルムのレルム記述子に定義された実際のセキュリティ構成パラメータ４２０のサブセットに基づいて、及びレルム内容の測定４２１に基づいて、パラメータ署名４２２を生成する。ステップ４５４において、ＲＭＵは、パラメータ署名４２２が期待される署名４１０とマッチするかどうかを判定し、マッチする場合には、ステップ４５６において、アクティブ化が可能にされ、署名者ＩＤ４１２及びエポック４３０は、レルム秘密を導出するための鍵材料に含まれる。パラメータ署名が、期待される署名とマッチしない場合、次いで、ステップ４５８において、アクティブ化制約が、適用される。これは、アクティブ化が成功することを防止するために障害を生成することになり得る、又は別法として、アクティブ化は可能にされ得るが、構成設定が、そのレルムがそれのレルム秘密にアクセスすることを防止するために、指定され得る。

【0152】

信頼される仲介レルム
図２２に示すように、レルムは、特定の物理システムによって統制される特定のシステムで最初に作成され得る。いくつかの後の時点において、それは、同じ又は異なるシステムで終了され、次いで再開され得る、或いは、同じレルムの複数のインスタンスが、負荷バランシング又は冗長性を目的として同じ又は異なるシステムで作成され得る。いずれの場合にも、それは、同じレルムのすべてのインスタンスが導出され得る、秘密鍵によって保護された、同じデータ・セットを共用するために必要とされ得る。同様に、レルムのセキュリティ構成パラメータは、同じレルムの複数のインスタンスにわたって無矛盾である必要があり得る。レルム再開を生き延びる、又は異なるシステムで再作成することが可能である必要がある任意のバインディングは、それ自体の物理システムの特定のインスタンスによって管理することができる。

【0153】

図２３に示すように、関連する問題は、サービス・プロバイダは、すべての利用可能なコンピューティング資源にわたる負荷、冗長性などを管理するために、データセンタ内の異なるシステム間で、又は異なるデータセンタ間でレルムを移行する能力を必要とし得るということである。前述のレルムベースの保護を有さないシステムの場合、移行は、たとえば、仮想マシンを一時停止させること、仮想マシン全体をページ・アウトすること、異なるマシンでそれを復帰させること、及び次いでそれを再び開始することによって、実装され得る。宛先は、通常は、移行プロセスの開始時には知られていないが、いくつかの後のポイントにおいて判定され、そのようにして、移行された仮想マシンは、任意のシステムで最後には復帰させられ得る。場合により、プロセスは、仮想マシンがまだ実行している間に、開始され得る（「ライブ移行」）。前述のレルムベースの保護を使用するシステムで、この既存の移行プロセスは、レルムベースのシステムの基礎的セキュリティ保証を破ることになるので、機能しない。たとえば、レルムは、知られているセキュリティ・プロパティを有するシステムで開始及び証明されてあることがある。通常の移行プロセスは、データセンタ内の信頼されていないシステム・ソフトウェアを含むので、ページングによるそのような移行で、宛先システムが、レルムが新しいシステムでアクティブ化される前に、同じセキュリティ・プロパティを有することを行使することは、レルム又は所与の物理システムのＲＭＵ２０にとって、不可能である。

【0154】

これらは、所与の目標レルムと関連付けられた、及びその目標レルムと関連付けられた外部パーティのために目標レルムを管理することを可能にされた、信頼される仲介レルムを定義することによって、対処され得る。異なる物理プラットフォーム間でレルムを移行すること、或いは「同じレルム」の各インスタンスのための無矛盾のセットの秘密鍵及びセキュリティ構成パラメータを有しながらレルムのインスタンスを終了する及び後で復帰させることが可能であるように、信頼される仲介レルムは、たとえば、「プロビジョニング済みの」秘密の挿入並びに／又はセキュリティ構成パラメータの保存及び復元を含む、ある特定のレルム管理機能を実行することを可能にされ得る。

【0155】

図２４に示すように、所与のレルムＡは、同じ物理インスタンスで動作する別のレルムである、信頼される仲介レルムの識別子５００をそれのレルム・セキュリティ構成パラメータ４００において（すなわち、それのレルム記述子１２４において）指定し得る。たとえば、前述のグローバル・レルム識別子（ＧＲＩＤ：Ｇｌｏｂａｌ Ｒｅａｌｍ ＩＤｅｎｔｉｆｉｅｒ）は、信頼される仲介レルムを識別するために使用され得る。場合により、所与のレルムＡのレルム記述子内のセキュリティ構成パラメータはまた、レルムが信頼される仲介レルムと関連付けられているか否かを示すフラグを含み得る。別法として、いくつかの実装形態において、これが、信頼される仲介レルム識別子フィールド５００内の値から推定され得る場合、そのようなフラグは、必須ではないことがある。たとえば、信頼される仲介レルム識別子５００が、実レルムの可能にされる識別子ではない値に設定された場合、次いで、これは、所与のレルムと関連付けられた信頼される仲介レルムが存在しないことを黙示的に識別し得る。レルムは、単に、１つの信頼される仲介レルムによって管理され得るが、１つの信頼される仲介レルムは、信頼される仲介レルムと同じレルムをそれぞれ指定する複数の他のレルムを管理し得る。

【0156】

信頼される仲介レルムは、関連付けられたレルムＡを管理するための情報をそれの所有されるメモリ・ページ５０２内に記憶し得る。たとえば、信頼される仲介レルムは、レルムＡのデータ及びコードを保護するための秘密鍵を導出するための鍵材料としてレルムＡに挿入され得るいくつかのプロビジョニング済みの秘密５０４、並びにそれらの鍵がどのように及びいつ挿入され得るかに関する情報を指定し得る鍵管理ポリシー５０６を記憶し得る。また、信頼される仲介レルムの所有されるページ５０２は、レルムＡのレルム記述子に挿入され得る１セットのセキュリティ構成パラメータを示し得る構成記録５０８を記憶し得る。信頼される仲介レルムによるレルムＡのセキュリティ構成パラメータの更新は、レルムのアクティブ化の前には制約され得る。レルム記述子のパラメータのうちのいくつかは、信頼される仲介レルムによって設定されることを可能にされないことがある（たとえば、信頼される仲介レルム自体の識別子）。

【0157】

いくつかの実例において、セキュリティ構成記録５０８は、信頼される仲介レルムの作成時に信頼される仲介レルムに提供されてあることがある（たとえば、信頼される仲介レルムによって管理されることになるレルムＡのセキュリティ構成記録５０８は、信頼される仲介レルムの作成時に信頼される仲介レルムの親レルムに提供される情報のバンドルに含まれ得る）。

【0158】

別法として、セキュリティ構成記録は、レルムＡのアクティブ化の後にキャプチャされる、レルムＡの構成パラメータのスナップショットとして生成され得る。たとえば、信頼される仲介レルムは、レルムＡのセキュリティ構成パラメータのスナップショットが、返され、信頼される仲介レルムによって所有されるメモリ領域にセキュリティ構成記録として記憶されることを要求する、ＲＭＵ２０へのコマンドを発行することを可能にされ得る。コマンドを発行するレルムが、レルムＡについて定義されたレルム・セキュリティ構成パラメータ４００内の識別子５００において指定された信頼される仲介レルム以外の任意のレルムである場合、そのようなコマンドは、ＲＭＵによって拒否され得る。これは、アクティブ・レルムのパラメータがバックアップされることを可能にし、したがって、それらは、たとえば、図２２に示すような前に終了されたレルムの復帰を可能にするために、又は図２３に示すような異なる物理プラットフォームへのレルムの移行を可能にするために、又は所与のレルムの構成を前の状態にロール・バックするために、後で復元され得る。セキュリティ構成記録５０８は、異なるプラットフォームへのレルムの移行が、どのように、いつ可能にされるか、及び可能にされるかどうか、並びにどのような状態の下かを制御するための属性を定義し得る移行ポリシー５１０と関連付けられ得る。

【0159】

プロビジョニング秘密の挿入とセキュリティ構成記録の保存及び復元との両方を信頼される仲介レルムがサポートすることは必要ではない。いくつかの仲介レルム（又はレルムベースのアーキテクチャ全体のいくつかの実装形態）は、これらの機能のうちの１つのみを処理することができ得る。

【0160】

レルム作成時のある特定の信頼される仲介レルムとのレルムの関連付けは、目標レルムの証明書及び／又は信頼される仲介レルムの証明書をＲＭＵ２０が生成することを要求することによって、外部パーティによって又は他のレルムによって確認され得る。そのような証明書は、レルムのセキュリティ構成パラメータの署名又は信頼される仲介レルムによって管理されている目標レルムＡのレルム内容を含み得る。証明書が、レルムＡについて生成されるとき、レルムＡは信頼される仲介と関連付けられているという事実は、レルム証明書から明らかになり得る。仲介レルムの直接証明書は、目標レルムＡの証明書に含まれるので、又は、別個の証明書生成コマンドが、仲介レルムの別個の証明書を要求するために、発行され得るように、目標レルムへの証明書は、信頼される仲介レルムの識別子を指定し得るので、目標レルムＡを証明するとき、証明書をチェックする認証エンティティはまた、関連付けられた信頼される仲介レルムを証明し得る。

【0161】

したがって、信頼される仲介レルムを定義することによって、これは、異なる瞬間に、又は、ＲＭＵのみを介して若しくはレルム自体のコードを介して安全に管理することが難しくなる、共通の鍵又はセキュリティ構成パラメータへのアクセスをそれぞれ共用する異なる物理プラットフォームで、所与のレルムの複数のインスタンスが確立されることを可能にする。

【0162】

図２５は、目標レルムと関連付けられたセキュリティ構成パラメータを更新するためのセキュリティ構成パラメータ更新コマンドの処理の方法を示す。このコマンドは、目標レルムと関連付けられたセキュリティ構成パラメータを更新するために使用され得る。ステップ５２０において、パラメータが更新されることになる、目標レルムを指定する、セキュリティ構成パラメータ更新コマンドが、受信される。

【0163】

ステップ５２２において、ＲＭＵ２０は、コマンドによって識別された目標レルムが、現在、クリーン状態にあるかどうかをチェックする。クリーン状態にない場合、レルムが、クリーン状態から新しい状態に渡された後は、セキュリティ構成パラメータは更新不可能であるので、次いで、ステップ５２４において、障害が、生成される。レルムが、クリーン状態にある場合、次いで、ステップ５２４において、コマンドを発行したレルムが目標レルムの親レルムであるかどうかが判定される。そうである場合、次いで、ステップ５２８において、更新が、親レルムが更新することを可能にされる１サブセットのセキュリティ構成パラメータへであれば、ＲＭＵは、その要求されたパラメータ更新を可能にする。秘密鍵などの所与のレルムのレルム記述子の内容のうちのいくつかは、所与のレルムの親レルムにアクセス不可能なことがある。また、いくつかのパラメータ、たとえば、レルムが信頼される仲介レルムと関連付けられているかどうか、信頼される仲介レルムのＩＤ、期待される署名４１０、署名者ＩＤ４１２など、は、親レルムによって更新されることを可能にされないことがある。

【0164】

コマンドが、親レルムによって発行されなかった場合、次いで、ステップ５３０において、ＲＭＵ２０は、目標レルムが信頼される仲介レルムと関連付けられているかどうか及びコマンドは信頼される仲介レルムによって発行されたかどうかをチェックする。目標レルムが、信頼される仲介レルムと関連付けられなかった場合、又はコマンドが、目標レルムと関連付けられた信頼される仲介レルムによって発行されなかった場合、次いで、ステップ５３２において、障害がトリガされる。そうではなくて、コマンドが、目標レルムと関連付けられた信頼される仲介レルムによって発行された場合、次いで、ステップ５３４において、レルム記述子のパラメータ更新は、可能にされる。再び、信頼される仲介レルムが更新することを可能にされないいくつかのパラメータが存在し得るが、これらは、親レルムが更新することを可能にされないものよりも少数のパラメータになり得る。たとえば、信頼される仲介レルムは、どのレルムが信頼される仲介レルムとして識別されるかを変更することを可能にされないことがある。しかしながら、親レルムとは異なって、信頼される仲介レルムは、レルムと関連付けられたデータ／コードを保護するための鍵を生成するための鍵材料であるプロビジョニング済みの秘密を更新することを可能にされ得る。

【0165】

ＲＭＵはまた、目標レルムのセキュリティ構成パラメータのサブセットのスナップショットを表すセキュリティ構成記録５０８のキャプチャをトリガするためのコマンドをサポートし得る。そのようなコマンドは、単に、目標レルムのレルム記述子において定義された信頼される仲介レルムによって発行されるときに、受け付けられ得る。

【0166】

図２６は、目標レルムの証明書の生成をトリガするための証明書コマンドの処理の方法を示す。ステップ５５０において、ＲＭＵ２０は、証明書が生成されることになる目標レルムを識別する証明書コマンドを受信する。ステップ５５２において、証明書コマンドが受け付けられ得るかどうかが判定され、受け付けられ得ない場合には、次いで、ステップ５５４において、障害が生成される。様々なチェックが、証明書コマンドが受け付けられ得るかどうかを判定するために、実行され得る。証明書コマンドによって識別された目標レルムが、無効な場合、証明書コマンドは、拒否され得、障害がトリガされ得る。また、証明書コマンドが、目標レルムと関連付けられた信頼される仲介レルム以外のレルムによって発行された場合、次いで、証明書コマンドは、目標レルムがアクティブ状態にある場合には、受け付けられ得、目標レルムが別の状態にある場合には、拒否され得る。証明書コマンドが、信頼される仲介レルムによって発行された場合、次いで、証明書コマンドは、目標レルムが、クリーン状態、新しい状態又はアクティブ状態のいずれかにある場合には、受け付けられ得る。

【0167】

証明書コマンドが、受け付けられた場合、次いで、ステップ５５６において、証明書情報が、目標レルムのセキュリティ構成パラメータに基づいて生成され、証明書情報は、目標レルムがある種のプロパティを満たすかどうかを認証エンティティがチェックすることを可能にするいくつかの情報を提供する。ステップ５５８において、ＲＭＵ２０は、目標レルムが信頼される仲介レルムと関連付けられているかどうかをチェックする。そうである場合、次いで、ステップ５６０において、次いで、ＲＭＵ２０は、目標レルムは信頼される仲介レルムと関連付けられていることを示す情報を証明書情報に含み、信頼される仲介レルムを識別する又は仲介レルムのプロパティを証明する証明書情報を提供する仲介レルム証明書情報も含む。目標レルムが、関連付けられた信頼される仲介レルムを有さなかった場合、次いで、ステップ５６０は省略される。いずれにしても、ステップ５６２において、証明書情報は、証明書の有効性を証明する鍵で署名され、証明書は、それを要求したパーティに出力される。

【0168】

したがって、目標レルムが、信頼される仲介レルムと関連付けられているとき、認証するパーティは、目標レルム自体の証明書をチェックすることによって又は目標レルムの証明書に含まれる識別子を使用して信頼される仲介レルムのさらなる証明書を要求することによって、証明書を使用して、信頼される仲介レルムがある種のプロパティを有するかどうかをチェックすることができる。このようにして、信頼は、適切に振る舞う信頼される仲介レルムによって目標レルムは正しく構成されたという事実に対して、確保され得る。

【0169】

したがって、要約すると、信頼される仲介は、それがそのパーティのために他のレルムを管理することを可能にする特別なプロパティを有して、管理されることになる所与のレルムと同じレルム管理パーティ（たとえば、同じバンキング・プロバイダ、医療提供者など）と関連付けられたレルム自体である、所与のレルムを管理するために定義される。最も単純な実装形態において、（レルム管理パーティごとの）信頼される仲介の１つのインスタンスは、レルムが存在し得る各システムに存在し得る。信頼される仲介自体がレルムであるので、それは、信頼される仲介のみが、必要とされるセキュリティ・プロパティを有するシステムで、アクティブになる／権限を与えられることが可能であることを確実にして、権限付与の一部としてレルム管理パーティによって証明され得る。

【0170】

したがって、レルムは、以下のように、レルム作成において、信頼される仲介と関連付けられ得る。識別された信頼される仲介のみが、レルムを管理し得、レルムは信頼される仲介と関連付けられているという事実が、レルム証明書から明らかであり、そして、レルムを証明するとき、認証エンティティはまた、関連付けられた信頼される仲介を証明し得る。信頼される仲介は、装置２の所与の物理インスタンスからレルムのセキュリティ・コンテキストを受信し得、同じインスタンス又は異なるインスタンスでレルムのセキュリティ・コンテキストを復帰させ得る。レルム所有者の移行ポリシーは、レルム所有者と関連付けられた信頼される仲介内でエンコードされる。ポリシー自体が、信頼される仲介を証明することによって、証明され得る。これは、どのように及びいつレルム・セキュリティ・コンテキストが異なるシステム間で転送されるかのポリシーを含む。二次使用として、同じ方法が、関連使用事例、たとえば、完全なレルムのバックアップ／復元、又はそれが前の知られている状態にロール・バックされることを可能にするレルムのスナップショット／チェックポイントの取得など、をサポートし得る。

【0171】

信頼される仲介は、レルムがアクティブ化される前に、管理されるレルムを証明し得る。信頼される仲介は、レルムがアクティブ化される前に、レルム作成中にプロビジョニング済みのルート秘密を挿入することを可能にされる。レルム所有者の鍵管理ポリシーは、レルム所有者と関連付けられた信頼される仲介内でエンコードされる。ポリシー自体が、信頼される仲介を証明することによって、証明され得る。これは、たとえば、レルムの再開の後の、又は同じレルムの複数のインスタンスへの、又はレルムが期せずして開始されるのがどのシステムかとは無関係の、同じルート秘密のプロビジョニングを含む。

【0172】

図２７は使用可能なシミュレータ実装を示す。前に説明した実施例は、関連する技術をサポートする特定の処理ハードウェアを動作させるための装置及び方法に関して、本発明を実装しているが、コンピュータ・プログラムの使用により実装された本明細書に記載の実施例による、命令実行環境を提供することも可能である。こうしたコンピュータ・プログラムは、ソフトウェアに基づくハードウェア・アーキテクチャの実装を提供する限り、しばしばシミュレータと呼ばれる。様々なシミュレータ・コンピュータ・プログラムとしては、エミュレータ、仮想マシン、モデル、及び動的バイナリ・トランスレータを含むバイナリ・トランスレータが挙げられる。通常、シミュレータ実装は、シミュレータ・プログラム７１０をサポートする、ホスト・オペレーティング・システム７２０をオプションとして実行させる、ホスト・プロセッサ７３０上で実行することができる。いくつかの構成では、ハードウェアと提供された命令実行環境との間にシミュレーションの複数の層、及び／又は同じホスト・プロセッサに提供された複数の異なる命令実行環境があってもよい。歴史的に見て、納得のいく速度で実行するシミュレータ実装を提供するには、強力なプロセッサが必要とされてきたが、こうした手法は、互換性又は再利用の理由で別のプロセッサにネイティブなコードを実行したいという要望があるときなど、一定の事情において正当化することができる。たとえば、シミュレータ実装は、ホスト・プロセッサ・ハードウェアによってサポートされない追加の機能を有する命令実行環境、又は、通常、異なるハードウェア・アーキテクチャと関連付けられた命令実行環境を提供することができる。シミュレータの全体像は、「Ｓｏｍｅ Ｅｆｆｉｃｉｅｎｔ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｓｉｍｕｌａｔｉｏｎ Ｔｅｃｈｎｉｑｕｅｓ」、１９９０年冬、ＵＳＥＮＩＸ Ｃｏｎｆｅｒｅｎｃｅ、５３～６３頁に述べられている。

【0173】

シミュレートされた実施例において、特定のハードウェア構成又は機能を参照して、実施例が以前に説明された範囲で、同等の機能を適切なソフトウェア構成又は機能により提供することができる。たとえば、特定の回路（たとえば、ＭＭＵ２６及びＲＭＵ２０）は、シミュレータ・プログラム７１０内のコンピュータ・プログラム論理（たとえば、メモリ・アクセス・プログラム論理及びレルム管理プログラム論理）としてシミュレートされた実施例において実装され得る。同様に、レジスタ又はキャッシュといったメモリ・ハードウェアは、ソフトウェア・データ構造としてシミュレートされた実施例に実装することができる。前に説明した実施例で参照された１つ又は複数のハードウェア要素が、ホスト・ハードウェア（たとえば、ホスト・プロセッサ７３０）に存在する配列において、いくつかのシミュレートされた実施例は、適切なホスト・ハードウェアを使用することができる。

【0174】

シミュレータ・プログラム７１０は、コンピュータ可読記憶媒体（これは非一時的な媒体でよい）に記憶することができ、プログラム・インターフェース（命令実行環境）を、シミュレータ・プログラム７１０によってモデル化されているハードウェア・アーキテクチャのアプリケーション・プログラム・インターフェースと同じ目標コード７００（これは、図２に表すように、アプリケーション、オペレーティング・システム、及びハイパーバイザを含むことができる）に提供する。したがって、上で説明したレルム保護機能に基づくメモリ・アクセスの制御を含む、目標コード７００のプログラム命令は、シミュレータ・プログラム７１０を使用して命令実行環境内から実行することができ、その結果、上で説明した装置２のハードウェア機能を実際には有していないホスト・コンピュータ７３０が、これらの機能をエミュレートすることができる。

【0175】

本出願において、「構成される」という用語は、装置の要素が定義された動作を実行することができる構成を有しているということを意味するために使用される。この文脈において、「構成」とは、ハードウェア又はソフトウェアの配置又は相互接続の方法を意味する。たとえば、装置は、定義された動作を提供する専用ハードウェアを有してもよく、又は、プロセッサ若しくは他の処理デバイスは、機能を実行するようにプログラムされてもよい。「構成される」とは、装置の要素が定義された動作を提供するために、どのような方法によってであれ、変更される必要があるということを暗示しない。

【0176】

本発明の例示の実施例について、本明細書において添付図面を参照しながら詳細に説明してきたが、本発明は、これらの明確な実施例に限定されるものではなく、添付の請求項によって定義された本発明の範囲及び趣旨から逸脱することなく、当業者により様々な変更及び改変をその中で行うことができることを理解されたい。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17A】

【図17B】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【国際調査報告】