知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6970103
(24)【登録日】2021年11月1日
(45)【発行日】2021年11月24日
(54)【発明の名称】署名済み有界ポインタを生成するための装置及び方法
(51)【国際特許分類】
G06F 21/12 20130101AFI20211111BHJP
G06F 21/62 20130101ALI20211111BHJP
【ＦＩ】
G06F21/12
G06F21/62 318
【請求項の数】17
【全頁数】36
(21)【出願番号】特願2018-540741(P2018-540741)
(86)(22)【出願日】2016年12月23日
(65)【公表番号】特表2019-505928(P2019-505928A)
(43)【公表日】2019年2月28日
(86)【国際出願番号】GB2016054060
(87)【国際公開番号】WO2017137714
(87)【国際公開日】20170817
【審査請求日】2019年12月16日
(31)【優先権主張番号】1602544.7
(32)【優先日】2016年2月12日
(33)【優先権主張国】GB
(73)【特許権者】
【識別番号】500395107
【氏名又は名称】アーム・リミテッド
(74)【代理人】
【識別番号】110000855
【氏名又は名称】特許業務法人浅村特許事務所
(72)【発明者】
【氏名】バーンズ、グレーム ピーター
【審査官】
渡辺 順哉
(56)【参考文献】
【文献】
特開２０１１−０８１７９０（ＪＰ，Ａ）
【文献】
米国特許第０６８２６６７２（ＵＳ，Ｂ１）
【文献】
特開２００４−０１３５５６（ＪＰ，Ａ）
(58)【調査した分野】（Int.Cl.，ＤＢ名）
Ｇ０６Ｆ ９／３０−９／３５５
Ｇ０６Ｆ １２／１４
Ｇ０６Ｆ ２１／１０−２１／１６
Ｇ０６Ｆ ２１／５０−２１／８８
(57)【特許請求の範囲】
【請求項1】
少なくとも１つの生成条件が満たされることを条件に、指定されたデータから有界ポインタを生成する生成作業を行うよう、有界ポインタ生成リクエストに応答する処理回路であって、前記有界ポインタはポインタ値と関連付けられた属性とを有し、前記関連付けられた属性は前記ポインタ値を使用するときのアドレスの許容範囲を示す範囲情報を含む、処理回路であって、
当該処理回路が、署名が前記指定されたデータの一部から判断され、前記生成された有界ポインタに組み込まれる署名挿入作業を、少なくとも署名条件が満たされるときに前記生成作業の一部として行うよう、生成されることになる前記有界ポインタが前記署名を組み込んでいる署名済み有界ポインタであるとの前記指定されたデータからの検出に応答する処理回路と、
前記処理回路によって生成された前記有界ポインタを記憶する記憶装置と
を備える、装置。
当該処理回路が、署名が前記指定されたデータの一部から判断され、前記生成された有界ポインタに組み込まれる署名挿入作業を、少なくとも署名条件が満たされるときに前記生成作業の一部として行うよう、生成されることになる前記有界ポインタが前記署名を組み込んでいる署名済み有界ポインタであるとの前記指定されたデータからの検出に応答する処理回路と、
前記処理回路によって生成された前記有界ポインタを記憶する記憶装置と
を備える、装置。
【請求項2】
前記処理回路が、前記署名挿入作業を行う際に、前記有界ポインタが署名済みになったことを識別するために、前記生成された有界ポインタの前記関連付けられた属性に署名情報をセットするようにさらに構成される、請求項１に記載の装置。
【請求項3】
前記処理回路が、前記署名条件が満たされる場合にのみ、前記生成作業の一部として前記署名挿入作業を行うように構成され、
前記処理回路が、前記署名条件が満足されないと判断することに応答して、前記有界ポインタの生成を防ぐように構成される
請求項１又は請求項２に記載の装置。
前記処理回路が、前記署名条件が満足されないと判断することに応答して、前記有界ポインタの生成を防ぐように構成される
請求項１又は請求項２に記載の装置。
【請求項4】
前記署名条件が、前記処理回路が少なくとも１つの所定の特権状態で動作しているときに満たされる、請求項３に記載の装置。
【請求項5】
少なくとも１つの所定の特権状態で動作しているときに前記処理回路によって書込み可能な構成記憶要素をさらに備え、
前記署名条件が、前記署名挿入作業の実行が許可されていることを前記構成記憶要素が識別するときに満たされる、
請求項３又は請求項４に記載の装置。
前記署名条件が、前記署名挿入作業の実行が許可されていることを前記構成記憶要素が識別するときに満たされる、
請求項３又は請求項４に記載の装置。
【請求項6】
署名能力を記憶するための能力記憶要素をさらに備え、
前記処理回路が、前記署名挿入作業のためのオペランドとして前記能力記憶要素から前記署名能力を取得するように構成され、
前記署名条件が、前記署名挿入作業の実行が許可されていることを、前記署名能力が識別するときに満たされる、
請求項３から５までのいずれか一項に記載の装置。
前記処理回路が、前記署名挿入作業のためのオペランドとして前記能力記憶要素から前記署名能力を取得するように構成され、
前記署名条件が、前記署名挿入作業の実行が許可されていることを、前記署名能力が識別するときに満たされる、
請求項３から５までのいずれか一項に記載の装置。
【請求項7】
前記処理回路が、前記生成作業の実行中に総合能力にアクセスできるように構成され、前記総合能力は、任意の許された有界ポインタが当該総合能力から導き出されることを可能にするのに充分な情報を提供し、
前記処理回路が、前記指定されたデータを参照して、前記総合能力に対して精錬処理を行うように構成され、
前記少なくとも１つの生成条件が、前記精錬処理が前記指定されたデータと矛盾しない許された有界ポインタを結果として生成するときに満たされる、
請求項１から６までのいずれか一項に記載の装置。
前記処理回路が、前記指定されたデータを参照して、前記総合能力に対して精錬処理を行うように構成され、
前記少なくとも１つの生成条件が、前記精錬処理が前記指定されたデータと矛盾しない許された有界ポインタを結果として生成するときに満たされる、
請求項１から６までのいずれか一項に記載の装置。
【請求項8】
前記精錬処理の間、前記処理回路が、前記指定されたデータの対応する部分の値にマッチするように、前記総合能力内で識別される前記範囲情報及び１つ又は複数の許可を狭くしようとする、請求項７に記載の装置。
【請求項9】
前記精錬処理の間、前記処理回路が、前記ポインタ値を、前記総合能力によって許され、かつ、前記指定されたデータの対応する部分の前記値にマッチする値にさらにセットしようとする、請求項８に記載の装置。
【請求項10】
生成されることになる前記有界ポインタが署名済み有界ポインタになるであろうことを前記指定されたデータが示すとき、署名に特有の情報を収める任意の部分以外の、前記指定されたデータの部分にマッチする許された有界ポインタに、前記精錬処理が帰結するときに、前記少なくとも１つの生成条件が満たされる、請求項７から９までのいずれか一項に記載の装置。
【請求項11】
署名に特有の情報を収める前記指定されたデータの前記部分が、前記署名が判断される部分である、請求項１０に記載の装置。
【請求項12】
署名に特有の情報を収める前記指定されたデータの前記部分が、前記有界ポインタが署名されていることを識別するために、前記生成された有界ポインタの前記関連付けられた属性に挿入されることになる署名情報を提供するデータ・フィールドをさらに含む、請求項１１に記載の装置。
【請求項13】
前記処理回路が、前記有界ポインタの無署名版の中のその内容が前記有界ポインタの他のビットから再現できる複数の指定されたビットの中の前記生成された有界ポインタに前記署名を組み込むように構成される、請求項１から１２までのいずれか一項に記載の装置。
【請求項14】
前記複数の指定されたビットが、前記有界ポインタの前記無署名版に前記ポインタ値の一部を収めるために使用され、
前記ポインタ値の前記一部は、前記ポインタ値の残りの部分から導き出せる、
請求項１３に記載の装置。
前記ポインタ値の前記一部は、前記ポインタ値の残りの部分から導き出せる、
請求項１３に記載の装置。
【請求項15】
前記複数の指定されたビットが、前記有界ポインタの前記無署名版に前記範囲情報の一部を収めるために使用され、
前記範囲情報によって指定された範囲が、前記範囲情報の残りの部分の中で表されることができる、
請求項１３に記載の装置。
前記範囲情報によって指定された範囲が、前記範囲情報の残りの部分の中で表されることができる、
請求項１３に記載の装置。
【請求項16】
有界ポインタ生成リクエストに応答して、少なくとも１つの生成条件が満たされることを条件に、指定されたデータから有界ポインタを生成する生成作業を処理回路が行うようにするステップであって、前記有界ポインタはポインタ値及び関連付けられた属性を有し、前記関連付けられた属性は、前記ポインタ値を使用するときのアドレスの許容範囲を示す範囲情報を含む、ステップと、
生成されることになる前記有界ポインタが署名を組み込んでいる署名済み有界ポインタであるとの前記指定されたデータからの検出に応答して、及び少なくとも署名条件が満たされるときに、前記署名が前記指定されたデータの一部から判断され、前記生成された有界ポインタに組み込まれる署名挿入作業を、前記生成作業の一部として前記処理回路が行うようにするステップと、
前記生成された有界ポインタを記憶位置に記憶するために前記処理回路から出力するステップと
を含む、署名済み有界ポインタを生成する方法。
生成されることになる前記有界ポインタが署名を組み込んでいる署名済み有界ポインタであるとの前記指定されたデータからの検出に応答して、及び少なくとも署名条件が満たされるときに、前記署名が前記指定されたデータの一部から判断され、前記生成された有界ポインタに組み込まれる署名挿入作業を、前記生成作業の一部として前記処理回路が行うようにするステップと、
前記生成された有界ポインタを記憶位置に記憶するために前記処理回路から出力するステップと
を含む、署名済み有界ポインタを生成する方法。
【請求項17】
有界ポインタ生成リクエストに応答して、少なくとも１つの生成条件が満たされることを条件に、指定されたデータから有界ポインタを生成する生成作業を行うための処理手段であって、前記有界ポインタはポインタ値と関連付けられた属性とを有し、前記関連付けられた属性は前記ポインタ値を使用するときのアドレスの許容範囲を示す範囲情報を含む、処理手段であって、
当該処理手段が、生成されることになる前記有界ポインタが署名を組み込んでいる署名済み有界ポインタであるとの前記指定されたデータからの検出に応答して、及び少なくとも署名条件が満たされるときに、前記署名が前記指定されたデータの一部から判断され、前記生成された有界ポインタに組み込まれる署名挿入作業を、前記生成作業の一部としてさらに行うための処理手段と、
前記処理手段によって生成された前記有界ポインタを記憶するための記憶手段と
を備える、装置。
当該処理手段が、生成されることになる前記有界ポインタが署名を組み込んでいる署名済み有界ポインタであるとの前記指定されたデータからの検出に応答して、及び少なくとも署名条件が満たされるときに、前記署名が前記指定されたデータの一部から判断され、前記生成された有界ポインタに組み込まれる署名挿入作業を、前記生成作業の一部としてさらに行うための処理手段と、
前記処理手段によって生成された前記有界ポインタを記憶するための記憶手段と
を備える、装置。
【発明の詳細な説明】
【技術分野】
【0001】
本技法は、データ処理の分野に関する。
【背景技術】
【0002】
いくつかのデータ処理装置は、特定のアドレスを示すポインタが、ポインタのアドレスの許容範囲を示す範囲情報と関連付けられる有界ポインタ（ｂｏｕｎｄｅｄ ｐｏｉｎｔｅｒ）をサポートすることがある。例えば、このようなポインタは、「ファット・ポインタ（ｆａｔ ｐｏｉｎｔｅｒ）」と呼ばれることがある。
【0003】
範囲情報に加えて、このような有界ポインタは、ポインタの使用について１つ又は複数の制限／許可を定義する他の関連付けられた属性を有することもある。したがって、このような有界ポインタの使用は、有界ポインタによって指定されたポインタ値がどのように使用されるかについて制約を課すことによって、強固なセキュリティをもたらすことができる。
【先行技術文献】
【非特許文献】
【0004】
【非特許文献1】Ｒ Ｗａｔｓｏｎ、外、「Capability Hardware Enhanced RISC Instructions: CHERI Instruction-Set Architecture」、技術レポート、University of Cambridge Computer Laboratory、第８５０号、UCAM-CL-TR-850、ISSN 1476-2986
【発明の概要】
【発明が解決しようとする課題】
【0005】
有界ポインタが、レジスタとメモリの両方の中にある汎用データと区別されることを可能にする技法が開発されてきたが、このような有界ポインタは、ディスクなどの補助記憶装置に出力される必要があることが時々あり、この場合、有界ポインタが補助記憶装置内の汎用データとしてしか扱われないフォーマットに、有界ポインタが分解されることがある。その後、補助記憶装置内の汎用データからこのような有界ポインタを再作成しようとすることが必要になることがあるが、汎用データからこのような能力（ｃａｐａｂｉｌｉｔｉｅｓ）を再構築するために提供されるどのような技法も慎重に制御される必要があり、そうしなければ、このような有界ポインタを使用することで備わるセキュリティの恩恵が損なわれることがあるからである。
【課題を解決するための手段】
【0006】
構成の１つの実例において、少なくとも１つの生成条件が満たされることを条件に、指定されたデータから有界ポインタを生成する生成作業を行うよう、有界ポインタ生成リクエストに応答する処理回路であって、有界ポインタはポインタ値と関連付けられた属性とを有し、関連付けられた属性はポインタ値を使用するときのアドレスの許容範囲を示す範囲情報を含む、処理回路であって、処理回路が、署名が指定されたデータの一部から判断され、生成された有界ポインタの内部に組み込まれる署名挿入作業を、少なくとも署名条件が満たされるときに生成作業の一部として行うよう、生成されることになる有界ポインタが署名を組み込んでいる署名済み有界ポインタであるとの指定されたデータからの検出に応答する処理回路と、処理回路によって生成された有界ポインタを記憶する記憶装置とを備える装置が提供される。
【0007】
構成の別の実例において、有界ポインタ生成リクエストに応答して、少なくとも１つの生成条件が満たされることを条件に、指定されたデータから有界ポインタを生成する生成作業を行うことであって、有界ポインタはポインタ値及び関連付けられた属性を有し、関連付けられた属性は、ポインタ値を使用するときのアドレスの許容範囲を示す範囲情報を含む、生成作業を行うことと、生成されることになる有界ポインタが署名を組み込んでいる署名済み有界ポインタであるとの指定されたデータからの検出に応答して、及び少なくとも署名条件が満たされるときに、署名が指定されたデータの一部から判断され、生成された有界ポインタに組み込まれる署名挿入作業を、生成作業の一部として行うことと、生成された有界ポインタを記憶位置に記憶するために出力することとを含む、署名済み有界ポインタを生成する方法が提供される。
【0008】
構成のさらなる実例において、有界ポインタ生成リクエストに応答して、少なくとも１つの生成条件が満たされることを条件に、指定されたデータから有界ポインタを生成する生成作業を行うための処理手段であって、有界ポインタはポインタ値と関連付けられた属性とを有し、関連付けられた属性はポインタ値を使用するときのアドレスの許容範囲を示す範囲情報を含む、処理手段であって、処理手段が、生成されることになる有界ポインタが署名を組み込んでいる署名済み有界ポインタであるとの指定されたデータからの検出に応答して、及び少なくとも署名条件が満たされるときに、署名が指定されたデータの一部から判断され、生成された有界ポインタに組み込まれる署名挿入作業を、生成作業の一部としてさらに行うための処理手段と、処理手段によって生成された有界ポインタを記憶するための記憶手段とを備える装置が提供される。
【0009】
本技法は、添付の図面に示されるように、本技法の実施例を参照しながら、単なる実例として、さらに説明される。
【図面の簡単な説明】
【0010】
【図1】１つの実施例による、装置のブロック図である。
【図2】有界ポインタ記憶要素のセット内のポインタ値をセット又はアクセスしようと試みる場合に、エラーがトリガされることがある命令のタイプの実例を示す図であり、ここでこのポインタ値は、関連付けられた範囲情報によって示される範囲の外側のアドレスを指定するために使用される。
【図3】１つの実施例による、有界ポインタに関連したタグ・ビット（ｔａｇ ｂｉｔ）の使用を示す図である。
【図4】１つの実施例による、署名作業及びその後の権限付与作業を概略的に示す図である。
【図5】１つの実施例による、有界ポインタの関連付けられた属性内の署名情報の使用を示す図である。
【図6】１つの実施例による、署名作業を示す流れ図である。
【図7】１つの実施例による、権限付与作業を示す流れ図である。
【図8】有界ポインタの範囲情報が、この有界ポインタのポインタ値に関連して記憶される構成の実例を示す図である。
【図9】１つの実施例による、（署名済み有界ポインタとも呼ばれる）署名済み能力の不変性を保証するために行われる作業を示す流れ図である。
【図10】１つの実施例による、署名済み能力のポインタ値の変更が許可されるときに実施されることがある一連の作業を示す流れ図である。
【図11】１つの実施例によって行われる参照先の値を取得する作業を示す流れ図である。
【図12】１つの実施例による、入力された能力がまだ署名されていない状況に能力署名作業がどのように限定されるかを示す流れ図である。
【図13】１つの実施例によって行われる取外し作業を示す流れ図である。
【図14A】取外しが許可されるかどうかを判断するために、いくつかの実施例において行われることがあるチェックの様々な実例を示す図である。
【図14B】取外しが許可されるかどうかを判断するために、いくつかの実施例において行われることがあるチェックの様々な実例を示す図である。
【図14C】取外しが許可されるかどうかを判断するために、いくつかの実施例において行われることがあるチェックの様々な実例を示す図である。
【図15】１つの実施例による、代替の署名済み能力の符号化を示す図である。
【図17】１つの実施例による、補助記憶装置に保持されるデータから能力を再構築するために使用されることがある再構築処理を概略的に示す図である。
【図18】１つの実施例によって行われることがある能力再構築処理を示す流れ図である。
【図19A】このような能力再構築処理の間に、署名が許可しているかどうかを判断するために、いくつかの実施例において行われることがある様々なチェックを示す図である。
【図19B】このような能力再構築処理の間に、署名が許可しているかどうかを判断するために、いくつかの実施例において行われることがある様々なチェックを示す図である。
【図19C】このような能力再構築処理の間に、署名が許可しているかどうかを判断するために、いくつかの実施例において行われることがある様々なチェックを示す図である。
【発明を実施するための形態】
【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】
本発明の例証的な実施例が添付の図面を参照しながら本明細書で詳細に記述されたが、本発明は、これらの正確な実施例に限定されないということ、並びに様々な変更、追加、及び修正は、添付の特許請求の範囲によって定義されるような本発明の範囲及び精神から逸脱することなく、当業者によって本発明の中で行われてよいということを理解されたい。例えば、従属請求項の特徴の様々な組合せが、本発明の範囲から逸脱することなく、独立請求項の特徴と共に行われてよい。