(57)【要約】  有界ポインタの使用を制御するために装置及び方法が提供される。装置は、有界ポインタを記憶するための記憶装置を含み、各有界ポインタはポインタ値と関連付けられた属性とを有し、関連付けられた属性は、ポインタ値を使用するときのアドレスの許容範囲を示す性質をもつ範囲情報を含む。処理回路は、入力された有界ポインタの指定されたビットの代わりに、署名作業によって生成された署名が、出力される有界ポインタの中に収められる、出力される有界ポインタを生成するために、入力された有界ポインタに対して署名作業を行うために使用される。さらに、関連付けられた属性は、出力される有界ポインタが署名されていることを識別するために、出力される有界ポインタの中に処理回路によってセットされる署名情報を含む。このようなアプローチは、有界ポインタを使用するときの制御フローの整合性への攻撃に対する障害許容力の増大をもたらす。
2019505052.tif 000002
【特許請求の範囲】
【請求項１】
有界ポインタを記憶するための記憶装置であって、各有界ポインタはポインタ値と関連付けられた属性とを有し、前記関連付けられた属性は、前記ポインタ値を使用するときのアドレスの許容範囲を示す範囲情報を含む、記憶装置と、
入力された有界ポインタの指定されたビットの代わりに、署名作業によって生成された署名が、出力される有界ポインタの中に収められる、前記出力される有界ポインタを生成するために、前記入力された有界ポインタに対して前記署名作業を行う処理回路と、
を備え、
前記関連付けられた属性が、前記出力される有界ポインタが署名されていることを識別するために、前記出力される有界ポインタの中に前記処理回路によってセットされる署名情報を含む、
装置。
【請求項２】
前記処理回路が、前記記憶装置内の有界ポインタの使用を要求する少なくとも１つのリクエストされた作業のために、前記関連付けられた属性の中の前記署名情報から、前記有界ポインタが署名済みであるか無署名であるかを判断し、かつ、前記有界ポインタが前記署名情報によって署名済みと識別されるか又は無署名であると識別されるかに応じて、前記リクエストされた作業に応答して行われるべき処理ステップを判断するように構成される、請求項１に記載の装置。
【請求項３】
前記処理回路が、有界ポインタが署名済みであるかどうかを前記署名情報から判断するため、かつ、前記有界ポインタが署名済みであると判断されるときに、少なくとも前記ポインタ値に対する修正を防ぐために、前記有界ポインタを修正しようとするリクエストされた作業に対して応答するように構成される、請求項２に記載の装置。
【請求項４】
前記署名情報が、前記有界ポインタが署名済みであることを示すために前記関連付けられた属性の中にセットされ、前記有界ポインタが無署名であることを示すために前記関連付けられた属性の中でクリアされる署名ビットである、請求項１から３までのいずれか一項に記載の装置。
【請求項５】
前記署名情報が、前記有界ポインタの少なくとも１つの他のプロパティを識別するためにも使用される複数ビットのフィールド内で符号化される、請求項１から３までのいずれか一項に記載の装置。
【請求項６】
前記処理回路が、指定された条件が満たされない限り、前記署名作業が行われるのを防ぐように構成される、請求項１から５までのいずれか一項に記載の装置。
【請求項７】
前記指定された条件が満たされると、前記出力される有界ポインタのその後の無署名化が、前記入力された有界ポインタとは異なる有界ポインタを生成しないことを保証する、請求項６に記載の装置。
【請求項８】
前記処理回路が、前記入力された有界ポインタの前記指定されたビットが、前記入力された有界ポインタの他のビットから再現できる情報を有するとき、前記指定された条件が満たされると判断するように構成される、請求項６又は請求項７に記載の装置。
【請求項９】
前記処理回路が、有界ポインタが署名されている間、メモリ内でアクセスされることになるアドレスを判断するために前記有界ポインタが使用されるのを禁止するように構成される、請求項１から８までのいずれか一項に記載の装置。
【請求項１０】
前記署名作業の実行中、前記処理回路が、前記ポインタ値の少なくとも一部を使用して前記署名を生成するように構成される、請求項１から９までのいずれか一項に記載の装置。
【請求項１１】
前記処理回路が、前記ポインタ値の前記少なくとも一部と、署名キーと、コンテキスト・データの項目と、を使用して前記署名を生成するように構成される、請求項１０に記載の装置。
【請求項１２】
前記処理回路が、入力された署名済み有界ポインタの中に収められた前記署名と、前記署名済み有界ポインタ内に提供された前記ポインタ値の少なくとも一部を使用して前記処理回路によって生成された権限付与署名との間で署名マッチが検出されることを条件に、出力される無署名の有界ポインタを生成するために、前記入力された署名済み有界ポインタに対して権限付与作業を行うよう、権限付与リクエストに対して応答する、請求項１から１１までのいずれか一項に記載の装置。
【請求項１３】
前記処理回路が、前記署名済み有界ポインタ内に提供される前記ポインタ値の前記少なくとも一部と、署名キーと、コンテキスト・データの項目と、を使用して前記権限付与署名を生成するように構成される、請求項１２に記載の装置。
【請求項１４】
前記署名マッチが検出されるとき、前記処理回路が、前記署名を、前記入力された署名済み有界ポインタの１つ又は複数のビットから判断されたデータで置き換えること、かつ、前記出力される有界ポインタが無署名であることを識別するために、前記関連付けられた属性の中の前記署名情報をクリアすることによって、前記出力される無署名の有界ポインタを生成するように構成される、請求項１２又は請求項１３に記載の装置。
【請求項１５】
前記入力された有界ポインタの前記指定されたビットが、前記ポインタ値の一部を収め、
前記処理回路が、前記ポインタ値の前記一部が前記ポインタ値の残りの部分から導き出されるときに、前記指定された条件が満たされると判断するように構成される
請求項６に依存するときの請求項１から１４までのいずれか一項に記載の装置。
【請求項１６】
有界ポインタが無署名であるとき、前記処理回路が、前記ポインタ値を、前記指定されたビットを含む前記有界ポインタのデフォルトの複数のビットによって指定されているとして解釈するように構成され、有界ポインタが署名済みであるとき、前記処理回路が、前記ポインタ値を、前記指定されたビットを除く減少された複数のビットによって指定されているとして解釈するように構成される、請求項１５に記載の装置。
【請求項１７】
前記範囲情報が、前記ポインタ値に対して相対的に指定される、請求項１から１６までのいずれか一項に記載の装置。
【請求項１８】
前記処理回路が、前記ポインタ値に対する変更の結果として、前記範囲情報によって指定された前記範囲が変更されないことを保証するように、前記範囲情報も調節するように前記ポインタ値が変更される作業に対して応答する、請求項１７に記載の装置。
【請求項１９】
前記処理回路によって採用された前記ポインタ値の解釈の前記変更によって、有界ポインタを署名及び無署名化するときに前記範囲情報に対する調節が要求されない、請求項１６に依存するときの請求項１８に記載の装置。
【請求項２０】
前記処理回路が、取外し条件が満たされることを条件に、出力される無署名の有界ポインタを生成するために、入力された署名済み有界ポインタに対して取外し作業を行うよう、取外しリクエストに対して応答し、前記処理回路が、前記取外し条件が満たされるときに、前記署名を前記入力された署名済み有界ポインタの１つ又は複数のビットから判断されたデータで置き換えること、かつ、前記出力される有界ポインタが無署名であることを識別するために、前記関連付けられた属性の中の前記署名情報をクリアすることによって、前記出力される無署名の有界ポインタを生成するように構成される、請求項１から１９までのいずれか一項に記載の装置。
【請求項２１】
（ｉ）前記処理回路が所定の特権状態で動作している、
（ｉｉ）前記処理回路が所定の特権状態で動作しているときにセットできる構成記憶要素が、前記取外し作業が許可されていることを示す値を有する、
（ｉｉｉ）前記取外しリクエストが前記記憶装置に記憶された取外し能力を識別し、前記取外し作業が許可されていることを前記取外し能力が示す、
の条件のうちの少なくとも１つが真である場合に、前記取外し条件が満たされると判断される、請求項２０に記載の装置。
【請求項２２】
前記処理回路が、前記署名作業が行われるのを防ぐために、前記入力された有界ポインタが既に署名済みであることを、前記入力された有界ポインタの前記署名情報から判断することに対して応答するように構成される、請求項１から２１までのいずれか一項に記載の装置。
【請求項２３】
前記処理回路が、命令のセット内の署名命令を実行するときに前記署名作業を行うように構成され、命令の前記セット内の権限付与命令を実行するときに署名済み有界ポインタを無署名化するために、権限付与作業を行うようにさらに構成される、請求項１から２２までのいずれか一項に記載の装置。
【請求項２４】
前記署名命令及び前記権限付与命令のうちの少なくとも１つが、前記署名作業又は権限付与作業に加えて、少なくとも１つのさらなる作業を前記処理回路に行わせる、請求項２３に記載の装置。
【請求項２５】
前記入力された有界ポインタの前記指定されたビットが、前記範囲情報の一部を収め、
前記処理回路が、前記範囲情報によって指定された範囲が、前記範囲情報の残りの部分の中で表せるときに、前記指定された条件が満たされると判断するように構成される
請求項１から１４まで、１７、１８、又は２０から２４までのいずれか一項に記載の装置。
【請求項２６】
有界ポインタの使用を制御する方法であって、
記憶装置に有界ポインタを記憶するステップであって、各有界ポインタはポインタ値と関連付けられた属性とを有し、前記関連付けられた属性は、前記ポインタ値を使用するときのアドレスの許容範囲を示す範囲情報を含む、記憶するステップと、
入力された有界ポインタの指定されたビットの代わりに、出力される有界ポインタの中に署名作業によって生成された署名が収められる、前記出力される有界ポインタを生成するために、前記入力された有界ポインタに対して前記署名作業を行うステップと、
前記出力される有界ポインタが署名されていることを識別するために、前記出力される有界ポインタの前記関連付けられた属性の中に署名情報をセットするステップと、
を含む、方法。
【請求項２７】
有界ポインタを記憶するための記憶手段であって、各有界ポインタはポインタ値と関連付けられた属性とを有し、前記関連付けられた属性は、前記ポインタ値を使用するときのアドレスの許容範囲を示す範囲情報を含む、記憶手段と、
入力された有界ポインタの指定されたビットの代わりに、署名作業によって生成された署名が、出力される有界ポインタの中に収められる、前記出力される有界ポインタを生成するために、前記入力された有界ポインタに対して前記署名作業を行うための処理手段であって、前記出力される有界ポインタが署名されていることを識別するために、前記出力される有界ポインタの前記関連付けられた属性の中に署名情報をさらにセットするための処理手段と、
を備える、装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本技法は、データ処理の分野に関する。
【背景技術】
【０００２】
いくつかのデータ処理装置は、特定のアドレスを示すポインタが、ポインタのアドレスの許容範囲を示す範囲情報と関連付けられる有界ポインタ（ｂｏｕｎｄｅｄ  ｐｏｉｎｔｅｒ）をサポートすることがある。例えば、このようなポインタは、「ファット・ポインタ（ｆａｔ  ｐｏｉｎｔｅｒ）」と呼ばれることがある。
【０００３】
範囲情報に加えて、このような有界ポインタは、ポインタの使用について１つ又は複数の制限／許可を定義する他の関連付けられた属性を有することもある。したがって、このような有界ポインタの使用は、バウンダ・ポインタ（ｂｏｕｎｄｅｒ  ｐｏｉｎｔｅｒ）によって指定されたポインタ値がどのように使用されるかについて制約を課すことによって、強固なセキュリティをもたらすことができる。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】Ｒ  Ｗａｔｓｏｎ、外、「Capability Hardware Enhanced RISC Instructions: CHERI Instruction-Set Architecture」、技術レポート、University of Cambridge Computer Laboratory、第８５０号、UCAM-CL-TR-850、ISSN 1476-2986
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ソフトウェアが直面する１つの問題は、制御フローの整合性（ＣＦＩ：ｃｏｎｔｒｏｌ  ｆｌｏｗ  ｉｎｔｅｇｒｉｔｙ）である。具体的には、例えば、意図された方式以外の方式でプログラム・コードの各部を効果的に縫い合わせるために、意図された分岐挙動を修正しようとすることによって、コンピュータ・プログラムによる制御の意図されたフローを妨害するよう複数の試みが行われることがある。例えば、１つのタスクが、もう１つのタスクによって使用されることになるリターン・アドレスを上書きできる場合、これは、他のタスクを意図されていなかったコードの領域に、その後に分岐させることができる。
【０００６】
有界ポインタを使用するとき、これは、そのポインタから導き出され得るメモリ・アドレスの許容範囲に制約を課し、したがって、ＣＦＩ攻撃中に、１つのタスクが、別のタスクのリターン・アドレスを変化させるように構成される可能性がある場合、有界ポインタの使用は、このリターン・アドレスに対して行われ得る修正を著しく限定することがある。
【０００７】
それにもかかわらず、このような制御フローの整合性への攻撃（ｃｏｎｔｒｏｌ  ｆｌｏｗ  ｉｎｔｅｇｒｉｔｙ  ａｔｔａｃｋ）をさらに阻止することが望ましいであろう。
【課題を解決するための手段】
【０００８】
構成の１つの実例において、有界ポインタを記憶するための記憶装置であって、各有界ポインタはポインタ値と関連付けられた属性とを有し、関連付けられた属性は、ポインタ値を使用するときのアドレスの許容範囲を示す性質をもつ（ｉｎｄｉｃａｔｉｖｅ）範囲情報を含む、記憶装置と、入力された有界ポインタの指定されたビットの代わりに、署名作業によって生成された署名が、出力される有界ポインタの中に収められる、出力される有界ポインタを生成するために、入力された有界ポインタに対して署名作業を行う処理回路と、を備え、関連付けられた属性が、出力される有界ポインタが署名されていることを識別するために、出力される有界ポインタの中に処理回路によってセットされる署名情報を含む、装置が提供される。
【０００９】
構成の別の実例において、有界ポインタの使用を制御する方法であって、記憶装置に有界ポインタを記憶するステップであって、各有界ポインタはポインタ値と関連付けられた属性とを有し、関連付けられた属性は、前記ポインタ値を使用するときのアドレスの許容範囲を示す性質をもつ範囲情報を含む、記憶するステップと、入力された有界ポインタの指定されたビットの代わりに、出力される有界ポインタの中に署名作業によって生成された署名が収められる、出力される有界ポインタを生成するために、入力された有界ポインタに対して署名作業を行うステップと、出力される有界ポインタが署名されていることを識別するために、出力される有界ポインタの関連付けられた属性の中に署名情報をセットするステップと、を含む方法が提供される。
【００１０】
構成のさらなる実例において、有界ポインタを記憶するための記憶手段であって、各有界ポインタはポインタ値と関連付けられた属性とを有し、関連付けられた属性は、ポインタ値を使用するときのアドレスの許容範囲を示す範囲情報を含む、記憶手段と、入力された有界ポインタの指定されたビットの代わりに、署名作業によって生成された署名が、出力される有界ポインタの中に収められる、出力される有界ポインタを生成するために、入力された有界ポインタに対して署名作業を行うための処理手段であって、出力される有界ポインタが署名されていることを識別するために、出力される有界ポインタの関連付けられた属性の中に署名情報をさらにセットするための処理手段と、を有する装置が提供される。
【００１１】
本技法は、添付の図面に示されるように、本技法の実施例を参照しながら、単なる実例として、さらに説明される。
【図面の簡単な説明】
【００１２】
【図１】１つの実施例による、装置のブロック図である。
【図２】有界ポインタ記憶要素のセット内のポインタ値をセット又はアクセスしようと試みる場合に、エラーがトリガされることがある命令のタイプの実例を示す図であり、ここでこのポインタ値は、関連付けられた範囲情報によって示される範囲の外側のアドレスを指定するために使用される。
【図３】１つの実施例による、有界ポインタに関連したタグ・ビット（ｔａｇ  ｂｉｔ）の使用を示す図である。
【図４】１つの実施例による、署名作業及びその後の権限付与作業を概略的に示す図である。
【図５】１つの実施例による、有界ポインタの関連付けられた属性内の署名情報の使用を示す図である。
【図６】１つの実施例による、署名作業を示す流れ図である。
【図７】１つの実施例による、権限付与作業を示す流れ図である。
【図８】有界ポインタの範囲情報が、この有界ポインタのポインタ値に関連して記憶される構成の実例を示す図である。
【図９】１つの実施例による、（署名済み有界ポインタとも呼ばれる）署名済み能力の不変性を保証するために行われる作業を示す流れ図である。
【図１０】１つの実施例による、署名済み能力のポインタ値の変更が許可されるときに実施されることがある一連の作業を示す流れ図である。
【図１１】１つの実施例によって行われる参照先の値を取得する作業を示す流れ図である。
【図１２】１つの実施例による、入力された能力がまだ署名されていない状況に能力署名作業がどのように限定されるかを示す流れ図である。
【図１３】１つの実施例によって行われる取外し作業を示す流れ図である。
【図１４Ａ】取外しが許可されるかどうかを判断するために、いくつかの実施例において行われることがあるチェックの様々な実例を示す図である。
【図１４Ｂ】取外しが許可されるかどうかを判断するために、いくつかの実施例において行われることがあるチェックの様々な実例を示す図である。
【図１４Ｃ】取外しが許可されるかどうかを判断するために、いくつかの実施例において行われることがあるチェックの様々な実例を示す図である。
【図１５】１つの実施例による、代替の署名済み能力の符号化を示す図である。
【図１６Ａ】図１５のアプローチによる、署名が境界情報に追加される実施例において、署名作業を示す流れ図である。
【図１６Ｂ】図１５のアプローチによる、署名が境界情報に追加される実施例において、権限付与作業を示す流れ図である。
【図１７】１つの実施例による、補助記憶装置に保持されるデータから能力を再構築するために使用されることがある再構築処理を概略的に示す図である。
【図１８】１つの実施例によって行われることがある能力再構築処理を示す流れ図である。
【図１９Ａ】このような能力再構築処理の間に、署名が許可しているかどうかを判断するために、いくつかの実施例において行われることがある様々なチェックを示す図である。
【図１９Ｂ】このような能力再構築処理の間に、署名が許可しているかどうかを判断するために、いくつかの実施例において行われることがある様々なチェックを示す図である。
【図１９Ｃ】このような能力再構築処理の間に、署名が許可しているかどうかを判断するために、いくつかの実施例において行われることがある様々なチェックを示す図である。
【発明を実施するための形態】
【００１３】
添付の図を参照しながら実施例を議論する前に、実施例に関する以下の説明が行われる。
【００１４】
いくつかの処理装置は、有界ポインタの使用をサポートすることができる。ポインタ自体は、例えば、アクセスされることになるデータ値のアドレス、又は実行されることになる命令のアドレスを指すことができ、又これらを判断するために使用されてもよい。しかしポインタは、ポインタを使用するときのアドレスの許容範囲を示す、関連付けられた範囲情報を有することもできる。このことは、例えば、セキュリティ、又は挙動の機能的妥当性を維持するために、ポインタから判断されたアドレスが、一定の境界内にとどまることを保証するために有用であることがある。例えば、一定の能力が所与の処理に対して定義され、定義された能力の外側で作業を実行しようと試みる場合にエラーをトリガすることができる、能力に基づくアーキテクチャへの関心が高まっている。有界ポインタのための範囲情報は、このようなアーキテクチャのために定義される能力情報の一部であってよく、能力に基づくアーキテクチャの内部で、このような有界ポインタは（その関連付けられた能力情報を含めて）、能力（ｃａｐａｂｉｌｉｔｙ）と呼ばれることがある。
【００１５】
したがって、装置は、ポインタを使用するときのアドレスの許容範囲を示す性質をもつ関連付けられた範囲情報を有するポインタを記憶するために使用される有界ポインタ記憶要素を有することができる。各有界ポインタ記憶要素は、レジスタ、又は汎用メモリ内の記憶場所、例えばスタック・メモリ上の場所であってよい。
【００１６】
命令の動作中に要求されるメモリ内のアドレスを導き出すために使用されるポインタを取得するために、一定の命令が、このような有界ポインタ記憶要素を参照するために使用されることがある。ポインタは、メモリ・アドレスを識別するために直接、使用されてよく、又例えばオフセットをポインタ値に加えることによって、メモリ・アドレスを導き出すために使用されてもよい。
【００１７】
先に述べられたＣＦＩの問題を考えるとき、上述の、能力に基づくアーキテクチャにおいて使用される有界ポインタなどの、有界ポインタの一定のプロパティは、ＣＦＩ問題をある程度は緩和することができる。例えば、関連付けられた範囲情報は、有界ポインタ記憶要素に記憶されたポインタから宛先アドレスを導き出すときに、分岐命令によって宛先にされる可能性があるアドレスの範囲を限定することができる。能力に基づくアーキテクチャでは、分岐先アドレス（ｂｒａｎｃｈ  ｔａｒｇｅｔ  ａｄｄｒｅｓｓ）を導き出すために、一般的なデータが能力として使用されることを防ぐメカニズムを提供することも知られているが、さらに、一定の能力が維持され得る場所が制限されることがある。しかし、これらの限定の中で、例えば、予期しないプログラム・アドレスに制御が移されることを可能にすることによってコンピュータ・プログラムによる制御の意図されたフローが妨害されることを引き起こすことができるという方法で、不正を働く処理が有界ポインタを操作することがまだ可能である。
【００１８】
したがって、本明細書に説明される技法は、ＣＦＩを改善するために、このような潜在的な誤用に対する障害許容力をさらに改善することを目的とする。
【００１９】
１つの実施例において、有界ポインタを記憶するために使用される記憶装置を有する装置が提供され、各有界ポインタはポインタ値及び関連付けられた属性を有し、関連付けられた属性は、ポインタ値を使用するときのアドレスの許容範囲を示す性質をもつ範囲情報を含む。さらに、有界ポインタが署名されることを可能にするメカニズムが提供される。具体的には、装置内の処理回路は、入力された有界ポインタの指定されたビットの代わりに、出力される有界ポインタの中に署名作業によって生成された署名が収められる、出力される有界ポインタを生成するために、入力された有界ポインタに対して署名作業を行うように構成される。さらに、有界ポインタの関連付けられた属性は、署名情報を含むように構成され、処理回路は、出力される有界ポインタが署名されていることを識別するために、出力される有界ポインタの中に署名情報をセットする。
【００２０】
このような署名作業を採用することによって、次に、署名済み有界ポインタが使用されるのを許される前に署名チェック処理が導入されてよい。署名を生成するために使用された元の情報に内々に関与したエンティティだけが、容易に署名チェック処理に合格でき、したがって、この有界ポインタを使用することを意図していなかったエンティティによる有界ポインタの使用を防ぐことができる。
【００２１】
さらに、例えば、様々なエンティティが、装置上で実行されている種々のタスクである状況を考えると、後でリターン・アドレスとしてタスクＡが使用することになる有界ポインタにタスクＡが署名し、次に、タスクＡによって使用されることになるリターン・アドレスを修正しようとする目的で、この有界ポインタを別のタスクＢが修正しようとする場合、タスクＢがポインタに修正をもたらすことができるとしても、署名作業が行われたときにタスクＡによって使用された情報に、タスクＢは典型的には内々に関与していないので、修正された有界ポインタは、タスクＡによって行われる権限付与処理に後で失敗する可能性が極めて高い。
【００２２】
したがって、これは、ＣＦＩ攻撃に対する著しく高められた障害許容力をもたらす。
【００２３】
その上、上記で説明されたアプローチによれば、有界ポインタの関連付けられた属性は、有界ポインタが署名されているか否かを識別するために使用される。結果的に、入力された有界ポインタに対して作業するために一定の作業が起動されると、入力された有界ポインタが署名済みか否かを判断するために、関連付けられた属性を参照しながらチェックが行われてよく、行われるアクションは、入力された有界ポインタが署名済みか否かに応じて修正されてよい。
【００２４】
このようなアプローチによって、装置は、署名済み有界ポインタに関する限りでは、一定のアクションが行われるのを防ぐように容易に構成されてよく、それによって、さらに高められたセキュリティをもたらす。
【００２５】
具体的には、１つの実施例において、処理回路は、記憶装置内の有界ポインタの使用を要求する少なくとも１つのリクエストされた作業のために、関連付けられた属性の中の署名情報から、この有界ポインタが署名済みであるか無署名であるかを判断すること、及び有界ポインタが署名情報によって署名済みと識別されるか無署名であると識別されるかに応じて、リクエストされた作業に応答して行われるべき処理ステップを判断することを行うように構成される。このようなアプローチによって、無署名の有界ポインタに対して行われ得る作業が署名済み有界ポインタに対して行われるのを許す程度を、処理回路は制御することができる。例えば、このようなアプローチによって、処理回路は、署名済み有界ポインタが修正されるのを禁止することができ、参照先の値を取得する作業の間、即ちメモリ内のアドレスを識別するために有界ポインタのポインタ値が使用される場合に、署名済み有界ポインタの使用を禁止してもよく、既に署名された有界ポインタの署名を禁止すること、他を行ってよい。
【００２６】
あるいは、作業が禁止されない場合、入力された有界ポインタが署名済み有界ポインタであることがわかると、作業に対していくつかの制約がさらに課されることがある。例えば、いくつかの実施例において、署名済み有界ポインタに対していくつかの修正を行うことができる可能性があるが、無署名の有界ポインタに対して行われる修正が必ずしもすべて可能という訳ではなく、したがって、入力された有界ポインタが署名済みであるか無署名であるかを判断するために、入力された有界ポインタの署名情報を使用することによって、リクエストされた作業が適宜制御されてよい。
【００２７】
例えば、１つの実施例において、有界ポインタが署名済みであると判断されると、署名済み有界ポインタは、その関連付けられた属性のうちのいくつかを修正されることが可能であるが、ポインタ値に対するどのような修正も防ぐように構成されてよい。あるいは、上述のように、一定の実装形態において、署名されたままである間は、署名済み有界ポインタに対するどのような修正でも防ぐように判断され得る。
【００２８】
署名済み有界ポインタに対して行われる一定の作業が防がれることが可能ないくつかの方法がある。１つの実施例において、署名済み有界ポインタに対して、許されていないアクションを行おうとする試みが行われるとき、この署名済み有界ポインタを無効化することが決められてよい。あるいは、例えばソフトウェアにおいて例外が行われることといった、障害が引き起こされてもよい。
【００２９】
署名情報は、様々な形式をとることができる。１つの実施例において、署名情報は、有界ポインタが署名済みであることを示すために関連付けられた属性の中にセットされ、有界ポインタが無署名であることを示すために関連付けられた属性の中でクリアされる署名ビットである。したがって、このような実施例において、関連付けられた有界ポインタが署名済みであるか無署名であるかに応じて、セット又はクリアされることになる専用の署名ビットが関連付けられた属性の中に含まれる。セットされた状態を示すために使用される署名ビットの値、及びクリアされた状態を示すために使用される値は、実施例に応じて変えることができ、したがって、１つの実装形態において、値１がセットされた状態を示し、値０がクリアされた状態を示してよい一方で、１つの代替実施例において、値０がセットされた状態を示し、値１がクリアされた状態を示してよいことが理解されよう。
【００３０】
関連付けられた属性の中に専用の署名済みビットを有することに対する代替として、１つの代替実施例において、署名情報は、有界ポインタの少なくとも１つの他のプロパティを識別するためにも使用される複数ビットのフィールド内で符号化されてもよい。いくつかの例において、これは、利用可能な属性空間のさらに効率的な使用をもたらし得る。
【００３１】
いくつかの実施例において、署名作業が行われる可能性があるときに対していくつかの制約を課すことが適正である場合がある。具体的には、１つの実施例において、処理回路は、指定された条件が満たされない限り、署名作業が行われるのを防ぐように構成されてよい。
【００３２】
指定された条件は、様々な形式をとってよいが、１つの実施例において、出力される有界ポインタのその後の無署名化が、元の入力された有界ポインタとは異なる有界ポインタを生成しないことを保証するように構成される。
【００３３】
いくつかの例において、有界ポインタが、署名が挿入されるのを可能にする、符号化中の充分な空き空間を実質的に有していて、有界ポインタに関係があるどのような既存情報も上書きすることなく、有界ポインタが署名を追加するために使用される、符号化時の空間が存在する可能性がある。しかし、１つの代替実施例において、有界ポインタに関する前から存在する情報のうちのいくつかを上書きすることなく、署名が追加されることを可能にするための有界ポインタの符号化中の空きビットが十分にないということがあり得る。このような例において、指定された条件は、入力された有界ポインタの指定されたビット（即ち署名済み版において署名を入れるために使用されるビット）が、入力された有界ポインタの他のビットから再現できる情報を有するとき、指定された条件が満たされるというものである。したがって、このような実施例において、指定されたビットは、ポインタ値の一部又は範囲情報の一部などの有界ポインタの一部を定義する実際の情報を収めてよいが、これらの指定されたビット内の値は、入力された有界ポインタの残りのビットの知識から直接的に再現でき、したがって実質的に冗長であり、この情報を損失することなく署名によって上書きされることが可能である。
【００３４】
対照的に、入力された有界ポインタの指定されたビットが、入力された有界ポインタの他のビットから再現できない情報を有すると判断される場合、１つの実施例において、指定された条件は満たされないと判断され、この例において、処理回路は、入力された有界ポインタが署名されるのを防ぎ、代わりに所定のアクションを行うように構成されてよい。所定のアクションは、様々な形式をとることができるが、例えば、入力された有界ポインタを無効すること、又は例外を行うためにプロセッサ障害を引き起こすことを伴ってよい。
【００３５】
１つの実施例において、処理回路は、有界ポインタが署名されている間、メモリ内でアクセスされることになるアドレスを判断するために有界ポインタが使用されるのを禁止するように構成される。したがって、メモリ・アドレスを生成するために有界ポインタが参照されるとき、有界ポインタが署名済みであるか無署名であるかを判断するために、処理回路は関連付けられた属性の中の署名情報を参照することができ、その後、有界ポインタが署名済み有界ポインタである場合に、有界ポインタが使用されるのを防ぐ。これは、アクセス可能なメモリ・アドレスの生成を防ぐ署名済み有界ポインタ自体の形式に依存する必要なく、高められたセキュリティをもたらす。
【００３６】
署名作業の実行中に署名が生成され得るいくつかの方法がある。１つの実施例において、処理回路は、ポインタ値の少なくとも一部を使用して署名を生成するように構成される。いくつかの実施例において、ポインタ値の全体は、署名を生成するときに使用される。
【００３７】
ポインタ値の少なくとも一部を使用することに加えて、１つの実施例において、処理回路は、署名を生成するときに、署名キー及びコンテキスト・データ（ｃｏｎｔｅｘｔｕａｌ  ｄａｔａ）の項目も使用するように構成される。署名キーは、例えばいくつかの異なるタスクといった装置内のいくつかのエンティティによって知られている可能性があるが、コンテキスト・データの項目は、署名を行わせるエンティティによってのみ、及び任意選択で、１つ又は複数の他の関連したエンティティによってのみ、知られたデータであるように意図され、結果的にこれは、コンテキスト・データのこの項目を保有していないエンティティが、このような署名済み有界ポインタを成功裏に無署名化できる確率を著しく低下させる。
【００３８】
署名済み有界ポインタが無署名化されるように構成されることがあるいくつかの方法がある。１つの実施例において、処理回路は、入力された署名済み有界ポインタの中に収められた署名と、署名済み有界ポインタ内に提供されたポインタ値の少なくとも一部を使用して処理回路によって生成された権限付与署名との間で署名マッチが検出されることを条件に、出力される無署名の有界ポインタを生成するために、入力された署名済み有界ポインタに対して権限付与作業を行うよう、権限付与リクエストに対して応答性がある（ｒｅｓｐｏｎｓｉｖｅ）。
【００３９】
したがって、署名マッチが検出される場合だけ、出力される無署名の有界ポインタが生成される。署名マッチが発生しない場合、入力された署名済み有界ポインタを無効化する、又はプロセッサ障害引き起こすなどの所定のアクションが取られてよい。実装形態の別の実例において、署名マッチがない場合に、入力された署名済み有界ポインタを署名済み有界ポインタのままにすることが適正であると思われることがある。
【００４０】
１つの実施例において、処理回路は、先に述べられた、署名済み有界ポインタ内に提供されるポインタ値の少なくとも一部に加えて、署名キー及びコンテキスト・データの項目を使用して権限付与署名を生成するように構成される。先に述べられたように、署名処理と権限付与処理の両方においてコンテキスト・データの項目を使用することによって、不正なエンティティが、署名済み有界ポインタを成功裏に権限付与する確率を著しく低下させる。
【００４１】
１つの実施例において、署名マッチが検出されるとき、処理回路は、署名を、入力された署名済み有界ポインタの１つ又は複数のビットから判断されたデータで置き換え、及び出力される有界ポインタが無署名であることを識別するために、関連付けられた属性の中の署名情報をクリアすることによって、出力される無署名の有界ポインタを生成するように構成される。このようなアプローチによって、元の無署名の有界ポインタ内のいかなる冗長なデータも実質的に再作成され、したがって、署名済み有界ポインタをその元の無署名の形式に復元する。
【００４２】
先に述べられたように、署名作業中に署名によって置き換えられる入力された有界ポインタの指定されたビットは、様々な形式をとることができるが、１つの実施例において、これらの指定されたビットはポインタ値の一部を収める。このような構成において、処理回路は、ポインタ値のこの一部が、ポインタ値の残りの部分から導き出されるときに、署名作業が行われるのを許す指定された条件が満たされると判断するように構成される。例えば、ポインタ値の一定の数の最上位ビットは実際に、ポインタ値の先立つ最上位ビットの署名拡張された形式になるか、又は代替として、すべて０にセットされる（即ちゼロ拡張された形式になる）ことが多い。このような構成において、ポインタ値の署名拡張された（又はゼロ拡張された）部分の中に署名が置かれる場合、情報の損失を生じることはなく、最終的にポインタ値の署名拡張された形式又はゼロ拡張された形式は後で、署名済みポインタを無署名化するときに復元され得る。したがって、このような条件の下では、指定された条件が満たされ、したがって署名が認められることが識別されてよい。
【００４３】
このような１つの実施例において、有界ポインタが無署名であるとき、処理回路は、ポインタ値を、指定されたビットを含む有界ポインタのデフォルトの複数のビットによって指定されたものとして解釈するように構成され、有界ポインタが署名済みであるとき、処理回路は、ポインタ値を、指定されたビットを除く減少された複数のビットによって指定されたものとして解釈するように構成される。有界ポインタが署名済みであるか無署名であるかに応じて、ポインタ値について異なる解釈を行うことによって、有界ポインタが署名されている間、一定の修正が認められる状況で有界ポインタを処理する際に多少、簡素化することができる。
【００４４】
例えば、１つの実施例において、範囲情報は、ポインタ値に対して相対的に指定されてよい。一定の実装形態において、有界ポインタのための符号化空間はかなり限定され、絶対的な範囲情報を与えるのではなく、ポインタ値に対して相対的な範囲を指定することによって、範囲情報のさらに効率的な符号化が実現される可能性がある。
【００４５】
しかし、このようなアプローチを採用するとき、処理回路は、ポインタ値に対する変更の結果として、範囲情報によって指定された範囲が変更されないことを保証するために、範囲情報も調節するようにポインタ値が変更される作業に対して応答性がある必要がある。具体的には、有界ポインタの範囲情報は、一定のよく制御された状況の下で変更されることだけが可能であること、及びポインタ値に対する全体的な変更が、範囲情報に対するどのような変更も引き起こすべきではないということが望ましい。
【００４６】
しかし、有界ポインタが署名済みであるか無署名であるかに応じて、先に述べられたようにポインタ値に関する種々の解釈を行うことによって、有界ポインタを署名及び無署名化するときの範囲情報を調節する必要性を未然に防ぐ。具体的には、署名済み有界ポインタを作成するとき、署名自体は（縮小されたサイズの）ポインタ値の一部を形成するとは思われず、したがって、ポインタ値を変更するものとはみなされず、したがって、境界情報を調節する必要性を回避する。
【００４７】
いくつかの実施例において、署名済み有界ポインタは、先に述べられた権限付与作業によって変換され、無署名の状態に戻されることだけが可能であるが、１つの代替実施例において、署名済み有界ポインタを無署名の有界ポインタに変換するために、代替メカニズムを提供できることがある。具体的には、１つの実施例において、処理回路は、取外し条件が満たされる場合に、出力される無署名の有界ポインタを生成するために、入力された署名済み有界ポインタに対して取外し（ｓｔｒｉｐ）作業を行うための取外しリクエストに対して応答性があるように構成され、処理回路は、取外し条件が満たされるときに、署名を、入力された署名済み有界ポインタの１つ又は複数のビットから判断されたデータで置き換え、及び出力される有界ポインタが無署名であることを識別するために、関連付けられた属性の中の署名情報をクリアすることによって、出力される無署名の有界ポインタを生成するように構成される。
【００４８】
先に述べられた権限付与作業を行うときに要求される署名マッチを要求しないので、取外し作業はかなり強力なメカニズムである可能性があるということが理解されよう。したがって、１つの実施例において、取外し条件が満たされる状況に対して、取外し作業の使用が制限される。
【００４９】
取外し条件は、様々な形式をとることができる。１つの実施例において、取外し条件は、処理回路が所定の特権状態で動作している場合に満たされると判断される。したがって、取外し作業の使用は、処理回路によって実行される一定の特権的なコードに制限される。
【００５０】
１つの代替実施例において、構成記憶要素（例えば構成レジスタ）は、処理回路が所定の特権状態で動作中にセットできる装置内に設けられてよく、構成記憶要素が、取外し作業が許可されていることを示す値を有する場合に取外し条件が満たされると判断される。したがって、取外し作業の使用は、所定の特権状態によってさらに効果的に制御されるが、構成レジスタが取外し作業の使用を許すことを条件に、処理回路が他の状態にあるときに使用されてよい。
【００５１】
さらなる代替実施例において、取外しリクエストは、それ自体が、記憶装置に記憶された取外し能力を識別してもよい。例えば、取外しリクエストは、入力されたオペランドのうちの１つとして取外し能力を識別し、別のオペランドは、取外し作業が行われることになる署名済み有界ポインタを識別する取外し命令の形をとってよい。次に、識別された取外し能力は記憶装置から取り出され、取外し作業は、取外し作業の実行が許可されることを取外し能力が示す場合に進めることだけが許可される。
【００５２】
３つの異なる実施例において、取外し条件に関する上記の３つのオプションが使用されてよいが、１つの実施例において、これらの条件のうちのいずれか１つ又は複数が満たされる場合に、取外し条件が満たされると判断されるように、これらのうちの複数が一緒に用いられてよい。
【００５３】
１つの実施例において、既に署名済みの有界ポインタに署名することが許可されることがある。しかし、１つの代替実施例において、処理回路は、署名作業が行われるのを防ぐために、入力された有界ポインタが既に署名済みであることを、入力された有界ポインタの署名情報から判断することに対して応答性があるように構成されてよい。したがって、署名情報は、それ自体が、署名作業が行われ得るインスタンスを制御するために使用される。
【００５４】
署名作業が指定され得るいくつかの方法がある。１つの実施例において、処理回路は、命令のセット内の署名命令を実行するときに署名作業を行うように構成される。同様に、処理回路は、命令のセット内の権限付与命令を実行するときに署名済み有界ポインタを無署名化する権限付与作業を行うように構成されてよい。さらに、先に述べられた取外し作業がサポートされる場合、このような取外し作業を実装するために、処理回路によって実行するための命令セット内に具体的な取外し命令が提供されてよい。
【００５５】
これらの追加の命令は、署名作業又は無署名化作業を純粋に行うように構成されてよく、また代替として、署名作業又は無署名化作業に加えて少なくとも１つのさらなる作業を行うように構成されてもよい。
【００５６】
先に述べられたように、１つの実施例において、署名で置き換えられる入力された有界ポインタの指定されたビットは、ポインタ値の一部を収める。１つの代替実施例において、これらの指定されたビットは、範囲情報の一部を収める。このような実施例において、処理回路は、範囲情報によって指定された範囲が、範囲情報の残りの部分の中で表せるときに、指定された条件が満たされると判断するように構成されてよい。これは、情報のいかなる損失もなく、署名を収容するために元々指定されたような、範囲情報の中に充分な冗長性があるという判断によるものであってよい。あるいは、初めに充分な冗長性がなくても、充分な冗長性を作成するために、範囲情報の精度を低下させることができるということが決められてよく、この例において、範囲情報は次に、署名済み有界ポインタ内で、低下した精度で指定される。
【００５７】
これから、図を参照しながら特定の実施例を説明する。
【００５８】
図１は、命令を処理するための処理パイプライン４を備えるデータ処理装置２の実例を概略的に示す。この例において、処理パイプライン４は、フェッチ・ステージ６、デコード・ステージ８、発行ステージ１０、実行ステージ１２、及びライト・バック・ステージ１４を含めたいくつかのパイプライン・ステージを含むが、ステージの他のタイプ又は組合せが設けられてよいということが理解されよう。例えば、いくつかの実施例において、レジスタのリネームを行うためのリネーム・ステージが含まれてよい。処理されることになる命令はステージ間を移動し、命令が１つのステージで保留状態である間、別の命令がパイプライン４の異なるステージで保留状態であってよい。
【００５９】
フェッチ・ステージ６は、レベル１（Ｌ１）命令キャッシュ２０から命令をフェッチする。フェッチ・ステージ６は通常、連続的な命令アドレスから命令を順次にフェッチすることができる。しかし、フェッチ・ステージは、分岐命令の結果を予測するための分岐予測器２２を有してもよく、フェッチ・ステージ６は、分岐が行われると予測される場合には（連続していない）分岐先アドレスから、又は分岐が行われないと予測される場合には次の連続したアドレスから命令をフェッチすることができる。分岐予測器２２は、一定の分岐が行われる可能性があるか否かを予測するための情報を記憶するための１つ又は複数の分岐履歴テーブルを含むことができる。例えば、分岐履歴テーブルは、以前、実行された分岐の実際の結果を追跡するため、又は分岐に対して行われた予測の信頼度を表すためのカウンタを含むことができる。同じ分岐命令に後で遭遇した時に宛先アドレスが予測され得るように、分岐予測器２２は、分岐命令の以前の宛先アドレスをキャッシュするための分岐先アドレス・キャッシュ（ＢＴＡＣ：ｂｒａｎｃｈ  ｔａｒｇｅｔ  ａｄｄｒｅｓｓ  ｃａｃｈｅ）２４を含むこともできる。
【００６０】
フェッチされた命令は、命令をデコードしてデコードされた命令を生成するデコード・ステージ８に渡される。デコードされた命令は、適正な処理作業を実行するために、実行ステージ１２を制御するための制御情報を有することができる。キャッシュ２０からフェッチされたさらに複雑ないくつかの命令に対して、デコード・ステージ８は、これらの命令を、マイクロ・オペレーション（μｏｐｓ又はｕｏｐｓ）として知られることがある複数のデコードされた命令にマップすることができる。したがって、Ｌ１命令キャッシュ２０からフェッチされた命令と、パイプラインのその後のステージでみられるような命令との間に１対１の関連性はなくてもよい。一般に、本出願における「命令」への言及は、マイクロ・オペレーションを含むものとして解釈されるべきである。
【００６１】
デコードされた命令は、命令の実行のために要求されるオペランドが利用できるかどうかを判断し、オペランドが利用できるときに実行のために命令を発行する、発行ステージ１０に渡される。いくつかの実施例は、Ｌ１命令キャッシュ２０から命令がフェッチされたプログラム順に対応する順序で実行に対して命令が発行されるように、イン・オーダー（ｉｎ−ｏｒｄｅｒ）処理をサポートすることができる。その他の実施例は、アウト・オブ・オーダー（ｏｕｔ−ｏｆ−ｏｒｄｅｒ）実行をサポートすることができ、その結果、命令は、プログラム順とは異なる順序で実行ステージ１２に対して発行することができる。初めの方の命令がオペランドを待ちながら停止されている間、オペランドが利用できるプログラム順での後の命令が、最初に実行されることが可能になるので、アウト・オブ・オーダー処理は、パフォーマンスの改善に役立つ可能性がある。
【００６２】
発行ステージ１０は、様々なデータ処理作業を行うために命令が実行される実行ステージ１２に対して命令を発行する。例えば、実行ステージは、整数値に対する算術又は論理演算を行うための算術／論理ユニット（ＡＬＵ：ａｒｉｔｈｍｅｔｉｃ／ｌｏｇｉｃ  ｕｎｉｔ）３０、浮動小数点形式で表される値に対する演算を行うための浮動小数点（ＦＰ：ｆｌａｏｔｉｎｇ−ｐｏｉｎｔ）ユニット３２、及びレベル１（Ｌ１）データ・キャッシュ３６からレジスタ４０にデータ値をロードするためのロード作業、又はレジスタ４０からＬ１データ・キャッシュ３６にデータ値を記憶するための記憶作業を行うためのロード／記憶ユニット３４を含めた、多くの実行ユニット３０、３２、３４を含むことができる。これらは、提供され得る実行ユニットのタイプに関する単なるいくつかの実例にすぎず、他の多くの種類も提供され得るということが理解されよう。処理作業を行うために、実行ステージ１２は、レジスタ４０のセットからデータ値を読み込むことができる。実行された命令の結果は次に、ライト・バック・ステージ１４によってレジスタ４０に書き戻されてよい。
【００６３】
Ｌ１命令キャッシュ２０及びＬ１データ・キャッシュ３６は、複数のレベルのキャッシュを含むキャッシュ階層の一部であってよい。例えば、レベル２（Ｌ２）キャッシュ４４が提供されることもあり、任意選択でさらなるレベルのキャッシュが提供されることもある。この例において、Ｌ２キャッシュ４４は、Ｌ１命令キャッシュ２０とＬ１データ・キャッシュ３６の間で共有されるが、その他の実例は、別々のＬ２命令キャッシュ及びＬ２データ・キャッシュを有することができる。フェッチされることになる命令がＬ１命令キャッシュ２０の中にないとき、命令は、Ｌ２キャッシュ４４からフェッチされてよく、同様に、命令がＬ２キャッシュ４４の中にない場合、命令は、メイン・メモリ５０からフェッチされてよい。同様に、ロード命令に応答して、データは、命令がＬ１データ・キャッシュ３６の中にない場合、Ｌ２キャッシュ４４からフェッチされてよく、必要に応じてメモリ５０からフェッチされてもよい。任意の既知の方式が、キャッシュ階層を管理するために使用されてよい。
【００６４】
プログラム命令及びデータ値を参照するためにパイプライン４によって使用されるアドレスは、仮想アドレスであってよいが、少なくともメイン・メモリ５０、及び任意選択で、少なくともいくつかのレベルのキャッシュ階層も、物理的にアドレス指定されてよい。したがって、パイプライン４によって使用される仮想アドレスを、キャッシュ又はメモリにアクセスするために使用される物理アドレスに変換するために、トランスレーション・ルックアサイド・バッファ５２（ＴＬＢ：ｔｒａｎｓｌａｔｉｏｎ  ｌｏｏｋａｓｉｄｅ  ｂｕｆｆｅｒ）が提供されることがある。例えば、ＴＬＢ５２は、対応するページ内の仮想アドレスを物理アドレスに変換するために、仮想アドレス空間の対応するページの仮想ページ・アドレス、及び仮想ページ・アドレスがマップされるべき、対応する物理ページ・アドレスをそれぞれが指定する、いくつかのエントリを含むことができる。例えば、仮想及び物理ページ・アドレスは、対応する仮想及び物理アドレスのうちの最上位部分に対応してよく、残りの最下位部分は、仮想アドレスを物理アドレスにマップしても、変化しない状態を保つ。アドレス変換情報と同様に、各ＴＬＢエントリは、アドレスの一定のページが、パイプライン４の一定のモードでアクセスできるかどうかを示すなどの、アクセス許可を指定するいくつかの情報を含んでもよい。いくつかの実施例において、ＴＬＢエントリは、読込み又は書出し動作に応答してキャッシュ階層のどのレベルが更新されるか（例えば、ライト・バック又はライト・スルー・モードでキャッシュが動作すべきかどうか）を定義するキャッシュ・ポリシ情報、又はパイプライン４によってデータ・アクセスが発行された順序と比較して、対応するページ内のアドレスへのデータ・アクセスが、メモリ・システムによって並べ替えられてよいかどうかを定義する情報などの、アドレスの対応するページに関するその他のプロパティを定義することもできる。
【００６５】
図１は単一レベルＴＬＢ５２を示すが、レベル１（Ｌ１）ＴＬＢ５２が、最近アクセスされた多くのページ内のアドレスを変換するための複数のＴＬＢエントリを含むことができ、レベル２（Ｌ２）ＴＬＢが、多くのページに対するエントリを記憶するために提供され得るように、複数のＴＬＢの階層が提供されてよいということが理解されよう。要求されたエントリがＬ１  ＴＬＢに存在しないとき、Ｌ２  ＴＬＢから、又は階層内のさらなるＴＬＢから、フェッチされてよい。アクセスされることになるページに対する要求されたエントリがＴＬＢのいずれにもない場合、メモリ５０内のページ・テーブルにアクセスするために、ページ・テーブル・ウォーク（ｐａｇｅ  ｔａｂｌｅ  ｗａｌｋ）が行われてよい。任意の既知のＴＬＢ管理方式が本技法において使用されてよい。
【００６６】
また、例えば、仮想アドレスを中間アドレスに変換するために第１のＴＬＢ（又はＴＬＢの階層）が使用され、次に、１つ又は複数のさらになるＴＬＢを使用する第２レベルのアドレス変換が、中間アドレスを、キャッシュ又はメモリにアクセスするために使用される物理アドレスに変換できるように、いくつかのシステムは、複数レベルのアドレス変換をサポートすることができるということが理解されよう。これは、例えば、第１レベルのアドレス変換がオペレーティング・システムによって管理され、第２レベルのアドレス変換がハイパーバイザによって管理されることがある仮想化をサポートするのに役立つことがある。
【００６７】
図１に示されるように、装置２は有界ポインタ・レジスタ６０のセットを有することができる。有界ポインタ・レジスタのセットは、汎用データ・レジスタ４０のセットとは物理的に別個のものとして図１に示されるが、１つの実施例において、汎用データ・レジスタと有界ポインタ・レジスタの両方を提供するために同じ物理記憶が使用されてよい。
【００６８】
各有界ポインタ・レジスタ６０は、アクセスされることになるデータ値のアドレス、及び対応するポインタ６２を使用するときのアドレスの許容範囲を指定する範囲情報６４を判断するために使用されることがあるポインタ値６２を含む。有界ポインタ・レジスタ６０は、ポインタの使用に関する１つ又は複数の制限／許可を定義することができる制限情報６６（本明細書では許可情報とも呼ばれる）を含むこともできる。例えば制限６６は、ポインタ６２を使用できる命令のタイプ、又はポインタが使用され得るパイプライン４のモードを制限するために使用されてよい。したがって、範囲情報６４及び制限情報６６は、ポインタ６２を使用することが許される能力を定義すると見なされてよい。定義された能力の外側でポインタ６２を使用するという試みが行われると、エラーがトリガされることがある。範囲情報６４は、例えば、ポインタが一定の既知の境界内にとどまり、取扱いに注意を要し又セキュアな情報を収める可能性がある、メモリ・アドレス空間の他のエリアに迷い込まないことを保証するのに有用なことがある。汎用データ・レジスタと有界ポインタ・レジスタの両方に対して同じ物理記憶装置が使用される実施例において、１つの実施例において、ポインタ値６２は、例えば、対応する汎用レジスタに対して使用されるのと同じ記憶位置内に記憶されてよい。
【００６９】
図２は、データ又は命令への不正アクセスから保護するために許容範囲が使用される命令のタイプの実例を示す。図２の上部に示されるように、特定の有界ポインタ・レジスタＰＲ１は、所与のポインタ値６２、並びにこの例において、許容範囲の下限を定義する下限アドレス６８と許容範囲の上限を定義する上限アドレス６９とを使用して指定される範囲情報６４を含む。例えば、アドレスの範囲８００００〜８１０００を定義するように境界６８、６９がセットされる。一定の命令が有界ポインタ・レジスタＰＲ１を参照し、ポインタ６２から判断されるアドレスがこの範囲の外側にあるとき、エラーがトリガされてよい。
【００７０】
例えば、図２の部分Ａに示すように、いくつかのシステムにおいて、ポインタ・レジスタ６０内のポインタ６２の値を、範囲情報６４によって指定された範囲の外側にある値にセットしようと試みる場合、エラーがトリガされてよい（ここで、ポインタがアドレスを直接指定すると想定する）。これは、ポインタを使用するいずれのアクセスも、認められる範囲の中に間違いなくあることが保証され得るように、ポインタ６２が指定範囲の外側のいずれかの値をとることを回避する。あるいは、図２の部分Ｂに示すように、ポインタ６２のアドレスが指定範囲の外側にあるときに、ポインタ６２のアドレスによって識別される場所に命令がアクセスしようと試みるとき、エラーがトリガされてよい。したがって、ポインタ６２を指定範囲の外側の値にセットすることが依然として許容可能であってよいが、このポインタ・アドレス（又はこのポインタから導き出されたアドレス）でのデータ・アクセスが試みられると、このアドレスが許容される範囲の外側にある場合、エラーがトリガされてよい。その他のシステムは、図２の部分Ａ及びＢに示される命令のタイプの両方に応答して、エラーをトリガしてもよい。
【００７１】
範囲情報６４は、異なる方法で設定されてもよい。例えば、セキュアなコード、又はオペレーティング・システム若しくはハイパーバイザが、所与のポインタに認められる範囲を指定することができる。例えば、インストラクション・セット・アーキテクチャは、所与のポインタ６２に対する範囲情報６４をセット又は修正するための多くの命令を含むことができ、これらの命令の実行は、一定のソフトウェア又はプロセッサ４の一定のモード若しくは例外状態に制限されることがある。範囲情報６４をセット又は修正するための任意の既知の技法が使用されてもよい。
【００７２】
ポインタを参照する一定の命令を実行する実行状態１２で使用されることがある有界ポインタ記憶要素６０のセットに加えて、レベル１命令キャッシュ２０から命令がフェッチされているフェッチ・ステージ６で類似の機能を提供するために、プログラム・カウンタ能力（ＰＣＣ：ｐｒｏｇｒａｍ  ｃｏｕｎｔｅｒ  ｃａｐａｂｉｌｉｔｙ）レジスタ８０が使用されてもよい。具体的には、有界ポインタ記憶要素６０のセットにおいてポインタのそれぞれと共に提供される範囲及び制限情報に類似の、範囲情報８４及び任意の適正な制限情報８６もＰＣＣ８０が提供する状態で、プログラム・カウンタ・ポインタがフィールド８２に記憶されてよい。
【００７３】
図３は、個別のデータ・ブロックが、能力（即ち有界ポインタ及び関連付けられた制限情報）を表すか、又は通常のデータを表すかを識別するために、個別のデータ・ブロックと関連して、どのようにタグ・ビットが使用されるかを概略的に示す。具体的には、メモリ・アドレス空間１１０は、典型的には指定されたサイズを有する一連のデータ・ブロック１１５を記憶する。単なる例証のために、この例において、各データ・ブロックが１２８ビットを有すると想定する。各データ・ブロック１１５と関連して、１つの例においてタグ・ビットと呼ばれるシングル・ビット・フィールドである、タグ・フィールド１２０が提供され、タグ・ビットは、関連付けられたデータ・ブロックが能力を表すことを識別するためにセットされ、又は、関連付けられたデータ・ブロックが通常のデータを表し、したがって能力として扱われることがないことを示すためにクリアされる。セットされた状態又はクリアされた状態と関連付けられる実際の値は、実施例に応じて変えることができるが、単なる例証のために、１つの実施例において、タグ・ビットが値１を有する場合、これは、関連付けられたデータ・ブロックが能力であることを示し、タグ・ビットが値０を有する場合、これは、関連付けられたデータ・ブロックが通常のデータを収めることを示すということが理解されよう。
【００７４】
図３に示される能力レジスタ１００などの、（本明細書では能力レジスタとも呼ばれる）有界ポインタ・レジスタ６０のうちの１つに、能力がロードされると、タグ・ビットは能力情報と共に移動する。したがって、能力レジスタ１００に能力がロードされると、ポインタ１０２、範囲情報１０４、及び（以下に許可情報と呼ばれる）制限情報１０６は、能力レジスタにロードされる。さらに、この能力レジスタと関連して、又はこの中の特定のビット・フィールドとして、タグ・ビット１０８は、内容が能力を表すことを識別するためにセットされる。同様に、能力がメモリに戻されて記憶されると、能力が記憶されるデータ・ブロックと関連して、関連するタグ・ビット１２０がセットされる。このようなアプローチによって、能力と通常のデータを区別し、したがって通常のデータが能力として使用され得ないということを保証することができる。
【００７５】
図４は、無署名の能力を署名済み能力に変換するために使用されることがある署名作業、及びその後、署名済み能力を変換して無署名の能力に戻すために使用されることがある対応する権限付与作業を概略的に示す図である。（無署名有界ポインタとも呼ばれる）無署名の能力１５０が、署名作業のための入力オペランドとして提供され、能力１５０は、ポインタ部１５５と属性部１６０を有する。無署名の能力内に提供されるポインタ値の使用が許されることを示す性質をもつ様々な許可情報と共に、ポインタ部１５５にポインタ値が指定され、属性部１６０に範囲情報が指定される。例えば、どのタイプのオペレーションに対してポインタが参照されるのを許すか、したがって、例えば、ロード又は記憶することになるデータを識別するため、フェッチされることになる命令を識別するためなどに、ポインタを使用することができるかどうかを、許可情報は、識別することができる。さらに、先に議論されたように、情報の関連付けられたブロックが能力を表すことを識別するためにセットされるタグ・ビット１６５が提供される。能力のサイズは、実装形態に応じて変えられてよいが、能力が１２８ビットを有する、先に説明された実例と一致してよく、したがって、１つの実施例において、ポインタ部１５５は６４ビット有してよく、属性部１６０も６４ビットを有してよい。
【００７６】
無署名の能力を署名済み能力に変換するために使用される暗号署名機能１７０は、署名済み能力を形成するために追加されることになる署名を導き出すために使用される多くの入力を受け取る。具体的には、機能１７０は暗号署名キーにアクセスでき、さらにソルト値（ｓａｌｔ  ｖａｌｕｅ）にアクセスできる。ソルト値は、様々な形式をとることができるが、１つの実施例において、合法的に署名済み能力を無署名化する必要があり、したがって、署名済み能力に関しては、権限付与作業を正常に行うことができるはずである、１つのタスク又は複数のタスクに対してしか利用できないコンテキスト情報（ｃｏｎｔｅｘｔｕａｌ  ｉｎｆｏｒｍａｔｉｏｎ）を表す。コンテキスト情報は、様々な形式をとることができるが、１つの実施例において、例えば、合法的に署名済み能力に権限付与することを望む１つのタスク又は複数のタスクにしか知られていないスタック・ポインタの場所であってよい。
【００７７】
さらに、機能１７０は、ポインタ部１５５に記憶されるポインタ値の少なくとも一部を受け取る。１つの実装形態において、ポインタ値は、一定数の一意のポインタ・ビットを有することが予期され、残りの最上位ビットは、一意のポインタ・ビットの署名拡張版（したがって、一意のポインタ・ビットのうちの最上位ビットに応じて、全て１若しくは全て０）、又は一意のポインタ・ビットのゼロ拡張版（即ち全て０）である。１つの実施例において、ポインタ値の一定数の最上位ビット内のこの本質的に冗長な情報は、以前に生成された署名を挿入する場所として使用され、これにより、情報のいかなる損失もなく、署名済み能力に署名が組み込まれることを可能にする。１つ代替実施例において、この処理は、例えば、図１５の実施例を参照しながら後で議論されるように、例えば属性部１６０のいくつかのビット内といった、能力の別の部分に署名を挿入するように構成されてよい。実施例のさらなる実例において、無署名の能力内に充分な未使用ビットがあり、署名値を保持するために署名済み能力の中でそれらの未使用ビットを使用することが可能であるということを符号化することがあり得る。
【００７８】
図４に示される実施例において、ポインタ部１５５の上位ビット、具体的には、全て１又は全て０を収めるセクションに、署名が挿入されることが想定される。図４に示される実施例において、ポインタ値の全体が、署名機能１７０への入力として依然として使用され、本明細書でハッシュとも呼ばれる署名を生成するために、このポインタ値、暗号署名キー、及びソルト値を使用して暗号署名機能が行われている。任意の適切な暗号署名機能が、このために使用されることがある。
【００７９】
１つの代替実施例において、この処理は、ポインタ値全体ではなく暗号署名機能１７０への入力として、一意のポインタ・ビットだけが使用されるように構成されてよい。どのアプローチが取られるかに関係なく、署名済み能力の中のポインタ値の上位部分に署名が追加される場合、署名フィールド（即ち、署名で上書きされることになるポインタ値の部分）が、一意のポインタ・ビットの署名拡張版又はゼロ拡張版を収めるように、このポインタが「標準（ｃａｎｏｎｉｃａｌ）」であることを保証するためのチェックを、説明された実施例の処理は行う。これは次に、署名済み能力を作成する有効な署名処理とこれに続くこの署名済み能力の無署名版を作成する有効な権限付与処理が、元の無署名の能力１５０に対応する、結果として生じる無署名版を、もたらすことを保証する。このチェックが行われ得る多くの方法がある。例えば、１つの実施例において、図６の実例を参照しながら後で議論されるように、署名する前にこの条件が真であることを保証するためにチェックが行われる。あるいは、元の能力を権限付与された能力（即ち、署名済み能力を認証した後に作成される能力）と比較するために、署名処理後のテスト認証が機能１７０に組み込まれることがある。
【００８０】
図４に示されるように、署名が作成されると、署名は、署名済み能力１７５の部分１７６のセクション１７９に挿入される。次に、部分１７６のセクション１７７に一意のポインタ・ビットが保持される。許可部分１８０に、能力１７５が署名済み能力であることを識別するためにセットされる署名フィールド１８２が設けられ、さらに、関連付けられた１２８ビットのデータが能力を表すことを示すために、セットされた状態でタグ・ビット１８５が保持される。このことは、別個の署名フィールド１８２を設けることによって、提供された入力された能力が無署名の能力であるか又は署名済み能力であるかに応じて、一定のリクエストされた作業が異なる振舞いをすることを可能にする。このことは、例えば、署名済み能力に関して一定のアクションが行われるのを装置が防ぐことを可能にし、それによってさらに高められたセキュリティをもたらす。
【００８１】
図４の下部に示されるように、署名済み能力１７５を無署名化しようとするために、権限付与機能１９０が起動されてよい。最初に一意のポインタ・ビット１７７が識別され、次に署名機能１７０が実行されたときに使用された元のポインタ値を生成するために、署名拡張作業１９２が行われる。元のポインタ値がゼロ拡張型フォーマットで表された場合、ステップ１９２でゼロ拡張化作業が代わりに行われる。さらに、署名機能１７０への入力として一意のポインタ・ビットだけが使用された場合、署名拡張作業又はゼロ拡張作業はステップ１９２では要求されず、代わりに一意のポインタ・ビットが権限付与署名生成機能１９５に直接、提供されることがある。
【００８２】
図４に示されるように、権限付与署名生成機能１９５は、暗号署名キー及びソルト値にアクセスすることもできる。暗号署名機能１７０によって使用されたのと同じソルト値（即ちコンテキスト情報の同じ項目）に権限付与署名生成機能１９５がアクセスできない限り、署名済み能力のセクション１７９に挿入された署名にマッチする権限付与署名を生成することは、全くありそうにないということが理解されよう。
【００８３】
関連するポインタ・ビット、暗号署名キー、及びソルト値を使用して権限付与署名生成機能１９５によって生成される権限付与署名は次に、比較ブロック１９８に入力され、ここで権限付与署名は、署名済み能力のセクション１７９に保持されている署名と比較される。マッチする場合、権限付与は合格したと考えられ、署名済み能力１７５の無署名版が生成される。そうでなければ、失敗状態が識別され、図７を参照しながら後で実例として議論されるように、所定のアクションが行われる。
【００８４】
権限付与チェックが合格すると想定すると、セクション１７９から署名を削除し、当初のポインタ値を再作成するために、セクション１７７内の一意のポインタ・ビットの署名拡張版（又は実装形態によっては、ゼロ拡張版）で置き換えることによって、無署名の能力が作成される。さらに、現時点で能力が無署名であることを識別するために、署名情報１８２はクリアされる。
【００８５】
署名フィールド１８２は様々な形式をとることができる。図５はアプローチの２つの実例を示す。１つのアプローチによれば、能力が無署名であることを第１の値が示し、能力が署名済みであることを第２の値が示す、専用のシングル・ビットの署名フィールドが提供される。図５に示される実例において、値が論理値１にセットされるとき、これは能力が署名済みであることを示し、その一方で値が論理値０にクリアされる場合、これは能力が無署名であることを示すということが想定される。しかし、種々の実施例において、署名フィールド１８２内の論理値０と論理値１の意味が逆転されてもよいということが理解されよう。
【００８６】
１つの代替実施例において、署名情報に専用ビットを設けるのではなく、署名情報が署名済みか否かに加えて、有界ポインタの少なくとも１つの他のプロパティが識別され得るように、複数ビット型のフィールドが設けられることがある。可能ないくつかの符号化が図５に示される。表すことが望まれ得るその他のタイプの能力は、実施例に応じて明らかに変わる。単なる例証のために、能力が封印された能力であるときを識別するために複数ビット型のフィールドが使用されてよい。例えば、非特許文献１内で議論されているように、能力が使用されるのを防ぐために、能力のロックとして封印が使用されることがある。正しいキー（エンティティをロックし、能力自体として一般に実装されるもの）を有するエンティティだけが、エンティティを開錠することができる。
【００８７】
表される可能性がある３つ以上の異なるタイプの能力が存在する状況において、複数ビット型のフィールドを使用することによって、能力の利用可能な属性空間内で、さらに効率的な符号化につなげることができる。
【００８８】
図６は、１つの実施例による、署名作業を示す流れ図である。ステップ２００において、例えば、プロセッサが署名命令を実行することによって能力の署名がリクエストされる。その後、ステップ２０５において、署名によって上書きされることになるポインタのビットが識別される。図４の実例の通り、識別されたビットは、一意のポインタ・ビットの署名拡張版であるポインタ値の上位ビットである。
【００８９】
ステップ２１０において、次に、識別されたビットの全てが、ポインタの残りの部分のうちの最上位ビットと同じ値を有するかどうか、即ち識別されたビットの全てが、本当に一意のポインタ・ビットの署名拡張版であるかどうかが判断される。先に述べられたように、１つ代替実施例において、ゼロ拡張型フォーマットが使用されることがあり、この場合、ステップ２１０において、識別されたビットの全てがゼロであるかどうかが判断される。
【００９０】
ステップ２１０において、識別されたビットの全てが、必要な条件を満たさない、即ち図６の実例において、ポインタの残りの部分のうちの最上位ビットと同じ値を有さないビットがあると判断される場合、所定のアクションが行われるステップ２３５に処理は進む。所定のアクションは様々な形式をとることができるが、１つの実施例において、さらなる処理を取り扱うために例外が行われるように、プロセッサ障害を起こすことを伴ってよい。あるいは、例えば、実質的に能力が汎用データに変換され、もはや能力として使用されることがないようにタグ・ビットをクリアすることによって、識別された入力能力は無効化されてよい。ステップ２１０を実行し、条件が満足されないときにステップ２３５に進むことによって、無署名の能力を署名し、その後署名済み能力に権限付与する行為が、元の無署名の能力にマッチしない、結果として生じる無署名の能力を生み出すことがあるという可能性、即ち図４の実例において、署名及び無署名化の処理が、潜在的に異なるポインタ値を作成することから保護する。
【００９１】
署名し、その後権限付与する行為がポインタ値を変更しないことが重要であるが、署名し、権限付与する行為が、例えば、範囲情報によって指定された範囲を変更すること、又は能力に対して指定された許可を変更することといった、能力と関連付けられた権利を変更することができないということも重要である。１つの特定の実施例において、能力の中の符号化空間の制限のために、ポインタ値に関連して範囲情報が指定され、結果として、合法的にポインタ値が変更されると、範囲情報を適宜再符号化するために処理が行われる必要があるように構成されてよい。このような環境のなかで、署名し、権限付与する行為がポインタ値を変更できる場合、範囲情報も変更され、したがって能力と関連付けられた権利を変更することもあるので、署名し、権限付与する行為がポインタ値を変更させることがないということを保証することが明らかにさらにいっそう重要である。
【００９２】
ステップ２１０におけるチェックが合格し、したがってポインタ値の残りの部分のうちの最上位ビットと同じ値を、識別されたビットの全てが有すると判断されると想定すると、処理はステップ２１５に進み、ここでポインタ値、署名キー、ソルト値から署名が作成される。その後、ステップ２２０において、図４を参照しながら先で議論されたように、ポインタの識別されたビットは署名と置き換えられ、ステップ２２５において、署名属性フィールド１８２は、能力が署名されたことを示すためにセットされる。その後、ステップ２３０において、例えば能力レジスタ６０のうちの１つに記憶するために、署名済み能力は出力されてよい。
【００９３】
図７は、１つの実施例によって行われる権限付与処理を示す流れ図である。ステップ２５０において、例えば、プロセッサが権限付与命令を実行することによって、署名済み能力の権限付与がリクエストされる。ステップ２５５において、次に、一意のポインタ・ビットのサイズが識別される。これは、権限付与処理を行うために正しいビットが使用されることを保証するのに重要である。１つの実施例において、一意のポインタ・ビット部分のサイズは固定されてよく、したがって変化しない。１つ代替実施例において、ポインタ値の中の一意のポインタ・ビット部分のサイズは、例えば、所定の特権レベルで実行するソフトウェアによって、ソフトウェア制御の下でグローバルに構成されてよい。さらなる実例において、一意のポインタ・ビット部分のサイズは、特定の状況に依存することがあり、やはりソフトウェア制御の下で現在の状況に依存する値でセットされてよい。権限付与は典型的には、関連付けられた署名作業のために使用されたのと同じ状況で行われる。必要に応じて、権限付与を進められるように、この条件が満たされることを確認するためにチェックが行われてよい。
【００９４】
ステップ２５５に続いて、ステップ２６０において、一意のポインタ・ビットが抽出され、その後これらは、ステップ２６５において、完全なポインタ値を形成するために署名拡張される。先に述べられたように、ゼロ拡張型フォーマットが無署名ポインタ内で使用された場合、抽出されたビットは、ステップ２６５においてゼロ拡張されるであろう。
【００９５】
ステップ２７０において、ポインタ値、署名キー、及びソルト値から権限付与署名を作成するために、権限付与署名生成機能１９５が行われる。その後、ステップ２７５において、署名済み能力に設けられた署名に権限付与署名がマッチするかどうかが判断され、マッチしない場合、所定のアクションが行われるステップ２９５に処理は進む。所定のアクションは、様々な形式をとることができる。例えば、例外を行うためにプロセッサ障害が起こされてよく、又例えばタグ・ビットをクリアすることによって、署名済み能力が無効化されてもよい。さらなる実例の構成において、能力を署名済みのままにし、したがって権限付与処理を完了させないように判定されもよい。次に、能力のその後の使用が無署名の能力を使用することを予期しているが、その時点で能力がまだ署名済みであるので、能力のいかなるその後の使用も失敗することが予期される。
【００９６】
ステップ２７５において、権限付与署名が署名済み能力内の署名にマッチすると判断される場合、権限付与処理は合格したと見なされ、ステップ２６５で縮小されたサイズのポインタから導き出された署名拡張されたビットで能力内の署名が置き換えられるステップ２８０に処理は進む。さらに、ステップ２８５において、能力が無署名であること示すために、署名属性情報はクリアされ、その後ステップ２９０において、例えば能力レジスタ６０のうちの１つに記憶するために、無署名の能力が出力される。
【００９７】
先に述べられたように、１つの実施例において、範囲情報は絶対的に指定されてよく、したがってポインタ値へのどのような変更も、それ自体、範囲を変更しないが、１つの代替実施例において、例えば符号化空間が能力内で制約される場合、範囲を指定するために能力内に記憶されることになる情報の量を縮小するように、範囲情報はポインタに対して相対的に指定されてよい。このような構成は、例えば図８に示される。具体的には、範囲情報を形成するために、２つのオフセット３０５、３１０が指定されてよく、これらは、ポインタから基底へのオフセット及びポインタから限界へのオフセットを識別し、したがって範囲３１５の両端の識別を可能にする。次に、範囲３１５の広がりを識別するために、ポインタ値３００及び関連するオフセット情報を使用して限界判断処理３０７、３１２が行われてよい。これは、範囲情報を指定するのに要するビットの数の低下をもたらすことができるが、ポインタの調節の結果として範囲が変更されないことを保証するために、ポインタ値が変更されると、範囲情報を調節する必要が生じる。
【００９８】
署名済み能力のフィールド１８２内に署名情報をもたせることによって、入力された能力が署名済みか署名済みでないかを容易に識別し、能力が署名済みか署名済みでないかに応じて、プロセッサを様々に動作させることができる。これは、例えば、署名済み能力が使用される方法に一定の制限が課されることを可能にするが、能力が無署名である状況では、このような制限が課されることはない。図９は、署名済み能力の不変性が強制される１つの実例オプションを示す。したがって、ステップ３５０において、指定された入力された能力のいくつかの態様をリクエストするための変更がリクエストされると想定される。例えばこれは、例えば能力レジスタ６０のうちの１つを参照して入力された能力を指定し、能力の一部が修正されるようにする命令の一種である命令の形をとってもよい。ステップ３５５において、識別された入力された能力が取り出され、能力が署名済みか無署名かを署名属性情報が示すかどうかを確かめるために署名属性情報は見直される。能力が無署名である場合、ステップ３５０で受け取られたリクエストにしたがって、通常の能力修正処理が行われるステップ３６０に処理は進む。しかし、指定された入力された能力が署名済みであると判断される場合、代わりに、所定のアクションが行われるステップ３６５に処理は進む。例えばこれは、プロセッサ障害が引き起こされるか、又は入力能力が無効化されることがある。さらなるオプションとして、能力を、署名済みだが無修正のままにしておくと判定されてもよい。しかし、いくつかの例において、これは、修正挙動が誤っていたということの何らかの直接の指示が望まれることがあるので、適切なオプションではないと見なされることがある。
【００９９】
署名済み能力を不変にすることによって、２つの強固なプロパティを生み出す。第１に、能力が署名済みである間、能力に対して変更が行われることがないので、不正を働くエンティティは、より権限付与しやすい異なる形式に署名済み能力を変更しようとすることができない。さらに、境界情報がポインタ値に対して相対的に指定されることがある状況において、署名済み能力を修正しようとするどのような試みも、障害、又は能力の無効化を引き起こすので、署名済み能力を変更することを暗示する可能性を考慮する必要がない。
【０１００】
署名済み能力全体を不変にすることに対する代替として、代わりに、署名済み能力内の一定のフィールドが不変になるように構成されてよく、したがって、ステップ３５０でリクエストされた変更のタイプ、具体的には、修正されることになる署名済み能力のフィールドに応じて、チェック３５５が行われてよい。
【０１０１】
図１０は、図９に対する代替オプションを示し、ここで、署名済み能力、具体的にはポインタ値に対する変更が許される。ここで、ステップ３７０において、ポインタ値に対する変更がリクエストされる。ステップ３７２において、指定された入力能力の署名属性から、この能力が署名済みであるかどうかが判断される。署名済みでない場合、完全なサイズ、即ち図４の実例による完全な６４ビットであると、ポインタ値が解釈されるステップ３７４に処理は進み、ステップ３７６において、ステップ３７０で受け取られたリクエストに従って、完全なサイズのポインタ値は調節される。この例において、図８を参照しながら先に議論された構成によって、境界情報がポインタ値に対して相対的に指定されると想定し、したがってポインタ値自体を調節することに加えて、ステップ３７８において、完全なサイズのポインタの変更を考慮に入れるために境界情報（即ち範囲属性）を調節する、境界調節作業が行われる。
【０１０２】
しかし、ステップ３７２において、入力された能力が署名済みであると署名属性から判断される場合、ポインタ値に対する異なる解釈が行われる。具体的には、ステップ３８０において、縮小サイズ、即ち挿入された署名のサイズを完全なサイズから差し引いたサイズを有するものとしてポインタ値は解釈される。無署名の能力内でポインタ値が解釈されるのとは異なって署名済み能力内でポインタ値を解釈することによって、能力を署名するとき、及び後で能力を無署名化するときに、境界情報の変更が必要になるのを避ける。対照的に、ポインタ値が依然として完全なサイズであると見なされたなら、ポインタ・フィールドのうちの最上位ビットに挿入された署名のビットは、ポインタ値を実質的に変え、署名が挿入される（したがって、ポインタ値に対する第１の変更を引き起こす）とき、及びその後署名が削除される（したがって、ポインタ値に対する別の変更を引き起こす）権限付与処理中、の両方において、これらに応じて境界情報を調節しようとすることが必要になったであろう。能力が署名済みのときにポインタ値の異なる解釈を使用することによってこれらの複雑化は回避され、能力内の署名属性情報１８２を使用して能力が署名済みであるか又は無署名であるかを識別することによって、これらの２つの異なる解釈の使用は容易に実装でき、したがって署名済み能力と無署名の能力をプロセッサが容易に区別することを可能にする。
【０１０３】
図１０に戻ると、ステップ３８２において、縮小サイズのポインタ値に対するリクエストされた変更が、利用可能な縮小サイズ内にポインタを保つかどうか、即ちオーバーフロー条件がないかどうかが判断される。オーバーフローする場合、処理はステップ３８８に進み、ここで先に述べられた、プロセッサ障害を引き起こすこと、又は能力を無効化することなどの所定のアクションが行われる。しかし、リクエストされた変更が縮小サイズのポインタ内に収容できる、と想定されると、ステップ３８４において縮小サイズのポインタは調節され、次に、ステップ３８６において、縮小サイズのポインタの変更を考慮に入れるために境界情報が調節される。
【０１０４】
関連付けられた属性内の署名済み情報の使用を通じて、署名済み能力と無署名の能力とをプロセッサが容易に区別できるようにすることによって、指定された入力された能力が署名済みか又は無署名かに応じて、他のタイプのオペレーションをプロセッサが調節できるようにする。例えば、図１１に示されたような１つの実施例において、署名済み能力の参照先の値を取得することは禁止され、したがって、アクセスされることになるメモリ・アドレスを識別するためには署名済み能力は使用されることはないということを保証する。具体的には、ステップ４００において、能力から参照先の値を取得するためにリクエストが受け取られる。例えばこれは、アクセスされることになるメモリ・アドレスを導き出すために指定された入力された能力を識別する、ロード命令又は記憶命令を実行することによって生じることがある。ステップ４０５において、指定された能力が署名済みであるか、又は無署名であるかが、署名属性情報から判断される。署名済みでない場合、処理は単にステップ４１０に進み、ここで、ポインタから導き出されたメモリ・アドレスが、能力によって指定された境界の範囲内にあること、及びリクエストされたアクセスのタイプが、能力の許可属性によって許されることを前提に、能力内のポインタ値は、メモリにアクセスするために標準的な手法で使用される。
【０１０５】
しかし、ステップ４０５において、入力された能力が署名済みであると判断される場合、ステップ４１５において、例えばプロセッサ障害を引き起こすこと又は能力を無効化することといった、所定のアクションが行われる。
【０１０６】
ステップ４１５に対する代替オプションとして、ポインタ値フィールド全体からメモリ・アドレスを導き出せるようにすることを適正であると見なし、最上位ビットに署名を組み込むことによって、メモリ内の誤ったアドレスをポインタが識別することを保証するように構成して、したがってメモリ・アクセスを失敗させるようにしてもよい。しかし、ポインタ値のうちの最上位ビットを指定する署名が誤ったアドレスを識別するポインタ値の使用に依存するので、他の実装形態においてこのようなアプローチはセキュリティの所望レベルをもたらさないと判断されることがある。
【０１０７】
図１２は、指定された入力された能力が署名済みであるか又は無署名であるかということに、行われる処理が依存する可能性がある、別のタイプの作業を示す流れ図である。具体的には、図１２の実施例によれば、例えば、入力された能力を識別する署名命令が実行されることによって能力署名処理が起動される。ステップ４２５において、署名属性情報を参照することによって、入力された能力が既に署名済みであるかどうかが判断される。署名済みでない場合、例えば先に説明された図６のアプローチを使用して、ステップ４３０で通常の能力署名処理が行われてよい。しかし、ステップ４２５において、能力が既に署名済みであると判断される場合、代わりに、例えば障害条件をトリガすること又は能力を無効化することによって、ステップ４３５で所定のアクションが行われてよい。別の代替オプションは、元の署名情報を有する署名済み能力として、能力を保持することであってよい。
【０１０８】
結果的に、能力に関する関連付けられた属性の中の署名情報を使用することによって、署名作業を行うときに、署名済み能力と無署名の能力とを区別することができ、したがって必要に応じて、署名済み能力が再署名されるのを防ぐことができる。１つ代替実施例において、署名済み能力を再署名できるように決められることがあり、したがって図１２の処理は使用されないであろう。
【０１０９】
１つの実施例において、署名済み能力を無署名化するただ１つの方法は、図７を参照しながら先に議論された、能力を無署名化できるようにする前に署名マッチチェック処理が要求されるもののような権限付与処理を使用することになる可能性があるが、別の実施例では、一定の状況で署名済み能力を無署名化できるようにするために、追加機能が提供されることがある。具体的には、署名マッチチェックを行うことなく、一定の条件の下で、署名済み能力を無署名の能力に変換することを許可する、取外し（ｓｔｒｉｐ）機能が提供されてよい。このような処理が、図１３に実例として示される。
【０１１０】
具体的には、ステップ４５０において、例えば、入力された能力を指定して取外し命令を実行することによって、署名済み能力の取外しがリクエストされる。ステップ４５５において、取外しが許可されるかどうかが判断されるが、このステップは、図１４Ａ〜図１４Ｃの実例を参照しながら後でさらに詳細に議論される。取外しが許可されない場合、例えば、プロセッサ障害を引き起こすこと、能力を無効化すること、又は能力を署名済みのままにしておくことによって、ステップ４９０で所定のアクションが行われる。
【０１１１】
取外しが許可される場合、ステップ４６０において、一意のポインタ・ビットのサイズが識別され、その後ステップ４６５で一意のポインタ・ビットが抽出され、完全なポインタ値を形成するために、ステップ４７０で署名拡張される。ステップ４６０、４６５、４７０は、権限付与処理を説明したときに、図７を参照しながら先に議論されたステップ２５５、２６０、２６５と本質的に同じである。
【０１１２】
次に、ステップ４７５、４８０、及び４８５は、図７のステップ２８０、２８５、及び２９０に対応し、能力内の署名を署名拡張されたビットで置き換えること、署名属性情報をクリアすること、及び結果として生じる無署名の能力を出力すること、を行わせる。図１３と図７の比較からわかるように、取外しが許可される場合、いかなる権限付与署名を作成することも、権限付与が署名済み能力内の署名にマッチするかどうかをチェックすることも、行う必要がない。
【０１１３】
したがって、取外し機能は潜在的に強力なツールであり、したがって、１つの実施例において、取外し機能の使用を一定の所定の状況に制限することが適正であると見なされることが理解されよう。取外し機能の使用に対して課されることがあるいくつかの制限の実例が、図１４Ａ〜図１４Ｃに提示される。最初に図１４Ａを考えると、ステップ５００において、署名済み能力の取外しがリクエストされると想定する。このような状況では、ステップ５０５において、所定の高い特権状態でプロセッサが動作しているかどうかが判断される。所定の高い特権状態は実施例に応じて様々な形式をとることができるが、例えば仮想マシン・タイプの環境を考えると、所定の高い特権状態は、ハイパーバイザのレベルであってよい。プロセッサが、所定の高い特権状態で動作していないと判断される場合、処理はステップ５１５に進み、ここで障害が発生する、即ち図１３のステップ４９０において識別された所定のアクションのうちの１つが行われる。しかし、プロセッサが所定の高い特権状態にある場合、図１３のステップ４５５から「はい」の経路をたどることによって、ステップ５１０で取外し機能が行われる。
【０１１４】
図１４Ｂは代替アプローチを示し、ここでステップ５２０、５３０、及び５３５は、図１４Ａのステップ５００、５１０、及び５１５に対応するが、テスト５０５はテスト５２５によって置き換えられ、具体的には、特権的な構成レジスタが、取外しを許すようにセットされたかどうかが判断される。特権的な構成レジスタは、例えば、所定の特権状態で動作しているときにプロセッサによってセットできるレジスタであってよく、したがってこの値は、この所定の特権状態で動作しているプロセッサによって修正することしかできない。取外しが許されていることを構成レジスタの内容が示していると想定すると、ステップ５３０で取外し機能が行われるが、そうでなければ、ステップ５３５で障害が引き起こされる。
【０１１５】
図１４Ｃは、取外し能力（ｓｔｒｉｐ  ｃａｐａｂｉｌｉｔｙ）が定義される別の代替アプローチを示す。先に述べられたように、能力は、プロセッサに対して利用できる権利のセットを実質的に識別し、ほとんどの能力が、先に説明された有界ポインタの形式をとってよいが、全ての能力が有界ポインタである必要があるわけではない。代わりに、能力は、特定の機能に関連して一定の権利を識別するにすぎないと定義されてよい。したがって、例えば、能力レジスタ６０のうちの１つに保持され、取外し動作のための入力として指定されることがある取外し能力が定義されてよい。したがって、取外し命令は、例えば、そのオペランドのうちの１つとして取外し能力を、及び別のオペランドとして、それが取外すことをリクエストしている能力を、識別することができる。このような構成において、署名済み能力の取外しがリクエストされたことが判断されるステップ５４０に続いて、ステップ５４５において、取外し命令によって識別された取外し能力が、関連する能力レジスタから取り出され、その内容を判断するために分析される。次に、ステップ５５０において、識別された署名済みポインタを取り除くことを、取外し能力が許すかどうかが判断される。許す場合、ステップ５５５で取外し機能が行われるのに対して、そうでない場合、ステップ５６０で障害が引き起こされる。
【０１１６】
１つの実施例において、取外し能力は、取外しが許可されるかどうかを識別することのみに専用の能力であってよいが、１つの代替実施例においては、能力レジスタ６０に保持される単一の能力が、そのうちの１つは取外し許可であるいくつかの許可を識別することができる。
【０１１７】
先に議論されたような装置の中で、プロセッサによって実行できる命令セットは、いくつかの能力命令、即ち１つ又は複数のオペランドとして能力を具体的に識別する命令を含むことができる。例えば、先に説明された署名機能、権限付与機能、及び取外し機能をサポートするために、以下の３つの命令が提供されてよい。
ＣＳＩＧＮ  −  能力を署名済み能力に変換する。（発信元及び宛先として能力レジスタ、並びに任意選択のコンテキスト情報、例えばソルト値）
ＣＡＵＴＨ  −  成功裏に権限付与が行われることを条件として、署名済み能力を無署名の能力に変換する。（発信元及び宛先として能力レジスタ、並びに任意選択のコンテキスト情報、例えばソルト値）
ＣＳＴＲＩＰ  −  権限付与処理を行うことなく、署名済み能力を無署名の能力に変換する。（発信元及び宛先として能力レジスタ）
【０１１８】
これらの実例のそれぞれにおいて、発信元及び宛先の能力レジスタは、２つの異なる能力レジスタであってよく、又代替として、発信元及び宛先として同じレジスタが指定されてもよく、したがって、無署名の能力を署名済み能力で上書きさせ、又は逆もまた同様である。
【０１１９】
署名機能、権限付与機能、及び取外し機能のために専用命令を提供することに加えて、さらに必要に応じて、このような機能は他の機能と組み合わされてよい。例えば、１つの実施例において、権限付与処理をロード作業及び分岐作業とそれぞれ組み合わせるために、以下の２つの命令が提供されることがある。
ＣＬＤＲＡ  −  （能力レジスタからの）署名済み能力を、成功裏に権限付与が行われることを条件として、無署名の能力に変換し（能力レジスタ内では署名済み能力を無変化のままにしてよい）、ポインタを使用して、項目（能力又はデータ）をレジスタにロードするメモリ・アドレスを識別する。
ＣＢＲＡ  −  （能力レジスタからの）署名済み能力を、成功裏に権限付与が行われることを条件として、無署名の能力に変換し（能力レジスタ内では署名済み能力を無変化のままにしてよい）、ポインタを使用して、プログラム・カウンタ値の更新を判断する。
【０１２０】
したがって、このような機能によって、能力を署名済みとして保持するが、能力を別のオペレーションの一部として無署名化することができ、したがって、作業の残りを行うときに、無署名化された変形物をその後使用できるようにする一方、能力レジスタに元の署名済み能力を保持することができる。これは、署名済み能力を使用して動作するコードに一定の性能改善をもたらすことができる。
【０１２１】
先の実例において、ポインタ値の一定数の最上位ビットに署名が追加されることを想定した。しかし、１つの代替実施例において、代わりに、例えば境界情報の中といった属性フィールドの一部に署名が追加されてもよい。これは実例として図１５に示される。図１５の実例において、無署名の能力はポインタ部６００と、境界セクション６０５及び許可セクション６１０を含む属性部とを含む。タグ・ビット６１５も設けられ、これは、関連付けられた内容が汎用データではなく能力を表すことを識別するためにセットされる。能力が署名されるとき、この実例では、ポインタ値は変化しないままであり、代わりに、ハッシュ・フィールド６２５によって示されるように、境界情報のために利用できる空間の一部に署名が挿入される。これは、図１６Ａを参照しながら後でさらに詳細に議論されるように、縮小サイズ境界フィールド６２０をもたらす。先の実例の通りに、署名属性フィールド６３２も設けられ、能力が署名されたことを示すようにセットされ、修正された許可セクション６３０をもたらす。関連付けられた情報がまだ能力であることを識別するために、タグ・ビット６１５はセットされた状態に保たれる。
【０１２２】
このようなアプローチからの１つの潜在的な利益は、ポインタが署名処理によって変更されないということであり、したがって、境界情報がポインタに対して相対的に指定される状況では、境界情報に対して潜在的な効果がない。さらに、署名拡張されたビット又はゼロ拡張されたビット、即ち実質的に冗長な情報を収める、ポインタ値の充分な数の最上位ビットがなくても、このようなアプローチが使用されてよい。しかし、このようなアプローチによれば、署名の挿入に対応するために、境界情報に充分な冗長情報が存在する必要がある。
【０１２３】
図１６Ａは、署名が境界情報に追加される状況における署名処理を示す流れ図である。ステップ６５０において、例えば署名命令の実行によって、能力の署名がリクエストされ、その後ステップ６５５において、署名を入れるために境界情報のビットに充分な冗長性があるかどうかが判断される。例えば、境界情報が基底値及び限界値の指定を有し、これらの値の両方が、これらの上位ビットに一定量の冗長情報を有するという場合かもしれない。これらの上位ビットが、情報のどのような損失もなく署名を組み込むのに充分である場合、署名を入れるために、境界情報に充分な冗長性があると判断される。いくつかの例においては、こうでないとしても、充分な冗長性を作り出すために境界情報の精度を低下させ、したがって元の境界情報を、境界情報の低下させた精度のセットで置き換え、そして署名のために充分な空間を解放することができる可能性がある。
【０１２４】
ステップ６５５において、署名を入れるために、境界情報に充分な冗長性がないと判断される場合、例えば、プロセッサ障害を引き起こす又は入力された能力を無効化するといった、所定のアクションが行われるステップ６８０に処理は進む。
【０１２５】
しかし、充分な冗長性があると想定されると、ステップ６６０において、ポインタ値、署名キー、及びソルト値から署名が作成され、その後ステップ６６５において、境界情報の中の識別された冗長ビットが署名と置き換えられる。さらにステップ６７０において、能力が署名されたことを示すために、署名属性情報がセットされ、次にステップ６７５において、例えば能力レジスタ６０のうちの１つに記憶するために、署名済み能力が出力される。
【０１２６】
図１６Ｂは、署名が境界情報に追加される場合に行われる、対応する権限付与処理を示す流れ図である。ステップ７００において、署名済み能力に権限付与するリクエストが受け取られ、その後ステップ７０５において、ポインタ、署名キー、及びソルト値から権限付与署名が作成される。図１６Ｂを図７と比較することによって、ポインタ全体が使用される可能性があり、署名作業による影響を受けなかったので、一意のポインタ・ビットを識別する必要がないということが理解されよう。
【０１２７】
ステップ７１０において、権限付与署名が署名済み能力内の署名にマッチするかどうかが判断され、マッチしない場合、ステップ７３０で所定のアクションが行われ、これらは、図７のステップ２９５を参照して先に議論された所定のアクションに対応する。
【０１２８】
権限付与署名が署名済み能力内の署名にマッチすると想定すると、ステップ７１５において、署名は冗長な境界情報で置き換えられる。これは、例えば、１つの実施例において、署名のために以前使用されたこれらのビットに全てゼロ値を記憶することを伴ってよい。
【０１２９】
さらに、ステップ７２０において、現時点で能力が無署名であることを識別するために署名属性情報がクリアされ、次にステップ７２５で無署名の能力が出力される。
【０１３０】
例えば図３を参照しながら先に議論されたように、メモリと能力レジスタの間で能力が移されると、メモリに記憶されたデータの関連付けられたブロックが実際は能力であることを識別するために、能力と共にタグ・ビットが移動する。しかし、いくつかの実装形態において、例えばメモリに能力情報の全てを保持するのに充分なスペースがないために、又は休止状態をサポートするときに、能力をメモリからディスクなどの補助記憶装置に記憶することが必要な場合がある。１つの実施例において、これは、各能力を別々のデータ及びタグ部分に分解し、タグを補助記憶装置内のデータとして扱うことを伴う。これは図１７に概略的に示され、ここで、図３を参照しながら先に説明されたアプローチにしたがって、能力レジスタ８００とメモリ８０５の間で能力が移されると、各データ・ブロック８１０と共にタグ・ビット８１５が移動する。したがって、メモリ８０５の中のデータの各ブロックは、能力又は汎用データを表すものとして識別されることができる。データ・ブロックが補助記憶装置８２５に移されると、能力をデータ８２４及びタグ情報８２２に分解するために分解処理８２０が使用され、タグ情報はデータとして扱われる。したがって、補助記憶装置内では、情報はデータとして存続するにすぎず、補助記憶装置は能力に気づかない。
【０１３１】
補助記憶装置に記憶されたデータから能力を再構築するとき、補助記憶装置内の一般的なデータから能力を構築することしかできなかったとしたら、能力の使用を通じて利用できるセキュリティは損なわれてしまう可能性があるであろうから、再構築処理は制約される必要がある。具体的には、能力が作成されることを作業がリクエストし、この能力を形成するために補助記憶装置内のデータを識別するとき、識別されているデータが、もし能力に変換されたならば、プロセッサが所有する権利がある能力を形成することをチェックする処理が導入されることが望ましい。
【０１３２】
１つの実施例において、これは、本明細書では総合能力（ｇｅｎｅｒａｌ  ｃａｐａｂｉｌｉｔｙ）とも呼ばれるマスタ能力（ｍａｓｔｅｒ  ｃａｐａｂｉｌｉｔｙ）を参照しながら能力を再構築する再構築作業８３０を行うことによって実現される。具体的には、１つの実施例において、総合能力は、任意の許された能力が総合能力から導き出されることを可能にするのに充分な情報をもたらす。したがって、有界ポインタの形の能力を考えると、再構築作業８３０が、この総合能力から許容有界ポインタを生成することしかできないように、総合能力８３５は指定される。
【０１３３】
能力を再構築するために使用される処理は様々な形式をとることができるが、１つの実施例において、補助記憶装置８２５から取り出された指定されたデータを参照しながら、総合能力に対して精錬処理を行うように、プロセッサは構成される。したがって、能力再構築作業が起動され、補助記憶装置８２５の中のデータのブロック及びタグ・データの関連付けられた項目（これらは、１つの実施例において、データが次にプロセッサによって操作されることを可能にするために、補助記憶装置から１つ又は複数のレジスタにその時点で移されてよい）を識別し、この情報を使用して、作業８３０は、結果として生じる能力がこの識別されたデータにマッチするように、マスタ能力を精錬しようとすることができる。これが可能な場合、これは、識別されたデータが実際に能力を表すことができ、したがって処理８３０がこのデータと関連してタグ・ビットをセットし、メモリ８０５に記憶するために能力としてタグ・ビットを出力できるということを示す。１つの実施例において、この時点で能力をそれから生成するために使用されたデータは、マスタ能力の精錬版であってよく、又代替として、補助記憶装置から取り出されたデータであってもよい。どちらの場合でも、このステージにおいて、関連するデータは典型的には、レジスタに保持されるので、記憶作業は、例えば、能力をレジスタからメモリ８０５に記憶するために使用されることができる。
【０１３４】
しかし、マスタ能力に関して行われる精錬処理が、指定されたデータにマッチする能力をもたらすようになされない場合、これは、補助記憶装置からのデータが、能力を識別するために使用されることはないことを示し、障害が引き起こされる。
【０１３５】
有効な能力と関連付けられることがある利用可能な許可及び範囲の全ての上位集合を実質的に表すために、マスタ能力８３５が使用され得るが、署名済み能力の問題を考えるとき、マスタ能力の精錬から署名を導き出すことができないということが理解されよう。１つの実施例において、一定の制御された条件の下、補助記憶装置からのデータの使用が、再構築された能力内に署名を形成することを可能にすること、したがって再構築処理８３０が署名済み能力を再作成することも可能にすることによって、この問題は対処される。このプロセスは、図１８の流れ図を参照しながら、さらに詳細に議論される。
【０１３６】
具体的には、ステップ８５０に示されるように、再構築処理が起動されると、この再構築処理のために識別されたデータが補助記憶装置から取り出される。１つの実施例において、取り出されたデータは、１つ又は複数の作業レジスタに記憶される。例えば、能力を潜在的に表すことがあるデータ・ブロック部分（即ち、先に議論された実施例における１２８ビットのデータ）は、能力レジスタ８００のうちの１つに記憶されてよいが、タグ・ビットが有効な能力を（現在のところ）表すものではないことを示すために、タグ・ビットはクリアされる。さらに、タグ・ビットを示す性質をもつ、補助記憶装置から取り出されたデータのビットは、汎用レジスタに記憶されてよい。その後、ステップ８５５において、タグ情報を形成するデータ・ビット（即ち、今、汎用レジスタに記憶されたビット）が、このデータが能力を形成することになるということを示すかどうかが判断される。示さない場合、処理は単にステップ８５７に進み、ここで、取り出されたデータは、能力レジスタからメモリ８０５に出力されてよく、データ・ブロックが汎用データであることを識別するために、タグ・ビットはクリアされる。
【０１３７】
しかし、取り出されたデータが能力を形成することになることを、タグ情報を形成するデータ・ビットが示す場合、ステップ８６０において、取り出されたデータを使用して、マスタ能力の許可及び境界を狭くし、ポインタ値もセットすることで、マスタ能力のコピーを精錬しようとするために、精錬処理が起動される。この精錬処理は様々な方法で実装されてよいが、１つの実施例において、（例えば一連の精錬命令を実行することによる）反復処理であってよいということが理解されよう。
【０１３８】
ステップ８６５において、補助記憶装置から取り出された元のデータが、能力が署名済みになることを示すかどうかが判断される。例えば、能力の関連付けられた属性内の署名情報を表すであろう、データ内の関連するフィールドは、このフィールドがセットされるか又はクリアされるか、したがって、データが能力に変換された場合に、署名済み能力又は無署名の能力をデータが表すかどうかを確かめるために見直されてよい。ステップ８６５の結果として、作成されることになる能力が無署名であると判断される場合、処理はステップ８６７に進み、ここで、マスタ能力８３５の精錬によって、要求された能力が正常に作成され得るかどうかが判断される。１つの実施例において、この条件は、マスタ能力に関して行われる精錬処理が、補助記憶装置から取り出されたビットと同じ値を有する一連のビットを生じ、したがって、補助記憶装置から取り出されたデータが有効な能力を表すことができることを示す場合に合格すると見なされる。この場合、処理はステップ８９５に進み、ここで、（典型的にはこの時点でレジスタ内にある）マスタ能力の精錬版と関連してタグ・ビットをセットすることによって、能力が作成され、次に、例えば適切な記憶作業を行うことによって、（データ・ブロックが実際に能力であることを識別するためにセットされたタグ・ビットを維持して）メモリ８０５に能力が出力される。１つの代替実施例において、能力は、補助記憶装置から取り出されたデータのコピーから、メモリ８０５に出力する前にタグ・ビットがセットされて、この時点で生成されてよい。
【０１３９】
上記のステップ８９５は、様々な方法で実装されてよい。例えば、能力を形成するために使用されるデータが一時的に記憶される発信元（能力）レジスタ、並びに生成された能力が記憶され、それを能力として識別するためにタグ・ビットがセットされることになる宛先能力レジスタを識別するために、「ＳｅｔＴａｇ」命令が実行されてよい。１つの実施例において、発信元レジスタと宛先レジスタは同じレジスタであってよい。「ＳｅｔＴａｇ」命令の１つの変形形態において、（例えば、ステップ８８５、８９０を参照しながら、以下で議論されるように）結果として生じる能力を生成するときに、２つの発信元レジスタの両方が参照される可能性があるので、実質的に２つの発信元レジスタ、即ちステップ８６０から生じるマスタ能力の精錬版を収めるレジスタ、及び補助記憶装置から取り出される未加工のデータを収めるレジスタがあってよい。
【０１４０】
次に、能力をレジスタからメモリに記憶するために、別個の記憶命令が実行されてよい。
【０１４１】
ステップ８６７において、マスタ能力の精錬によって、能力を正常に作成することができないと判断される場合、代わりに、障害が発生するステップ８７０に処理は進む。例えば、例外が行われるように、プロセッサ障害が引き起こされてよい。別のオプションとして、データが一時的に取り出された能力レジスタ８００にデータが保持されてよいが、データを能力ではなく汎用データとして識別するために、タグ・ビットがクリアされた状態で維持される。別の代替は、例えば、条件フラグをセットすることによって、又はテスト及び分岐命令によってチェックを受けることができる汎用レジスタ内に値を置くことによって、効率的にテストできるプロセッサ条件をセットすることであろう。
【０１４２】
ステップ８６５において、能力が署名済みになることを元のデータが示すと判断される場合、先に述べられたように、マスタ能力の精錬によって署名を生成することができない。したがって、署名済み能力が再構築されることになる場合、少なくとも、署名を表すデータが能力に直接的にコピーされることを可能にすることが必要になろう。
【０１４３】
したがって、ステップ８６７の代わりに、処理はステップ８６９に進み、ここで、能力の署名済みの性質、具体的には署名と署名属性情報に関する部分以外の能力の全ての部分が、マスタ能力の精錬によって成功して作成され得るかどうかが判断される。作成されない場合、ステップ８７０で障害が引き起こされる。しかし、そうでなければ処理はステップ８７５に進み、ここで、再構築中に署名が許可されるかどうかが判断される。図１９Ａから図１９Ｃを参照しながら後で議論されるように、このステージで行われてよいいくつかの可能なチェックがあるが、補助記憶装置から取り出されたデータを使用して能力に直接的に署名することが認められる状況に対して、一般にいくつかの制約が課されることが予想される。ステップ８７５において、再構築中に署名することが許可されないと判断される場合、ステップ８８０で障害が引き起こされる。ステップ８８０で利用できるオプションは、例えば、ステップ８７０で利用できるオプションに対応してよい。あるいは、ステップ８８０に達する場合、障害を生成する代わりに、無署名の能力として能力が生成されてよい。
【０１４４】
再構築中に署名することが許可されると判断される場合、署名は、補助記憶装置から取り出された一連のビットに対応するように識別され、ステップ８８５において、例えば、先に議論された図４のアプローチが使用される場合の、ポインタ値の一定数の最上位ビットといった、生成された能力を形成することになるデータの識別された部分に挿入される。
【０１４５】
さらに、生成された能力の属性部に署名属性情報が設けられることになる場合、（ステップ８９０によって示されるように）この署名属性情報は、生成された能力を形成することになるデータのさらに識別された部分にセットされ、この能力が生成されるときに能力が署名済み能力であることを示す。その後、処理はステップ８９５に進み、ここで、能力が、タグ・ビットが、関連付けられたデータ・ブロックを能力であると識別するためにセットされて、生成され、メモリに出力される。
【０１４６】
ステップ８９５において、マスタ能力の精錬版から能力が生成される場合、ステップ８８５及び８９０において、この精錬版を一時的に保持するレジスタは、補助記憶装置から取り出された未加工のデータの関連部分で更新される。代わりに、補助記憶装置から取り出されたデータのコピーから能力が生成される場合、未加工のデータのこれらの関連部分が、マスタ能力の精錬版から外れることを実質的に可能にし、したがって、ステップ８８５及び８９０によって定義される挿入及びセット機能を実装するのは、ステップ８８５及び８９０である。
【０１４７】
先に説明された実施例において、署名済み能力は、関連付けられた能力を、署名済み又は無署名であると識別するために、署名属性フィールドを含むが、図１７及び１８を参照しながら議論された一般的な再構築処理は、このような追加の署名情報が属性フィールド内に提供されるかどうかに関わらず実装され得るということに留意されたい。したがって、このような署名属性フィールドが使用されない場合でも、補助記憶装置に保持されたデータから能力を再構築するときに、補助記憶装置から取り出されたデータを使用して、関連する署名を挿入することによって署名済み能力を生成するために、説明された処理が依然として使用され得る。
【０１４８】
図１９Ａ〜図１９Ｃは、図１８のステップ８７５における再構築中に署名が許可されるかどうかを判断するために行われることがある様々なチェックを示す。図１９Ａ〜図１９Ｃの図１４Ａ〜図１４Ｃとの比較から明白なように、１つの実施例において、これらのチェックは、署名済み能力が取り外されるのを許すかどうかを判定するために行われることがあるチェックに似ている。したがって、図１９Ａを考えると、ステップ９００において再構築中の署名がリクエストされると、ステップ９０５において、所定の高い特権状態で現在、プロセッサが動作しているかどうかが判断されてよく、高い特権状態で動作している場合、ステップ９１０で署名が挿入されるのを許すことになる一方で、そうでなければ、ステップ９１５で障害が引き起こされる（ステップ９１５は、図１８のステップ８８０に対応する）。
【０１４９】
図１９Ｂへの代替アプローチによれば、ステップ９２０、９３０、及び９３５は、図１９Ａのステップ９００、９１０、及び９１５に対応するが、判定９０５は、判定９２５によって置き換えられ、ここで、特権的な構成レジスタが、署名が挿入されるのを許すようにセットされているかどうかがチェックされる。この特権的な構成レジスタは典型的には、プロセッサが少なくとも１つの所定の特権状態で動作しているときにプロセッサによって書込むことしかできない。
【０１５０】
図１９Ｃの代替の実例によれば、能力レジスタ６０のうちの１つに例えば記憶されることがある署名能力（ｓｉｇｎｉｎｇ  ｃａｐａｂｉｌｉｔｙ）が提供される。この署名能力は、補助記憶装置に保持されたデータから能力を再構築する間、署名が許可されるかどうかを識別する情報を提供する。したがって、ステップ９５０において再構築中の署名がリクエストされると、本実施例によれば、関連した署名能力が識別され、署名能力の内容が分析されるのを可能にするために、ステップ９５５でこの署名能力が取り出される。例えば、汎用データから能力を再構築する間に署名の挿入を開始するために署名挿入命令が使用されてよく、署名能力は、この署名挿入命令のオペランドとして識別されてよい。一旦、適切な署名能力が取り出されると、次にステップ９６０において、署名が挿入されるのを署名能力が許すかどうかが判断され、許す場合、補助記憶装置に保持されたデータを使用して署名が挿入されるステップ９６５に処理は進む。そうでなければ、ステップ９７０で障害が引き起こされる。
【０１５１】
図１９Ａ〜図１９Ｃのオプションは択一的と見なされてよいが、いくつかの実施例において、これらは、任意のテストが満たされる場合に、署名の挿入が許可されるものと見なされるように、組み合わせて使用されてよい。
【０１５２】
図１８の処理は、様々な方法で実装されてよい。例えば、これはハードウェア内に実装されてよく、ここでハードウェアは、図１８において識別されたステップの全てを行うために、再構築処理を開始する単一の命令に応答する。あるいは、処理は、図１８の再構築処理を実装する一連の命令を使用することによってソフトウェアに実装されてよい。後者のアプローチによれば、補助記憶装置からの、取り出された未加工のデータの関連するデータ・フィールドを１つずつ検査すること、境界、許可、他をセットするためにマスタ能力を精錬すること、及び精錬されたマスタ能力をメモリに書き出すこと、を行うために、例えば一連の命令が実行されてよい。
【０１５３】
図１７〜図１９の再構築処理は、様々な状況で使用される可能性がある。例えば、ページング・システム・タスクなどのタスクＡは、さらなるタスク（タスクＢ）のための能力を、タスクＢに制御を渡す前にセットアップするために、（総合能力８３５へのこのアクセスのおかげで）充分な能力を有することができるものであってよい。ページング・システム・タスクは、図１７〜図１９の処理を採用することによって、要求された能力を作成することができ、これらの能力を共有メモリに記憶し、その後これらの能力は次にタスクＢに割り振られてよい。これは、能力再構築処理がどのように使用されてよいかについての単なる１つのシナリオの実例であることが理解され、補助記憶装置内のデータから能力を再構築できることが有用になる他のシナリオもあることが理解されよう。
【０１５４】
上記で説明された技法の使用を通じて、能力の使用によってもたらされる強固なセキュリティは、署名済み能力を生成するために署名作業を使用することによって、さらに高められる可能性があることが理解されよう。例えば、署名機能を能力と組み合わせることによって、能力によってもたらされる本来のセキュリティは、不正を働くエンティティが制御フローの整合性をくぐり抜けようとする可能性をさらに減らすために、さらに高められる。
【０１５５】
本出願において、用語「〜を行うように構成される（ｃｏｎｆｉｇｕｒｅｄ  ｔｏ）」は、定義された作業を行うことができる構成を装置の要素が有することを意味するために使用される。これに関連して、「構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）」は、ハードウェア又はソフトウェアの相互接続の構成又は手法を意味する。例えば、装置は、定義された作業を提供する専用のハードウェアを有してよく、又は、プロセッサ又はその他の処理デバイスは、機能を実行するようにプログラムされてもよい。「を行うように構成される（Ｃｏｎｆｉｇｕｒｅｄ  ｔｏ）」は、定義された作業を提供するために、装置要素がなんらかの方法で変更される必要があることを含意しない。
【０１５６】
本発明の例証的な実施例が添付の図面を参照しながら本明細書で詳細に記述されたが、本発明は、これらの正確な実施例に限定されないということ、並びに様々な変更、追加、及び修正は、添付の特許請求の範囲によって定義されるような本発明の範囲及び精神から逸脱することなく、当業者によって本発明の中で行われてよいということを理解されたい。例えば、従属請求項の特徴の様々な組合せが、本発明の範囲から逸脱することなく、独立請求項の特徴と共に行われてよい。
【図１】
2019505052.tif 000003
【図２】
2019505052.tif 000004
【図３】
2019505052.tif 000005
【図４】
2019505052.tif 000006
【図５】
2019505052.tif 000007
【図６】
2019505052.tif 000008
【図７】
2019505052.tif 000009
【図８】
2019505052.tif 000010
【図９】
2019505052.tif 000011
【図１０】
2019505052.tif 000012
【図１１】
2019505052.tif 000013
【図１２】
2019505052.tif 000014
【図１３】
2019505052.tif 000015
【図１４Ａ】
2019505052.tif 000016
【図１４Ｂ】
2019505052.tif 000017
【図１４Ｃ】
2019505052.tif 000018
【図１５】
2019505052.tif 000019
【図１６Ａ】
2019505052.tif 000020
【図１６Ｂ】
2019505052.tif 000021
【図１７】
2019505052.tif 000022
【図１８】
2019505052.tif 000023
【図１９Ａ】
2019505052.tif 000024
【図１９Ｂ】
2019505052.tif 000025
【図１９Ｃ】
2019505052.tif 000026
【国際調査報告】
2019505052.tif 000027
2019505052.tif 000028
2019505052.tif 000029