(57)【要約】  命令セット内の変更を制御するための装置及び方法が提供される。装置は命令セットの命令を実行するための処理回路を有し、処理回路は命令を実行する際処理回路によって実施される動作を制約するために使用される機能を備える機能ドメインで動作するように構成される。プログラムカウンタ値を決定するために処理回路によって使用されるプログラムカウンタ機能を格納するためのプログラムカウンタ機能格納要素が使用される。処理回路は命令セットを変更するために機能ベースのメカニズムを採用するように構成される。特に、特定される機能をプログラムカウンタ機能格納要素にロードするために使用される少なくとも１つのタイプの命令の実行に応答して、処理回路は特定される機能に関して機能チェック動作を実施するために、また機能チェック動作が成功したとすれば、命令セットを特定される機能からの命令セット識別子フィールドによって特定させるために、機能ベースのメカニズムを呼び出すように構成される。これは命令セットを変更させる制御されるメカニズムを提供し、それにより命令セットを変更しようとする不注意による又は悪意のある試行のリスクを軽減する。
2020523680.tif 000002
【特許請求の範囲】
【請求項１】
命令セットの命令を実行するための処理回路であって、前記命令を実行する際に前記処理回路によって実施される動作を制約するために使用される機能を備える機能ドメインにおいて動作するように構成される処理回路と、
プログラムカウンタ値を決定するために前記処理回路によって使用されるプログラムカウンタ機能を格納するための、プログラムカウンタ機能格納要素と
を備える装置であって、
前記処理回路は、特定される機能を前記プログラムカウンタ機能格納要素にロードするために使用される少なくとも１つのタイプの命令の実行に応答して、前記命令セットを変更するために機能ベースのメカニズムを採用するように構成され、前記処理回路は前記特定される機能に関して機能チェック動作を実施するために、また前記機能チェック動作が成功したとすれば、前記命令セットを前記特定される機能からの命令セット識別子フィールドによって特定させるために、前記機能ベースのメカニズムを呼び出すように構成される、
装置。
【請求項２】
前記処理回路は、前記特定される機能について、前記特定される機能を前記プログラムカウンタ機能格納要素にロードすることに先立って、前記機能チェック動作を実施するように構成される、請求項１に記載の装置。
【請求項３】
前記処理回路は、前記特定される機能について、前記特定される機能を前記プログラムカウンタ機能格納要素にロードした後、前記機能チェック動作を実施するように構成される、請求項１に記載の装置。
【請求項４】
前記処理回路は、前記機能チェック動作の失敗を検出することに応答して例外を取るように構成される、請求項１から３までのいずれか一項に記載の装置。
【請求項５】
前記処理回路は、前記機能チェック動作の失敗を特定するためにフラグをセットするように構成され、次の命令が実行される際前記フラグをセットすることにより前記例外を取らせる、請求項４に記載の装置。
【請求項６】
前記処理回路は、前記特定される機能を指定する分岐命令を実行することによって、前記機能ベースのメカニズムを呼び出すように構成される、請求項１から５までのいずれか一項に記載の装置。
【請求項７】
前記処理回路からアクセス可能であり、前記命令を実行する際前記処理回路によって実施される動作を制約するために使用される機能を格納するように構成される、１つ又は複数の機能格納要素
をさらに備え、
前記分岐命令は前記１つ又は複数の機能格納要素のうちの１つをソースオペランドとして指定し、前記指定された機能格納要素は前記特定される機能を含む、
請求項６に記載の装置。
【請求項８】
前記分岐命令は、前記特定される機能を形成するリターンアドレス機能を前記プログラムカウンタ機能格納要素にロードするために実行されるリターン命令を含む、請求項６又は７に記載の装置。
【請求項９】
前記処理回路は、前記機能チェック動作を実施する際、前記特定される機能が有効な機能でない限り前記機能チェック動作が成功することを妨げるために、前記特定される機能に関連付けられる有効フラグをチェックするように構成される、請求項１から８までのいずれか一項に記載の装置。
【請求項１０】
前記特定される機能は、前記特定される機能に関連付けられる１つ又は複数のパーミッションの状態を特定するために使用されるより多くのパーミッションフラグのうちの１つを含み、
前記処理回路は、前記機能チェック動作を実施する際、少なくとも１つのパーミッションが所定の状態でない限り前記機能チェック動作が成功することを妨げるために、前記１つ又は複数のパーミッションフラグをチェックするように構成される、請求項１から９までのいずれか一項に記載の装置。
【請求項１１】
前記少なくとも１つのパーミッションは、前記特定される機能が、前記プログラムカウンタ機能として使用される場合、メモリから命令をフェッチするための前記特定される機能の使用を妨げるあらゆるオーバーライド制御情報にしたがって、メモリから命令をフェッチするために使用できるかどうか、また前記所定の状態が前記特定される機能がメモリから命令をフェッチするために使用できることを示すセット状態かどうか、を特定するために使用される実行可能なパーミッションを含む、請求項１０に記載の装置。
【請求項１２】
前記少なくとも１つのパーミッションは、前記特定される機能が１つ又は複数の機能修正命令によって修正可能かどうか、また前記所定の状態が前記機能が前記１つ又は複数の機能修正命令によって修正不可能であることを示すクリア状態かどうかを特定するために使用される修正可能なパーミッションを含む、請求項１０又は１１に記載の装置。
【請求項１３】
前記機能チェック動作が成功する場合、前記処理回路は前記命令セット識別子フィールドを含む前記特定される機能を使用して、前記プログラムカウンタ機能格納要素内に新しいプログラムカウンタ機能を形成するように構成され、
前記新しいプログラムカウンタ機能内の前記命令セット識別子フィールドの値は、前記命令セットを決定するために使用される、請求項１から１２までのいずれか一項に記載の装置。
【請求項１４】
前記機能チェック動作が成功する場合、前記処理回路は前記特定される機能を使用して前記プログラムカウンタ機能格納要素内に新しいプログラムカウンタ機能を形成するように構成されるが、前記命令セット識別子フィールドに対応する前記新しいプログラムカウンタ機能内のフィールドはデフォルト値にセットされ、前記処理回路はさらに前記特定される機能の前記命令セット識別子フィールド内の前記値を命令セット制御記憶要素に書き込み、
前記命令セット制御記憶要素内の前記値は前記命令セットを決定するために使用される、
請求項１から１２までのいずれか一項に記載の装置。
【請求項１５】
前記命令セット制御記憶要素は現在のプロセッサ状態レジスタ（ＣＰＳＲ）内のフィールドによって与えられる、請求項１４に記載の装置。
【請求項１６】
前記処理回路は前記命令セットを変更するために例外ベースのメカニズムをさらに提供し、前記例外ベースのメカニズムを呼び出すと、前記処理回路は、信頼されたソフトウェアが前記例外からリターンする際使用される前記命令セットを特定するリターン状態を確立するために実行される予め定義された状態へ例外を取るように構成される、請求項１から１５までのいずれか一項に記載の装置。
【請求項１７】
前記処理回路は、前記機能ベースのメカニズム又は前記例外ベースのメカニズムのいずれかを使用して前記命令セットを変更のみできるように制約される、請求項１６に記載の装置。
【請求項１８】
現在の命令セットの命令を実行するための処理回路であり、前記命令を実行する際に前記処理回路によって実施される動作を制約するために使用される機能を備える機能ドメインにおいて動作するように構成される処理回路を有する装置内で命令セット内の変更を制御する方法であって、前記方法は
プログラムカウンタ機能格納要素内に、プログラムカウンタ値を決定するために前記処理回路によって使用されるプログラムカウンタ機能を格納することと、
前記処理回路が、特定される機能を前記プログラムカウンタ機能格納要素にロードするために使用される少なくとも１つのタイプの命令の実行に応答して、前記現在の命令セットの変更を制御するために機能ベースのメカニズムを呼び出すように構成することであって、前記機能ベースのメカニズムは、
前記特定される機能に関して機能チェック動作を実施することと、
前記機能チェック動作が成功したとすれば、前記特定される機能からの命令セット識別子フィールドによって前記命令セットを特定させることと
を含む、構成することと
を含む、方法。
【請求項１９】
命令セットの命令を実行するための処理手段であって、前記命令を実行する際前記処理手段によって実施される動作を制約するために使用される機能を備える機能ドメインにおいて動作するための処理手段と、
プログラムカウンタ値を決定するために前記処理手段によって使用されるプログラムカウンタ機能を格納するための、プログラムカウンタ機能格納要素手段と
を備える装置であって、
前記処理手段は、特定される機能を前記プログラムカウンタ機能格納要素にロードするために使用される少なくとも１つのタイプの命令の実行に応答して、前記命令セットを変更するために機能ベースのメカニズムを採用し、前記処理手段は前記特定される機能に関して機能チェック動作を実施するために、また前記機能チェック動作が成功したとすれば、前記命令セットを前記特定される機能からの命令セット識別子フィールドによって特定させるために、前記機能ベースのメカニズムを呼び出す、
装置。
【請求項２０】
請求項１から１７までのいずれか一項に記載の装置に対応する命令実行環境を提供するためのホストデータ処理装置を制御するためのプログラム命令を含む、仮想マシンコンピュータプログラム。
【請求項２１】
請求項２０に記載の前記仮想マシンコンピュータプログラムを記憶するコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本技法はデータ処理の分野に関する。
【背景技術】
【０００２】
所与の処理についてある機能が定義され、定義された機能以外の動作を実行するような試行があるとエラーをトリガすることができる機能ベースのアーキテクチャに対する興味が高まっている。機能は様々な形態を取ることができるが、機能の１つのタイプは結合ポインタ（「ファットポインタ」とも称され得る）である。
【０００３】
装置の処理回路が一連の命令を実行するように構成される場合、機能を使用してそれらの命令を実行する際に処理回路によって実施される動作を制約することができる。例えば、そのような手法によって、一定の機能に関連付けられる範囲及びパーミッション情報を考慮してメモリアクセスが制約されることを保証することにより、処理回路によってなされるメモリアクセスを効果的に取り締まることが可能である。そのような手法はメモリ内でアクセスされるデータだけではなく、命令が実行のために取り出され得るアドレス範囲を制約するために使用することができる。
【０００４】
いくつかのプロセッサは、異なる命令セットからの命令を実行することができ、それに応じて、制御情報は現在の命令セットを特定するために維持され得、この時その制御情報は、異なる命令セットの実行へ動作をスイッチするよう決定される場合、変更される。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、機能ベースのアーキテクチャ内では、命令セットを変更するための能力は、機能の使用を通じて達成可能なセキュリティ上の有益性のうち一部を潜在的に低下させることがある。特に、命令セットを変更することは、メモリからフェッチされた命令データの解釈を変え、ひいてはメモリ内に保持されている読み取り専用コードの解釈を変えることがある。機能ベースのシステム内で命令セットを変更するような不注意による又は悪意のある試行の可能性を軽減することが望ましいであろう。
【課題を解決するための手段】
【０００６】
第１の実例の構成において、提供される装置は、命令セットの命令を実行するための処理回路であって、前記命令を実行する際に処理回路によって実施される動作を制約するために使用される機能を備える機能ドメインにおいて動作するように構成される処理回路と、プログラムカウンタ値を決定するために処理回路によって使用されるプログラムカウンタ機能を格納するための、プログラムカウンタ機能格納要素とを備え、処理回路は、特定される機能をプログラムカウンタ機能格納要素にロードするために使用される少なくとも１つのタイプの命令の実行に応答して、命令セットを変更するために機能ベースのメカニズムを採用するように構成され、処理回路は特定される機能に関して機能チェック動作を実施するために、また機能チェック動作が成功したとすれば、命令セットを特定される機能からの命令セット識別子フィールドによって特定させるために、機能ベースのメカニズムを呼び出すように構成される。
【０００７】
別の実例の構成において、提供される方法は、現在の命令セットの命令を実行するための処理回路であり、前記命令を実行する際に処理回路によって実施される動作を制約するために使用される機能を備える機能ドメインにおいて動作するように構成される処理回路を有する装置内で命令セット内の変更を制御する方法であって、方法はプログラムカウンタ機能格納要素内に、プログラムカウンタ値を決定するために処理回路によって使用されるプログラムカウンタ機能を格納することと、処理回路が、特定される機能をプログラムカウンタ機能格納要素にロードするために使用される少なくとも１つのタイプの命令の実行に応答して、現在の命令セットの変更を制御するために機能ベースのメカニズムを呼び出すように構成することであって、前記機能ベースのメカニズムは、特定される機能に関して機能チェック動作を実施することと、機能チェック動作が成功したとすれば、特定される機能からの命令セット識別子フィールドによって命令セットを特定させることとを含む、構成することとを含む。
【０００８】
さらなる実例の構成において、提供される装置は、命令セットの命令を実行するための処理手段であって、前記命令を実行する際処理手段によって実施される動作を制約するために使用される機能を備える機能ドメインにおいて動作するための処理手段と、プログラムカウンタ値を決定するために処理手段によって使用されるプログラムカウンタ機能を格納するための、プログラムカウンタ機能格納要素手段とを備え、処理手段は、特定される機能をプログラムカウンタ機能格納要素にロードするために使用される少なくとも１つのタイプの命令の実行に応答して、命令セットを変更するために機能ベースのメカニズムを採用し、処理手段は特定される機能に関して機能チェック動作を実施するために、また機能チェック動作が成功したとすれば、命令セットを特定される機能からの命令セット識別子フィールドによって特定させるために、機能ベースのメカニズムを呼び出す。
【０００９】
なおさらなる実例の構成において、上で議論した第１の実例の構成の装置に対応する命令実行環境を提供するためのホストのデータ処理装置を制御するためのプログラム命令を含む、仮想マシンコンピュータプログラムが提供される。一実施例おいて、コンピュータ可読記憶媒体は仮想マシンコンピュータプログラムを格納するために提供されてもよい。
【００１０】
本技法は、単に実例として、その実施例を参照して添付の図面に図示されるように、さらに説明される。
【図面の簡単な説明】
【００１１】
【図１】一実施例による装置のブロック図である。
【図２】結合ポインタ格納要素のセット内でポインタ値の設定又はポインタ値へのアクセスが試行される場合、関連付けられる範囲情報によって示される範囲の外のアドレスを指定するためにそのポインタ値が使用される場合、エラーがトリガされ得るような、命令のタイプの実例の図である。
【図３】一実施例による、結合ポインタに関連付けられるタグビットの使用を示す図である。
【図４】一実施例による、命令セット識別子フィールドがどのように機能内に組み込まれ得るかを概略的に示す図である。
【図５】一実施例による、命令セット内の変更を制御するための機能ベースのメカニズムを実装するように実施されるステップを示すフロー図である。
【図６】一実施例による、機能チェックが機能をプログラムカウンタ機能格納要素にロードするより前に実施される状況における、命令セット内の変更を制御するための機能ベースのメカニズムのさらなる詳細を与えるフロー図である。
【図７】一実施例による、機能チェックが機能をプログラムカウンタ機能格納要素にロードした後に実施される状況における、命令セット内の変更を制御するための機能ベースのメカニズムのさらなる詳細を与えるフロー図である。
【図８】一実施例による、機能チェック動作の間実施されるステップを図示するフロー図である。
【図９Ａ】機能をプログラムカウンタ機能格納要素にロードするために分岐命令が実行される場合、命令セット識別子フィールド情報を使用するための代替的な手法を示す図である。
【図９Ｂ】機能をプログラムカウンタ機能格納要素にロードするために分岐命令が実行される場合、命令セット識別子フィールド情報を使用するための代替的な手法を示す図である。
【図１０】いくつかの実施例において命令セット内で変更できるようにするために使用されることもできる例外ベースのメカニズムを示すフロー図である。
【図１１】使用され得る仮想マシンの実装形態を示す図である。
【発明を実施するための形態】
【００１２】
添付の図面を参照して実施例を議論する前に、以下に実施例の説明を与える。
【００１３】
先に言及したように、所与の処理についてある機能が定義され、定義された機能以外の動作を実行するよう試行されるとエラーをトリガすることができる機能ベースのアーキテクチャに対する興味が高まっている。様々なタイプの機能が定義され得るが、機能の１つのタイプは結合ポインタ（一実施例においてはポインタ値、並びに関連付けられる範囲及びパーミッション情報の両方を組み込む）である。
【００１４】
そのような機能ベースのアーキテクチャに適合する装置は、典型的には機能を格納するために使用される格納要素（本明細書では結合ポインタ格納要素、又はより一般的には機能格納要素とも称する）を有することになる。格納要素はレジスタ（本明細書では結合ポインタレジスタ、又は機能レジスタとも称する）であってもよく、及び／又は汎用メモリにおけるメモリ位置、例えば、スタックメモリ上の位置であってもよい。所望の機能にアクセスし、その機能に応じた動作を実施するべく、そのような格納要素を参照するためにある命令が使用され得る。例えば、結合ポインタを考えると、そのような命令の実行により結合ポインタを取り出し、次いでその中のポインタ値について、命令の実行の間に要求されるメモリ内のアドレスを導出するために使用できるようにする。ポインタ値はメモリアドレスを直接特定するために使用することができ、又は例えば、ポインタ値へのオフセットの加算によってメモリアドレスを導出するために使用することができる。次いで、メモリアドレスが範囲情報によって指定される範囲内にあり、またパーミッション情報において指定されるあらゆるパーミッションが満たされていれば、動作は進むことができるようになる。
【００１５】
したがって、結合ポインタを使用する際、ポインタ値自身は、例えば、アクセスされるデータ値又は実行のためにフェッチされる命令のアドレスを指し示すことができる、又はそのようなアドレスを決定するために使用することができる。しかしながら、その時例えば、アクセスされるあらゆるアドレスが許容範囲内であり、許可された目的のためにアクセスされることを保証するために、範囲及びパーミッション情報が参照され得る。これは、例えば、ポインタから決定されたアドレスがある境界内に留まり、挙動についてのセキュリティ上又は機能的な正常性を維持することを保証するために有用であり得る。そのような手法によって、処理回路によってなされるメモリアクセスを効果的に取り締まることが可能である。
【００１６】
しかしながら、複数の命令セットの使用をサポートするシステムにおいて、命令セットを変更するための能力は、機能の使用を通じて与えられる保護の一部を潜在的にすり抜けることができる。特に、メモリからフェッチされた命令データの解釈は、いったん命令セットの指標が変更されると、異なるものとなる。したがって、機能ベースのアーキテクチャは、命令がフェッチされ得るアドレスの範囲を限定することができる一方、命令セットを変更しようとする不注意による又は悪意のある試行は、処理回路に第１の命令セットの命令を機能ベースのアーキテクチャの制約によって許可されるように正当にフェッチさせることができるが、処理回路については、第２の命令セットにしたがってそのフェッチされた命令を解釈しようとし、潜在的にプロセッサの望ましくない動作上の挙動をまねく。
【００１７】
本明細書において説明される実施例は命令セットを変更するための制御されるメカニズムを与えようとするものであり、命令セットを変更しようとする不注意による又は悪意のある試行の能力を低減させようとするものである。
【００１８】
一実施例において、装置は命令セットの命令を実行するための処理回路を有し、処理回路は命令を実行する際処理回路によって実施される動作を制約するために使用される機能を備える機能ドメインで動作するように構成される。機能ドメインは現在処理回路からアクセス可能な機能格納要素内に存在する機能によって形成される機能のセット、及びそれらの機能格納要素に保持される機能を介してアクセス可能なあらゆるさらなる機能を備える。機能格納要素のうちの１つは、プログラムカウンタ値を決定するために処理回路によって使用されるプログラムカウンタ機能を格納するために使用されるプログラムカウンタ機能格納要素である。プログラムカウンタ値は次いで、命令をフェッチするメモリ内のアドレスを特定するために使用される。
【００１９】
説明される実施例において、処理回路は命令セットを変更するために機能ベースのメカニズムを採用するように構成することができる。特に、特定される機能をプログラムカウンタ機能格納要素にロードするために使用される少なくとも１つのタイプの命令の実行に応答して、処理回路は特定される機能に関して機能チェック動作を実施するために機能ベースのメカニズムを呼び出すように構成される。機能チェック動作を実施した結果、機能チェック動作が成功したとすれば、命令セットは特定される機能からの命令セット識別子フィールドによって特定される。
【００２０】
この機能ベースのメカニズムを採用した結果、処理回路が特定される機能をプログラムカウンタ機能格納要素にロードするために命令を実行することによってプログラムカウンタ機能を更新しようとする場合、特定される機能内の命令セット識別子フィールドが命令セットを特定できるよりも前に機能チェック動作が成功することが必要である。したがって機能チェック動作が成功すると、このメカニズムによって命令セットを変更することができるが、機能チェック動作に失敗すると、命令セットにおけるこの更新は妨げられ、代わりに、例えば例外を取るなどの代替的なアクションが取られる。
【００２１】
機能チェック動作のタイミングは実施例によって変わってもよい。例えば、一実施例において、処理回路は、特定される機能について、その特定される機能をプログラムカウンタ機能格納要素にロードすることに先立って、機能チェック動作を実施するように構成され得る。そのような手法の結果として、特定される機能をプログラムカウンタ機能格納要素にロードさせるかどうかが決定されるよりも前に、機能チェック動作が成功したか、又は失敗したかが分かる。
【００２２】
しかしながら、代替的な実施例において、処理回路は特定される機能について、その特定される機能をプログラムカウンタ機能格納要素にロードした後、機能チェック動作を実施するように構成されてもよい。このことにより、特定される機能をプログラムカウンタ機能格納要素にロードする命令の実行におけるあらゆる遅延を回避することができる一方で、なおその更新されたプログラムカウンタ機能は、機能チェック動作が実施されるよりも前は信頼されないことを保証する。例えば、次の命令が実行されることになるとすぐに、これは機能チェック動作の実施をトリガすることができ、したがって機能チェック動作が成功したかどうかが判断されるよりも前に、その更新されたプログラムカウンタ機能のあらゆる詳細が使用されることを回避し、ひいては特に、機能チェック動作が成功したと決定されない限り、あらゆるフェッチされた命令を特定される機能からの命令セット識別子フィールドによって示され得る変更された命令セットにしたがって解釈することを回避する。
【００２３】
機能チェック動作の失敗を検出した場合に処理回路が取るように構成され得るアクションは複数あるが、一実施例において、処理回路は例外を取るように構成される。一実施例において、これにより例えばソフトウェア例外ハンドラは、機能チェック動作の失敗に関連するある情報を記録し、次いで命令セットにおける試行された変更に対処するために、適当なエラーハンドリングルーチンに制御を渡すことができる。エラーハンドリングルーチンは様々なステップを取ることができる一方、一実施例において、命令セットにおける変更を呼び出そうとしたアプリケーションを停止することを選択することができるが、それは一実施例において先に言及したように、命令セットにおける変更が機能の使用によって与えられる保護をすり抜けようとするために使用される可能性を軽減するべく、命令セットを変更する能力を厳密に制御することが非常に望ましいからである。
【００２４】
一実施例において、機能チェック動作の失敗を検出することに応答して即時に例外が取られ得る一方、代替的な実施例において、機能チェック動作の失敗を特定するためにフラグがセットされてもよく、この場合次の命令が実行される際フラグをセットすることにより例外を取らせる。これによって、失敗条件が検出されてフラグがセットされる時間と、例外が取られる時間との間に、あるイベントが発生する。例えばそれによって、フラグ情報及びプログラムカウンタ機能（ＰＣＣ：Ｐｒｏｇｒａｍ  Ｃｏｕｎｔｅｒ  Ｃａｐａｂｉｌｉｔｙ）情報を保存し、次いでフラグをクリアして異なるプログラムカウンタ機能をプログラムカウンタ機能格納要素にロードする、優先度の高い例外／割り込みを取ることができる。優先度の高い例外／割り込みから戻る際、フラグ及びＰＣＣ情報は次いで復元され、次の命令が実行されることになる際、セットされたフラグの存在により例外が取られることになる。
【００２５】
特定される機能をプログラムカウンタ機能格納要素にロードするために使用される少なくとも１つのタイプの命令は、様々な形態を取ることができるが、一実施例において、命令は分岐命令であり、それによって処理回路は特定される機能を指定する分岐命令を実行することによって機能ベースのメカニズムを呼び出すように構成される。
【００２６】
分岐命令は様々な形態を取ることができる。例えば、ソースオペランドを介して明示的に特定される機能を特定する分岐命令であってもよい。例えば、装置は典型的に処理回路からアクセス可能であり、命令を実行する際処理回路によって実施される動作を制約するために使用される機能を格納するように構成される、１つ又は複数の機能格納要素を備える。この時、分岐命令はそれらの機能格納要素のうちの１つをソースオペランドとして指定することができ、この場合指定された機能格納要素は特定される機能を含む。
【００２７】
他の実例において、分岐命令は非明示的に特定される機能を特定してもよい。例えば、分岐命令は、特定される機能を形成するリターンアドレス機能をプログラムカウンタ機能格納要素にロードするために実行されるリターン命令の形態を取ることができる。典型的には、リターン命令はリターンアドレス機能を明示的に特定する必要はなく、それはリターンアドレス機能を含むデフォルトの記憶要素があるからであり、一実例においてこれは機能例外リンクレジスタ（ＣＥＬＲ：Ｃａｐａｂｉｌｉｔｙ  Ｅｘｃｅｐｔｉｏｎ  Ｌｉｎｋ  Ｒｅｇｉｓｔｅｒ）と称される。
【００２８】
機能チェック動作は様々な形態を取ることができ、したがって実例として、機能チェック動作が成功するか、又は失敗するかを判断するために、機能チェック動作の実施の間特定される機能内の様々な異なるフィールドが参照され得る。例えば、一実施例において、処理回路は、機能チェック動作を実施する際、特定される機能が有効な機能でない限り機能チェック動作が成功することを妨げるために、特定される機能に関連付けられる有効フラグをチェックするように構成され得る。したがって、これにより、処理回路が有効な機能を表すものではない情報を使用してプログラムカウンタ機能格納要素の内容を更新しようとする場合はいつでも機能チェック動作は失敗することになる。
【００２９】
代替的に、又は追加で、機能チェック動作は特定される機能内に与えられる１つ又は複数のパーミッションフラグを参照するように構成されてもよい。特に、特定される機能は典型的に、特定される機能に関連付けられる１つ又は複数のパーミッションの状態を特定するために使用される１つ又は複数のパーミッションフラグを含む。例えば、パーミッションは、処理回路の特定のタイプの動作、特定のモードの動作などへの機能の使用を制限するために使用することができる。異なるパーミッションはまた、アクセスされる異なるタイプの情報に関連付けられることができ、それによって例えばアクセスされる情報がそれ自身機能であるか、又は通常のデータ値であるかどうかに応じて、異なる書き込み及び読み出しパーミッションが設定され得る。
【００３０】
そのような実施例において、処理回路は、機能チェック動作を実行する際、少なくとも１つのパーミッションが所定の状態にない限り機能チェック動作が成功することを妨げるために、１つ又は複数のパーミッションフラグをチェックするように構成され得る。
【００３１】
そのような手法によって、特定される機能が特定の状態において少なくとも１つのパーミッションを有する状況へと命令セットを変更するために、能力を制約することが可能である。一実例として、少なくとも１つのパーミッションは、特定される機能が、プログラムカウンタ機能として使用される場合、メモリから命令をフェッチするための特定される機能の使用を妨げるあらゆるオーバーライド制御情報にしたがって、メモリから命令をフェッチするために使用できるかどうか、また所定の状態が特定される機能がメモリから命令をフェッチするために使用できることを示すセット状態かどうか、を特定するために使用される実行可能なパーミッションを含むことができる。一実施例において、実行可能なパーミッションがクリア状態にあるとすれば、これは機能がプログラムカウンタ機能を形成している場合、メモリから命令をフェッチするために使用されることを妨げられることを特定することになる。したがって、これは機能がプログラムカウンタ機能として使用されることについて適切ではなかったことを特定することになり、ひいては命令がその機能をプログラムカウンタ機能格納要素にロードしようとする場合、一実施例において、機能チェック動作は失敗し、その特定される機能内の命令セット識別子フィールドの内容が命令セットを特定するために使用されることを妨げることがある。
【００３２】
パーミッションフラグがどのようにチェックされ得るかの別の実例として、少なくともパーミッションは、特定される機能が１つ又は複数の機能修正命令によって修正可能かどうか、また所定の状態が機能が前記１つ又は複数の機能修正命令によって修正不可能であることを示すクリア状態かどうかを特定するために使用される修正可能なパーミッションを含むことができる。特定される機能が修正不可能としてマークされると、これは命令セット識別子フィールドの内容が、機能が（例えば、特定の特権レベルにおいて動作している処理によって）確立された時と、続いて処理（その特権レベルになくてもよい）がその機能をプログラムカウンタ機能にロードしようとする時との間の期間に改ざんされていないという追加的な安心感を与えることができる。
【００３３】
機能チェック動作が成功する状況において、特定される機能からの命令セット識別子フィールドの内容を使用して命令セットを特定することができる、いくつかのやり方がある。一実施例において、機能チェック動作が成功する場合、処理回路は命令セット識別子フィールドを含む特定される機能を使用して、プログラムカウンタ機能格納要素内に新しいプログラムカウンタ機能を形成するように構成される。さらには、新しいプログラムカウンタ機能内の命令セット識別子フィールドの値は、命令セットを決定するために使用される。したがって、そのような実施例において、現在の命令セットはプログラムカウンタ機能内の関連付けられる命令セット識別子フィールドの内容によって特定される。
【００３４】
しかしながら、代替的な実施例において、機能チェック動作が成功する場合、処理回路は特定される機能を使用してプログラムカウンタ機能格納要素内に新しいプログラムカウンタ機能を形成するように構成されるが、この時、命令セット識別子フィールドに対応する新しいプログラムカウンタ機能内のフィールドはデフォルト値にセットされる。処理回路はさらに特定される機能の命令セット識別子フィールド内の値を命令セット制御記憶要素に書き込み、命令セット制御記憶要素内の値は命令セットを決定するために使用される。したがって、そのような実施例において、特定される機能がプログラムカウンタ機能格納要素にロードされると、命令セット識別子フィールドの内容は抽出され、命令セット制御記憶要素に書き込まれる。したがって、そのような実施例において、現在の命令セットを決定するために使用されるのは、命令セット制御記憶要素の内容である。
【００３５】
命令セット制御記憶要素は様々な形態を取ることができるが、一実施例において、現在のプロセッサ状態レジスタ（ＣＰＳＲ：Ｃｕｒｒｅｎｔ  Ｐｒｏｃｅｓｓｏｒ  Ｓｔａｔｅ  Ｒｅｇｉｓｔｅｒ）内のフィールドによって与えられる。
【００３６】
一実施例において、命令セットを変更するための前述の機能ベースのメカニズムは、命令セットを変更させるために提供される唯一のメカニズムであり得る。しかしながら、代替的な実施例において、処理回路は命令セットを変更するために例外ベースのメカニズムをさらに提供することができ、例外ベースのメカニズムを呼び出すと、処理回路は、信頼されたソフトウェアが例外からリターンする際使用される命令セットを特定するリターン状態を確立するために実行される予め定義された状態へ例外を取るように構成される。したがって、そのような手法によって、信頼される例外／例外リターンメカニズムを、命令セットを修正するために信頼されるソフトウェアの使用をトリガするために使用することが可能である。
【００３７】
命令セットを変更するために、１つ又は複数のさらなる制御されるメカニズムがやはり提供される一方、特定の一実施例において、処理回路は、機能ベースのメカニズム又は例外ベースのメカニズムのいずれかを使用して命令セットを変更のみできるように、制約されてもよい。命令セットが変更され得るやり方を厳密に制約することによって、これは、機能の使用を通じて設けられるセキュリティ施策のうちの１つ又は複数を潜在的にすり抜けることがある、命令セットを変更しようとする不注意による又は悪意のある試行に対して、強化された弾性力を与える。
【００３８】
次に、図面を参照して特定の実施例を説明する。
【００３９】
図１は命令を処理するための処理パイプライン４を備えるデータ処理装置２の実例を概略的に図示している。この実例において、処理パイプライン４は、フェッチ工程６、デコード工程８、発行工程１０、実行工程１２、及びライトバック工程１４を含む複数のパイプライン工程を含むが、他のタイプの工程又は工程の組合せが提供されてもよいことを了解されたい。例えば、いくつかの実施例ではレジスタのリネームを実施するためのリネーム工程を含むことができる。処理されることになる命令が工程から工程へと移動し、命令がある工程で待ち状態にある間、別の命令はパイプライン４の異なる工程で待ち状態にあり得る。
【００４０】
フェッチ工程６はレベル１（Ｌ１：Ｌｅｖｅｌ  １）の命令キャッシュ２０から命令をフェッチする。フェッチ工程６は普通、連続する命令アドレスから逐次に命令をフェッチすることができる。しかしながら、フェッチ工程はまた分岐命令の結果を予測するための分岐予測器２２を有することがあり、フェッチ工程６は、分岐すると予測される場合は（非逐次）分岐ターゲットアドレスから、又は分岐しないと予測される場合は次の連続するアドレスから、命令をフェッチすることができる。分岐予測器２２は、ある分岐が取られそうか、又は取られそうにないかを予測するための情報を格納するための１つ又は複数の分岐履歴テーブルを含むことができる。例えば分岐履歴テーブルは、前に実行された分岐の実際の結果を追跡するための、又は分岐についてなされた予測についての信頼度を表すカウンタを含むことができる。分岐予測器２２はまた分岐命令の前のターゲットアドレスをキャッシュするための分岐ターゲットアドレスキャッシュ（ＢＴＡＣ：Ｂｒａｎｃｈ  Ｔａｒｇｅｔ  Ａｄｄｒｅｓｓ  Ｃａｃｈｅ）２４を含むことができ、それによって同一の分岐命令との後続の遭遇の際、これらが予測され得る。
【００４１】
フェッチされた命令は命令をデコードしてデコード命令を生成するためのデコード工程８に渡される。デコード命令は適当な処理演算を実行するために実行工程１２を制御するための制御情報を含むことができる。キャッシュ２０からフェッチされたいくつかのより複雑な命令について、デコード工程８はこれらの命令を複数のデコード命令にマッピングすることができ、これはマイクロ命令（μｏｐ又はｕｏｐ）として知られ得る。したがって、Ｌ１の命令キャッシュ２０からフェッチされた命令とパイプラインの後方の工程で見られる命令との間には１対１関係がなくてもよい。一般的には、本出願における「命令」との称し方はマイクロ命令を含むものとして解釈するべきである。
【００４２】
デコード命令は発行工程１０に渡され、命令の実行に必要なオペランドが利用可能かどうかを判断し、オペランドが利用可能であれば実行のため命令を発行する。いくつかの実施例はインオーダー処理をサポートしていることがあり、それによって、命令がＬ１の命令キャッシュ２０からフェッチされたプログラム順序に対応する順序での実行のために、命令が発行される。他の実施例はアウトオブオーダー実行をサポートしていることがあり、それによって命令は、プログラムの順序とは異なる順序で実行工程１２に発行され得る。前方の命令がオペランドを待ってストールしている間、オペランドが利用可能であるプログラムの順序において後方の命令を先に実行できるため、アウトオブオーダー処理はパフォーマンスを改善するために有用であり得る。
【００４３】
発行工程１０は命令を実行工程１２に発行し、命令は様々なデータ処理演算を実行するために、実行される。例えば、実行工程は、整数値に対して算術又は論理演算を実行するための算術／論理ユニット（ＡＬＵ：Ａｒｉｔｈｍｅｔｉｃ／Ｌｏｇｉｃ  Ｕｎｉｔ）３０、浮動小数点形式で表現される値に対して演算を実行するための浮動小数点（ＦＰ：Ｆｌｏａｔｉｎｇ−Ｐｏｉｎｔ）ユニット３２、及びレベル１（Ｌ１）のデータキャッシュ３６からのデータ値をレジスタ４０にロードするためのロード演算、又はレジスタ４０からのデータ値をＬ１のデータキャッシュ３６に格納するためのストア演算を実行するためロード／ストアユニット３４を含む複数の実行ユニット３０、３２、３４を含むことができる。これらは、提供され得る実行ユニットのいくつかの実例のタイプに過ぎず、多くの他の種類がやはり提供され得ることを了解されたい。処理演算を実行するために、実行工程１２はデータ値をレジスタ４０のセットから読み出すことができる。実行された命令の結果は次いでライトバック工程１４によってレジスタ４０に書き戻すことができる。
【００４４】
Ｌ１の命令キャッシュ２０及びＬ１のデータキャッシュ３６は、複数のキャッシュのレベルを含むキャッシュヒエラルキーの一部であってもよい。例えば、レベル２（Ｌ２：Ｌｅｖｅｌ  ２）のキャッシュ４４がやはり提供され得、任意選択でさらなるレベルのキャッシュが提供されてもよい。この実例において、Ｌ２のキャッシュ４４はＬ１の命令キャッシュ２０とＬ１のデータキャッシュ３６との間で共有されるが、他の実例は別個のＬ２の命令及びデータキャッシュを有することができる。フェッチされることになる命令がＬ１の命令キャッシュ２０にない場合、Ｌ２のキャッシュ４４からフェッチすることができ、同様に命令がＬ２のキャッシュ４４にない場合、メインメモリ５０からフェッチすることができる。同様に、ロード命令に応答して、データはＬ１のデータキャッシュ３６にない場合Ｌ２のキャッシュ４４からフェッチすることができ、必要に応じてメモリ５０からフェッチすることができる。あらゆる既知のスキームがキャッシュヒエラルキーを管理するために使用され得る。
【００４５】
プログラム命令及びデータ値を参照するためにパイプライン４によって使用されるアドレスは、仮想アドレスであってもよいが、少なくともメインメモリ５０、及び任意選択でやはり少なくともキャッシュヒエラルキーのいくつかのレベルは、物理的にアドレッシングされ得る。したがってトランスレーション・ルックアサイド・バッファ（ＴＬＢ：Ｔｒａｎｓｌａｔｉｏｎ  Ｌｏｏｋａｓｉｄｅ  Ｂｕｆｆｅｒ）５２が、パイプライン４によって使用される仮想アドレスを、キャッシュ又はメモリにアクセスするために使用される物理アドレスにトランスレートするために与えられてもよい。例えば、ＴＬＢ５２はそれぞれが仮想アドレス空間の対応するページの仮想ページアドレスを指定する複数のエントリを含むことができ、仮想ページがアドレッシングする対応する物理ページアドレスは、対応するページ内の仮想アドレスを物理アドレスにトランスレートするためにマッピングされるべきである。例えば、仮想及び物理ページアドレスは対応する仮想アドレス及び物理アドレスの最上位部分に対応することができ、この時残りの最下位部分は仮想アドレスを物理アドレスにマッピングする際変更されないままである。アドレストランスレーション情報と同様に、それぞれのＴＬＢエントリはまた、アドレスのあるページがパイプライン４のあるモードでアクセス可能かどうかを示すことなどのアクセスパーミッションを指定するいくつかの情報を含むことができる。いくつかの実施例において、ＴＬＢエントリはまた、キャッシュヒエラルキーのどのレベルが読み出し若しくは書き込み動作に応じて更新されるかを定義するキャッシュポリシ情報（例えば、キャッシュがライトバック又はライトスルーモードで動作すべきであるかどうか）、又は対応するページ内のアドレスへのデータアクセスがメモリシステムによって、データアクセスがパイプライン４によって発行された順序と比べてリオーダすることができるかどうかを定義する情報、などのアドレスの対応するページの他のプロパティを定義することができる。
【００４６】
図１が単一のレベルのＴＬＢ５２を示す一方、ＴＬＢのヒエラルキーがレベル１（Ｌ１）のＴＬＢ５２が複数の最近アクセスされたページ内のアドレスをトランスレートするためのＴＬＢエントリを含み得るように提供され得、またレベル２（Ｌ２）のＴＬＢが多数のページについてのエントリを格納するために提供され得ることを了解されたい。必要とされるエントリがＬ１のＴＬＢに存在しない場合、Ｌ２のＴＬＢから、又はヒエラルキー内のさらなるＴＬＢからフェッチすることができる。アクセスされることになるページについて必要とされるエントリがＴＬＢのうちいずれにもない場合、メモリ５０のページテーブルにアクセスするためにページテーブルウォークを実施することができる。本技法では、あらゆる既知のＴＬＢ管理スキームを使用することができる。
【００４７】
また、いくつかのシステムは複数のレベルのアドレストランスレーションをサポートすることができ、それによって、例えば、第１のＴＬＢ（又はＴＬＢのヒエラルキー）は仮想アドレスを中間アドレスにトランスレートするために使用することができ、また１つ又は複数のさらなるＴＬＢを使用するアドレストランスレーションの第２のレベルが、次いで中間アドレスをキャッシュ又はメモリにアクセスするために使用される物理アドレスにトランスレートできることを了解されたい。これは例えば、アドレストランスレーションの第１のレベルがオペレーティングシステムによって管理され得、アドレストランスレーションの第２のレベルがハイパーバイザによって管理され得る場合の仮想化をサポートするために有用であり得る。
【００４８】
図１に示すように、装置２は結合ポインタレジスタ６０のセットを有することができる。結合ポインタレジスタのセットは図１において汎用データレジスタ４０のセットとは物理的に別個であるように示されるが、一実施例においては汎用データレジスタ及び結合ポインタレジスタの両方を提供するために同一の物理記憶装置が使用されてもよい。
【００４９】
それぞれの結合ポインタレジスタ６０は、アクセスされることになるデータ値のアドレスを決定するために使用され得るポインタ値６２、及び対応するポインタ６２を使用する際アドレスの許容範囲を指定する範囲情報６４を含む。結合ポインタレジスタ６０はまたポインタの使用に関して１つ又は複数のリストリクション／パーミッションを定義することができるリストリクション情報６６（本明細書ではパーミッション情報とも称する）を含むことができる。例えば、リストリクション６６は、ポインタ６２を使用し得る命令のタイプ、又はポインタが使用され得るパイプライン４のモードを制限するために使用することができる。したがって、範囲情報６４及びリストリクション情報６６は、ポインタ６２を使用できる機能を定義すると考えられ得る。定義された機能以外でポインタ６２を使用する試行がなされると、エラーがトリガされ得る。範囲情報６４は例えば、ポインタがある既知の境界内に留まっており、重要又はセキュアな情報を含み得るメモリアドレス空間の他のエリアに迷い込んでいないことを保証することのために有用であり得る。汎用データレジスタ及び結合ポインタレジスタの両方のために同一の物理記憶装置が使用される一実施例において、その時一実施例においてポインタ値６２は例えば対応する汎用レジスタについて使用されるのと同一の記憶装置の位置に格納され得る。
【００５０】
図２は、許容範囲が、データ又は命令への認可されていないアクセスに対して保護するために使用される命令のタイプの実例を示す。図２の上部で示すように、特定の結合ポインタレジスタＰＲ（Ｐｏｉｎｔｅｒ  Ｒｅｇｉｓｔｅｒ）１は所与のポインタ値６２及び範囲情報６４を含み、この実例においては許容範囲の下位境界を定義する下位境界アドレス６８、及び許容範囲の上位境界を定義する上位境界アドレス６９を使用して指定されている。例えば、境界６８、６９はアドレス範囲８００００から８１０００を定義するために設定される。ある命令が結合ポインタレジスタＰＲ１参照し、ポインタ６２から決定されるアドレスがこの範囲の外にある場合、エラーがトリガされ得る。
【００５１】
例えば、図２のパートＡで示されるように、いくつかのシステムではポインタレジスタ６０内のポインタ６２の値を範囲情報６４によって指定される範囲の外にある値に設定しようとする試行があるとエラーがトリガされ得る（ここではポインタがアドレスを直接指定すると仮定している）。これはポインタ６２が指定された範囲の外のいかなる値を取ることも回避し、それによって、ポインタを使用するあらゆるアクセスが許可された範囲内に安全にあることを保証することができる。代替的に、図２のパートＢで示されるように、命令がポインタ６２のアドレスによって特定される位置にアクセスしようと試行し、その時そのアドレスが指定された範囲の外にある場合、エラーがトリガされ得る。したがって、ポインタ６２を指定された範囲の外の値に設定することがなお許容され得るが、そのポインタアドレス（又はそのポインタから導出されるアドレス）においてデータアクセスが試行されると、そのアドレスが許可された範囲の外にある場合、エラーがトリガされ得る。図２のパートＡ及びＢに示される両方のタイプの命令に応じて、他のシステムがエラーをトリガすることもある。
【００５２】
範囲情報６４は異なるやり方で設定することができる。例えば、セキュアなコード、又はオペレーティングシステム若しくはハイパーバイザは、所与のポインタについて許可される範囲を指定することができる。例えば、命令セットアーキテクチャは、所与のポインタ６２についての範囲情報６４を設定するための又は修正するための複数の命令を含むことができ、これらの命令の実行はあるソフトウェア又はプロセッサ４のあるモード若しくは例外レベルに制限することができる。範囲情報６４を設定するための又は修正するためのあらゆる既知の技法を使用することができる。
【００５３】
ポインタへの参照を行うある命令を実行する際に実行状態１２で使用され得る結合ポインタ格納要素６０のセットに加えて、プログラムカウンタ機能（ＰＣＣ：Ｐｒｏｇｒａｍ  Ｃｏｕｎｔｅｒ  Ｃａｐａｂｉｌｉｔｙ）レジスタ８０が、命令がレベル１の命令キャッシュ２０からフェッチされる際、フェッチ工程６で類似の機能性を提供するためにやはり使用されてもよい。特に、プログラムカウンタポインタはフィールド８２に格納され得、この時ＰＣＣ８０はまた、結合ポインタ格納要素６０のセット内のポインタのそれぞれに与えられる範囲及びリストリクション情報と同様に、範囲情報８４及び適当なリストリクション情報８６を与える。
【００５４】
さらには、一実施例において、非結合ポインタはまた汎用レジスタ４０内で指定され、メモリアクセスを実施する際使用され得る。そのような非結合ポインタを使用してアクセスされ得るメモリアドレスを限定するために、機能レジスタのいずれかに含まれる範囲及びリストリクション情報と同様に、範囲情報９２及びあらゆるリストリクションデータ９４の両方を指定するデフォルトのデータ機能（ＤＤＣ：Ｄｅｆａｕｌｔ  Ｄａｔａ  Ｃａｐａｂｉｌｉｔｙ）レジスタ９０が提供されてもよい。次に、汎用レジスタ４０内の非結合ポインタを参照してメモリアドレスを特定するメモリアクセス命令が実行されると、結合ポインタに関して実施される結合チェック動作に類似する結合チェック動作が、その非結合ポインタから導出されるあらゆるアドレスに基づいてなお実施され得るが、この事例ではＤＤＣレジスタ９０内に保持された範囲及びリストリクション情報を考慮している。そのような手法によって、例えば、機能非認識コードを実行する際に汎用レジスタ４０からアクセスされるポインタがどのように使用されるかを制約するために、既存のソフトウェアライブラリ内のいくつかの機能非認識コードを利用したいと思う機能認識コードがＤＤＣレジスタ９０を設定することが可能である。特に、範囲情報はそのような機能非認識コードを実行する際アクセスされ得るアドレス範囲を限定するために使用することができる。
【００５５】
結合ポインタレジスタ内の結合ポインタによって特定されるメモリアドレスのあらゆる特定の範囲は、データ、命令、及び／又は他の機能（すなわち、他の結合ポインタ）を含むことができる。したがって、時間的なあらゆるポイントにおいて、メモリへアクセスするための処理回路の能力は、結合ポインタレジスタにおいて特定される機能、及びそれらの結合ポインタレジスタで保持される機能を介してアクセス可能なあらゆるさらなる機能を含む機能のセットによって定義され、本明細書において機能のこのセットを機能ドメインと称することを了解されたい。
【００５６】
ＰＣＣレジスタ８０又はＤＤＣレジスタ９０内で指定される範囲情報及びあらゆる関連付けられるリストリクションは、様々なやり方で設定することができる。しかしながら、一実施例において、その情報は現在の機能ドメインで処理回路に利用可能な結合ポインタの１つ又は複数を使用して決定され、それによって現在の機能ドメインについて特定されたメモリアドレス範囲の外にあるＰＣＣ又はＤＤＣベースの結合チェックを使用してアクセスできるメモリアドレスはない。
【００５７】
図３は、タグビットが個々のデータブロックに関連付けられて、これらのデータブロックが機能を表しているかどうか（すなわち、結合ポインタ及び関連付けられるリストリクション情報）、又は通常データを表しているかどうかを特定するためにどのように使用されるか概略的に図示している。特に、メモリアドレス空間１１０は、典型的には指定されたサイズを有することになる一連のデータブロック１１５を格納することになる。純粋に図示のために、この実例において、それぞれのデータブロックが１２８ビット含むと仮定する。それぞれのデータブロック１１５に関連して、タグフィールド１２０が提供され、一実例において、タグビットと称される単一のビットフィールドであり、関連付けられるデータブロックが機能を表すことを特定するために設定され、関連付けられるデータブロックが通常データを表し、したがって機能として取り扱うことができないことを示すためにクリアされる。セットされた又はクリアな状態に関連付けられる実際の値は、実施例によって異なっていてよいが、純粋に図示のため、一実施例においては、タグビットが値１を有する場合、関連付けられるデータブロックが機能であることを示し、タグビットが値０を有する場合は関連付けられるデータブロックが通常データを含むことを示すことを了解されたい。
【００５８】
機能が、図３で示される機能レジスタ１００などの結合ポインタレジスタ（本明細書では機能レジスタとも称する）６０のうちの１つにロードされると、次にタグビットは機能情報を伴って移動する。したがって、機能が機能レジスタ１００にロードされると、ポインタ１０２、範囲情報１０４及びリストリクション情報１０６（以降でパーミッション情報と称する）が機能レジスタにロードされることになる。加えて、その機能レジスタに関連して、又はその中の特定のビットフィールドとして、タグビット１０８はその内容が機能を表すことを特定するために設定されることになる。同様に、機能がメモリに格納し戻される場合、関連するタグビット１２０は機能が格納されるデータブロックに関連付けられて設定されることになる。そのような手法によって、機能と通常データとを区別し、ひいては通常データを機能として使用することができないことを保証することが可能である。
【００５９】
一実施例において、装置は、それぞれの例外レベルが異なるソフトウェア実行特権を有する、異なる例外レベルで動作できるように構成され得る。さらには、例外メカニズムを使用して複数の例外レベルの間を遷移することができる。しかしながら、一実施例において、すべての例外が例外レベルを変更させるわけではない。
【００６０】
図１に示されるように、装置１０は処理回路によってその動作中に参照される様々な制御及びステータス情報を格納する様々な制御／ステータスレジスタ７０へのアクセスを有しており、制御／ステータスレジスタ７０は例外のハンドリングの間に使用される様々なレジスタを含んでいる。
【００６１】
図１に示されるように、現在の処理状態７４は制御／ステータスレジスタ７０内に維持され、プロセッサの現在の動作に関連する様々な実行状態情報を捉える。単一のボックス７４として示される一方、現在の処理状態は必ずしもすべて単一のレジスタ内に格納されるわけではないが、利用可能な制御／ステータスレジスタ７０内の、複数の制御及びステータスレジスタ内に格納され得る。
【００６２】
動作中、様々な異なるメカニズム、例えば割り込み、システムコール、フォールトなどによって例外がトリガされ得る。一実施例によると、例外が取られると、例外エントリメカニズムがトリガされ、この処理の間、現在の処理状態７４は保存される処理状態７２として捉えられる。やはり、保存される処理状態７２は単一のレジスタ内、又は複数のレジスタ内に格納することができる。次いで例外を処理するために、処理回路によって例外ハンドリング動作が実施される。続いて処理回路が例外からリターンする場合、保存された処理状態が現在の処理状態に復元され、処理回路が例外が取られる前に実施していた動作を継続できるようになる。
【００６３】
複数の例外レベルについて処理回路の実行状態を維持できるようにするために、別個の保存される処理状態レジスタ（ＳＰＳＲ：Ｓａｖｅｄ  Ｐｒｏｃｅｓｓ  Ｓｔａｔｅ  Ｒｅｇｉｓｔｅｒ）７２及び現在の処理状態レジスタ（ＣＰＳＲ）７４を、所望であれば複数の例外レベルについて維持することができる。
【００６４】
例外エントリの際、プログラムカウンタ機能レジスタ８０は機能制御格納要素７９に格納される例外エントリアドレス機能情報を使用して更新され得る。特に、レジスタ７９は例外エントリの際使用される適当なアドレスについての情報、及びＰＣＣレジスタ８０内に格納されるプログラムカウンタ機能を形成するためにそのアドレスに加えて与えられる関連付けられる機能情報もまた格納する。レジスタ７９内の例外エントリアドレス情報は様々な形態を取ることができるが、一実施例において、レジスタ７９は機能ベクトルベースアドレスレジスタ（ＣＶＢＡＲ：Ｃａｐａｂｉｌｉｔｙ  Ｖｅｃｔｏｒ  Ｂａｓｅ  Ａｄｄｒｅｓｓ  Ｒｅｇｉｓｔｅｒ）の形態を取る。このレジスタは例外エントリのためのベースアドレスを与え、例外は例外タイプに依存してこのベースアドレスからのオフセットを決定する。したがって例外のタイプについての情報がＰＣＣレジスタ８０にロードされるプログラムカウンタ機能を形成するために使用される適当なアドレスを特定するために使用され、この時ＰＣＣレジスタについて機能情報の残りの部分はＣＶＢＡＲ内の機能の対応する部分から形成されている。
【００６５】
先に言及したように、例外を取る際、現在の処理状態７４が保存される処理状態７２として捉えられる。加えて、ＰＣＣレジスタ８０内に格納される現在のプログラムカウンタ機能は、好ましいリターンアドレス機能を特定するために使用される。好ましいリターンアドレスは例外のタイプに依存するが、典型的にはプログラムカウンタ値、又は命令サイズの分インクリメントされたプログラムカウンタ値（例えばバイトサイズのアドレス指定、及び３２ビット命令を仮定すると４インクリメントされる）である。好ましいリターンアドレスに加えて、現在のプログラムカウンタ機能からの残りの機能情報はまた、ＰＣＣから生成されるリターンアドレス機能へ複製される。一実施例において、このやり方で生成されるリターンアドレス機能は専用のリターンアドレス機能レジスタ内に格納され、特定の一実施例において、これは機能例外リンクレジスタ（ＣＥＬＲ：Ｃａｐａｂｉｌｉｔｙ  Ｅｘｃｅｐｔｉｏｎ  Ｌｉｎｋ  Ｒｅｇｉｓｔｅｒ）７８である。後に例外からリターンする際、ＣＥＬＲレジスタ７８の内容は、ＰＣＣレジスタ８０に復元され、ＳＰＳＲレジスタ７２の内容に加え、関連する例外レベルについてＣＰＳＲレジスタ７４に復元することができる。
【００６６】
上述のような機能ベースのシステムの使用は、セキュリティ及びシステム挙動の機能的な正常性を著しく強化することができる。例えば、そのような手法の使用を通じて、処理回路によってなされるメモリアクセスを効果的に取り締まること、実行のためにメモリからフェッチされる命令及びプロセッサによって操作されるデータ値の両方を、それらの命令を実行する際に制御することが可能である。しかしながら、先に言及したように、いくつかのシステムは複数の命令セットからの命令の実行を可能とし、この時制御状態は使用されている現在の命令セットを特定するように維持され、ひいてはメモリからフェッチされる命令データが実行のために命令をデコードする際どのように解釈されるべきかを特定する。命令セットを変更するような不注意による又は悪意のある試行は機能の使用によって与えられる保護の一部をすり抜けることがあるが、それはメモリ内に保持される読み取り専用コードの解釈における変更を可能とすることができるからである。本明細書において説明される実施例は、そのようなリスクを緩和することを目的として、命令セットがそのような装置内でどのように変更され得るかを厳密に制御するメカニズムを提供する。
【００６７】
図４は機能を命令セット識別子フィールドとして機能する追加的なフィールドでどのように補うことができるかを図示している。特に、この実例における機能１５０は結合ポインタであると仮定されており、したがってポインタ値１５８並びに関連付けられている範囲及びパーミッションフィールド１５６、１５４をそれぞれ有している。タグビット１５２はまた関連付けられている情報が有効な機能を表しているか、そうでないかを示すために与えられる。パーミッションフィールド１５４内でエンコードされるパーミッションは、それらのフィールド内で与えられる複数のパーミッションフラグの状態によって決定され得、それによってパーミッションフラグの値は１つ又は複数のパーミッションの状態を決定するために使用される。これらのパーミッションは様々な形態を取ることができるが、一実施例においては、関連付けられている機能がプログラムカウンタ機能として使用される際メモリから命令をフェッチするために使用できるかどうかを特定する少なくとも実行可能なパーミッション、及び関連付けられている機能が１つ又は複数の機能修正命令によって修正可能かどうかを特定するために使用される修正可能なパーミッションを含むことができる。一実施例において、パーミッションはそのパーミッションに影響を及ぼし得る他の制御情報との組合せで解釈される必要がある場合もある。したがって、一実施例において、パーミッションがクリア状態にある場合、これはその機能に関してはそのパーミッションが付与されていないことを示している。しかしながら、パーミッションがセット状態にある場合、一実施例において、これはそのパーミッションが、そのパーミッションを付与することに影響を及ぼし得るあらゆるオーバーライド制御情報にしたがって、付与されていることを示す。
【００６８】
やはり図４に示されるように、フィールド１６０は命令セットを特定するために与えられ得る。このフィールドのサイズはサポートされる命令セットの数に依存するが、実例として、サポートされる命令セットが２つしかない場合、２つの命令セットのそれぞれを特定できるようにするためには単一のビットフィールドで十分である。
【００６９】
命令セット識別子フィールドが別個の専用のフィールドであり得る一方、一実施例において、それはポインタ値フィールドの１つ又は複数の最下位ビットによって形成されてもよい。例えば、ポインタ値に対するメモリのアラインメント制約のため、ポインタ値の１つ又は複数の最下位ビットが使用されないことがあり、それに応じて、それらの使用されないビットは命令セット識別子フィールドを与えるために使用することができる。
【００７０】
一実施例において、機能が汎用機能レジスタ６０のうちの１つにおいて汎用機能である間、命令セット識別子フィールドの値は何の関連性も有さない。しかしながら、機能がＰＣＣレジスタ８０にロードされて新しいプログラムカウンタ機能を形成する場合、その機能が新しいプログラムカウンタ機能として使用されると適用可能となる命令セットを特定するために、命令セット識別子フィールドの情報を使用することができる。したがって、これは命令セットを変更させることができる単純なメカニズムを提供する。
【００７１】
しかしながら、命令セットを指定するためのそのような命令セット識別子フィールドの使用が、誤使用に対して強健であることを保証するために、命令が特定される機能をＰＣＣレジスタ８０にロードするために使用される時は、特定される機能からの命令セット識別子フィールドの情報を使用して命令セットを変更させるよりも前に、特定される機能に関する機能チェック動作を実施するために、いつも機能ベースのメカニズムが呼び出される。
【００７２】
図５は命令セット内の変更を制御するために一実施例において使用される機能ベースのメカニズムの一般的な概要を与えるフロー図である。一実施例において、機能ベースのメカニズムは、あるタイプの命令が特定される機能をプログラムカウンタ機能レジスタ８０にロードしようとすると、トリガされる。特に、機能ベースのメカニズムは、分岐命令がその目的のために使用されるとトリガされ得る。したがって、ステップ２００において、分岐命令がプロセッサによって実行されることになるかどうかが判断され、この場合その分岐命令は機能を指定する。分岐命令は具体的に機能レジスタ６０のセット内のソース機能レジスタを特定することができ、この時、そのソース機能レジスタはＰＣＣレジスタ８０にロードされる特定される機能を含む。しかしながら、ステップ２００において分岐命令の他の形態がやはり検出されてもよい。例えば、先に取られた例外に続くいくつかの前のコードに戻るために使用されるリターン命令は、やはりステップ２００において検出されるべきタイプの分岐命令と考えることができるが、それはやはりＰＣＣレジスタ８０の内容を、特定される機能で更新させるからである。リターン命令の実例において、特定される機能を含むレジスタは明示的に特定される必要はない場合があるが、それはリターン命令からは非明示的であるからである。特に、一実施例において、リターン命令はＣＥＬＲレジスタ７８の内容をＰＣＣレジスタ８０にロードさせる。
【００７３】
特定される機能をプログラムカウンタ機能レジスタにロードするために使用される分岐命令が実行されることを特定してあるため、処理はステップ２０５に進み、特定される機能について機能チェック動作が実施される。図６及び図７を参照して後に議論するように、機能チェック動作の実施のタイミングは実施例によって異なることができる。例えば、ＰＣＣレジスタの内容を更新するのに先立って実施されてもよく、又はそれらの内容が更新された後に実施されてもよい。しかしながら、一実施例において、どの手法が取られるかに関わらず、機能チェックが実施されてそれが成功したと判断されるまでは、更新されたプログラムカウンタ機能及び関連付けられている命令セット識別子情報に応じてアクションが取られないように、機能チェックが実施される。
【００７４】
ステップ２０５における機能チェック動作の実施に続いて、ステップ２１０において機能チェック動作が成功したか、そうでないかが判断される。成功した場合、処理はステップ２１５に進み、新しい有効なプログラムカウンタ機能が特定される機能から形成され、さらには命令セットが特定される機能からの命令セット識別子フィールドを使用して決定される。図９Ａ及び図９Ｂを参照して後により詳細に議論するように、命令セット識別子フィールドの内容はプログラムカウンタ機能に複製することができるか、又は代わりに抽出して別個の制御レジスタ内に格納することができる。
【００７５】
ステップ２１０において機能チェックが成功していないと判断される場合、処理はステップ２２０に進み所定のアクションが取られる。所定のアクションは様々な形態を取ることができるが、一実施例において、機能チェック動作が失敗したと判断されると直接例外を取ることを伴うことができる。代替的に、例外を取ることを延期することができ、代わりに後々実行される次の命令によって例外をトリガすることができる。
【００７６】
図６は機能チェック動作が特定される機能をＰＣＣレジスタ８０にロードすることに先立って実施される実施例をより詳細に図示するフロー図である。ステップ２５０において、ソースレジスタ内に存在するものとして特定される機能について機能チェック動作が実施される。次いでステップ２５５において、機能チェック動作が成功したか、又はそうでないかが決定される。成功した場合、処理はステップ２６０に進み、ＰＣＣレジスタ８０の内容を更新するために、及び特定される機能からの命令セット識別子フィールドを使用して命令セット示すことができるように、分岐動作を完了させる。したがって、命令セット識別子フィールド内の情報が、分岐動作の実施に先立って命令セットを特定する情報と違っている場合、そのようなメカニズムによって命令セットが変更されることが了解されよう。続いてフェッチされた命令は、新しく特定される命令セットにしたがってデコードされる。
【００７７】
ステップ２５５においてテストに失敗した場合、一実施例において、これはステップ２７０において即時に例外を取ることを伴うことができる。しかしながら、代替的な実施例において、ある期間について例外を取ることを延期することが可能であってもよい。したがって、ステップ２６５において、例外を取ることを延期するべきか、又はそうでないかを判断することができる。延期しない場合、ステップ２７０において即時に例外が取られる。
【００７８】
しかしながら、例外が延期される場合、処理はステップ２７５に進み、機能チェック動作の失敗状態を特定するためにフラグがセットされる。フラグをセットできる複数のやり方がある。例えば、機能チェック動作の失敗状態を特定するために設定される制御レジスタ内に専用の制御フィールドがあってもよい。代替的に、ステップ２８０において分岐動作を完了させる場合、特定される機能を使用して作成されるプログラムカウンタ機能のいくつかのプロパティは変更することができ、それによって更新されたＰＣＣはそれを使用するようなあらゆる試行がなされると例外をトリガする。特定の実例として、ＰＣＣレジスタ内に格納される際、更新されたＰＣＣにおいてタグビットをクリアして、ＰＣＣレジスタが有効な機能を格納していないことを示すことができる。
【００７９】
ステップ２８０において分岐動作が完了され、その結果としてＰＣＣの内容が更新され、命令セットについての情報が特定される機能からの命令セット識別子フィールドを使用して更新される。ステップ２８５において、次の命令が実行されるかどうか判断され、実行される場合処理はステップ２９０に進み、フラグがセットされているかどうか判断される。フラグがセットされていると仮定すると、ステップ２９２において例外が取られ、フラグはクリアされる。しかしながら、フラグがセットされていない場合、命令はステップ２９４で実行される。
【００８０】
フラグのメカニズムを使用することによって、フラグがセットされてから例外が取られるまでの間にあるイベントが起こるようにする。例えばそれにより、フラグ情報及びプログラムカウンタ機能情報を保存し、次いでフラグをクリアして異なるプログラムカウンタ機能をプログラムカウンタ機能レジスタ８０にロードする、優先度の高い例外／割り込みが取られ得る。その優先度の高い例外／割り込みから戻る際、フラグ及びＰＣＣ情報は次いで復元され、次の命令が実行されることになる際、セットされたフラグの存在により例外が取られる。
【００８１】
ステップ２７０又はステップ２９２のいずれかにおいて例外が取られると、ソフトウェア例外ハンドラは、命令セットにおける試行された変更に対処するために、適当なエラーハンドリングルーチンに制御を渡す。エラーハンドリングルーチンが取り得る複数のステップがある。しかしながら、一実施例において、例外を取ることは機能チェック動作に成功しなかった機能を使用して命令セットを変更する試行がなされた事実によって生じた結果であるため、分岐命令を実行させたアプリケーションを停止することが適当であると考えられ得る。代替的に、例外ハンドリングルーチンは、分岐動作の完了によって命令セットを変更させることが安全であることを確実にするために、いくつかの追加的なチェック及び／又はクリーンアップ動作を実施するように構成されてもよい。
【００８２】
図７は機能チェック動作が特定される機能をＰＣＣレジスタ８０にロードした後に実施される、図６に対する代替的な手法を図示するフロー図である。したがって、ステップ３００において示されるように、分岐動作を完了させ、その結果、ＰＣＣレジスタの内容は特定される機能を使用して更新され、加えて、特定される機能からの命令セット識別子フィールドは命令セットを示すために使用される。
【００８３】
処理は次いでステップ３０５に進み、次の命令が実行されることになるかどうかを特定され、処理がステップ３１０に進む場合は、機能チェック動作は、現在ＰＣＣレジスタに存在する形態で特定される機能について実施される。ステップ３１５において機能チェックが成功したと考えられる場合、処理はステップ３２０に進み、今度は処理によって特定される機能から新しい有効なプログラムカウンタ機能が形成され、また特定される機能からの命令セット識別子フィールドを使用して命令セットが決定される。しかしながら、ステップ３１５において機能チェック動作が失敗したと判断される場合、処理はステップ３２５に進み例外が取られる。図６のステップ２７０又はステップ２９２について先に議論したような同一のやり方で例外が扱われる。
【００８４】
機能チェック動作は様々な形態を取ることができるが、図８のフロー図によって一実施例が図示される。ステップ３５０において、特定される機能が有効かどうか判断される。一実施例において、これはタグビットの値を見ることによって判断される。特に、タグビットがセットされている場合、特定される機能は有効な機能であると考えられ、タグビットがクリアされていれば機能は有効ではないと見なされる。特定される機能が有効ではないと判断される場合、処理はステップ３７０に進み、機能チェックは失敗したものとして示される。
【００８５】
しかしながら、特定される機能が有効であると分かったと仮定すると、一実施例において、関連付けられている機能に与えられる１つ又は複数のパーミッションを参照して１つ又は複数の追加的なチェックを実施することができ、これらのパーミッションの状態は、機能のパーミッションフィールド内に保持される１つ又は複数のパーミッションフラグの値を参照して決定される。
【００８６】
例えば、一実施例において、ステップ３５５において機能に関連付けられる修正可能なパーミッションがクリア状態にあるかどうか判断される。特に、パーミッションフラグは修正可能なパーミッションをエンコードするために使用することができ、修正可能なパーミッションがクリア状態にある場合、これは関連付けられている機能が１つ又は複数の機能修正命令によって修正不可能であることを示すために使用することができる。したがってこれは、機能のプロパティにおいて、それが修正不可能であるとしてマークされた後、その調整を妨げることによって、その特定の機能について向上したセキュリティを提供することができる。例えば、結合ポインタに関連してその結合ポインタによって処理回路に与えられる機能を増やそうとするために、処理回路が通常の動作において範囲を拡張することができない、又はパーミッションフラグをセットすることができない一方で、結合ポインタが修正不可能であるとしてマークされていな場合、処理回路はその結合ポインタに関連付けられる範囲を減らすため及び／又はパーミッションフラグをクリアするためのステップを取ることが可能であり得る。しかしながら、機能が修正不可能としてマークされている場合、処理回路はいかなるそのような調整も行うことができない。
【００８７】
逆に、修正可能なパーミッションがセット状態にある場合、これは処理回路により範囲を減らすこと及び／又はあるパーミッションフラグをクリアすることが、そのような修正を妨げるようなオーバーライド制御情報がないとすれば、できることを示している。
【００８８】
機能チェック動作の一実施例において、ステップ３５５によって示されるように、修正可能なパーミッションがクリア状態にない場合、機能チェックは失敗したと判断される。特に、この実施例において、修正不可能な機能をＰＣＣレジスタにロードした結果として命令セットにおいて変化させることだけが適当であると判断されるが、これは機能が現在の処理による使用のために与えられたため命令セット識別子フィールドの内容は変更されていないという追加的な安心感を与えるからである。
【００８９】
したがって、図８に示される実施例において、修正可能なパーミッションがクリア状態にある場合のみ、処理は機能チェックが成功するような状況に進むことができる。一実施例において、追加的なチェックは必要ないことがあり、したがって、修正可能なパーミッションがクリア状態にあると判断されると処理は直接ステップ３６５に進むことができ、機能チェックが成功したと判断される。しかしながら、代替的な実施例において、１つ又は複数のさらなるチェックが、例えばパーミッションフラグによってエンコードされる１つ又は複数の他のパーミッションの状態を考慮して実施され得る。例えば、ボックス３６０によって示されるように、実行可能なパーミッションがセット状態にあるかどうか判断することができる。実行可能なパーミッションは機能に関連付けられるが、機能がプログラムカウンタ機能レジスタにロードされる時に関連性があるだけである。特に、実行可能なパーミッションは機能がプログラムカウンタ機能を形成する際、メモリから命令をフェッチするために使用できるかどうかを特定する。したがって、ＰＣＣレジスタ内の機能がクリア状態にある実行可能なパーミッションを有する場合、これは機能がメモリから命令をフェッチするために使用されることを妨げられることを示している。したがって、これは分岐命令がＰＣＣレジスタ８０にプログラムカウンタ機能として使用されることを意図されていない機能をロードしようとするために使用されていることを示している。したがって、実行可能なパーミッションがクリア状態にある場合、処理はステップ３７０に進むことができ、機能チェックは失敗していると考えられる。
【００９０】
逆に、実行可能なパーミッションがセット状態にあり、機能がメモリから命令をフェッチするために使用できることを示している場合、いかなるオーバーライド制御情報もその使用を妨げていないとすると、処理はステップ３６５に進むことができ、機能チェックは成功したと判断される。
【００９１】
図９Ａ及び図９Ｂは、機能チェックが成功したと判断された状況において、分岐命令を実行する場合、命令セット識別子フィールド情報を使用するための２つの選択肢を図示している。先の議論から明らかとなるように、機能チェックが成功したと判断される状況において、ソース機能レジスタＣＮ内の機能を使用してＰＣＣレジスタ８０内に新しいプログラムカウンタ機能を形成する。したがって、図９Ａの選択肢１によって示されるように、ソース機能レジスタＣＮ内の特定される機能４００は、新しいＰＣＣ４１０を形成するためにＰＣＣレジスタに複製される。この実施例において、特定される機能４００内の命令セット識別子フィールド４０５はやはりＰＣＣレジスタに複製され、更新されたプログラムカウンタ機能４１０内に新しいフィールド４１５を形成する。この実施例において、処理回路は、命令セットを特定するためにＰＣＣレジスタのフィールド４１５の値を使用するように構成される。したがって、特定される機能４０５内の命令セット識別子が分岐命令が実行される前に使用されていた命令セットとは異なる命令セットを指定する場合、分岐命令が実行され、それに応じてＰＣＣレジスタ８０の内容が更新されていると、フィールド４１５内の更新された情報により命令セット内の変更が起こる。
【００９２】
図９Ｂはソース機能レジスタＣＮ内の特定される機能４２０がやはり本質的にＰＣＣレジスタ８０に複製され、新しいプログラムカウンタ機能４３５を形成する、代替の実施例を図示している。しかしながら、この実施例においては、特定される機能４２０内の命令セット識別子フィールド４２５が抽出され、ＰＣＣレジスタ８０に別個に与えられる命令セット制御レジスタ４３０内に格納される。この実施例において、デフォルトの値は、そうでなければ命令セット識別子フィールドに対応するであろうＰＣＣのフィールド４４０に書き込まれる。一実施例において、ＰＣＣ４３５を使用する際フィールド４４０内の値は参照されず、したがって、あらゆる所望の値にセットすることができる。
【００９３】
一実施例において、命令セット制御レジスタ４３０は、命令セット情報を格納するための別個の専用のレジスタであってもよい。しかしながら、代替的な実施例において、既存のレジスタ、例えば現在の処理状態レジスタ７４内のフィールドによって与えられてもよい。
【００９４】
一実施例において、前述の機能ベースのメカニズムは、命令セットを変更させる唯一のメカニズムであり得る。しかしながら、別の実施例において、命令セットにおける変更を可能にするさらなるメカニズムとして、追加的な、例外ベースのメカニズムが提供されてもよい。図１０において、この処理が概略的に図示されている。ステップ４５０において、例外が取られ、その結果としてステップ４５５においてプロセッサは予め定義された状態に遷移する。例外により、例えば、例外が取られた処理も高いレベルのソフトウェア実行特権を有する、より高い例外レベルへ遷移することができる。一実施例において、例外をハンドリングする際プロセッサによって使用される命令セットが予め定められる。例えば、設定レジスタは予め定義された状態にある間実行される例外ハンドラコードに適用可能な命令セットを指定するために使用することができる。代替的に、先に参照された機能ベクトルベースアドレスレジスタ（ＣＶＢＡＲ）内のフィールドが命令セットを指定するために使用されてもよい。特定の一実例において、ＣＶＢＡＲのビット０がこの目的のために使用されてもよい。別の代替として、命令セットは、特定の命令セットが例外ハンドラコードのために常に使用されるように、全体的に固定されていてもよい。
【００９５】
ステップ４５５において予め定義された状態に遷移しているため、例外から戻った後に使用されるリターン状態を確立すべく、プロセッサは信頼される例外ハンドリングコードを実行する。この処理の間、例外から戻る際に使用されることになる命令セットを、適当な制御レジスタ内でセットすることができる。例えば、命令セットがＰＣＣレジスタ内のフィールドから直接導出される場合、図９Ａを参照して先に議論した実例にしたがって、ＣＥＬＲレジスタ７８の内容はリターンアドレス機能内の関連付けられているフィールドが例外から戻る際に適用されるべき命令セットを特定するように更新され得る。代替的に、図９Ｂの手法が使用される場合、例えば命令セットがＣＰＳＲ７４内のフィールドによって与えられると、例外から戻る際に適用されるべき命令セットを指定するためにＳＰＳＲ７２内の適当なフィールドを信頼されるソフトウェアによって操作することができる。
【００９６】
ステップ４６０に続き、例外から戻るためにステップ４６５においてリターン命令を実行することができる。この処理の一部として、ＣＥＬＲ７８の内容がＰＣＣレジスタ８０に復元され、ＳＰＳＲ７２の内容はＣＰＳＲ７４に復元される。この後、続いてフェッチされた命令は、新しく特定される命令セットにしたがって解釈される。
【００９７】
さらなる実施例において、命令セットを変更するために、１つ又は複数の追加的な制御されるメカニズムを提供することができる一方、特定の一実施例において、本明細書において説明される機能ベースのメカニズム又は例外ベースのメカニズムの使用により命令セットを変更するだけのために、プロセッサが制約されてもよい。
【００９８】
図１１は使用され得る仮想マシンの実装形態を示す。前述の実施例は考慮される技法をサポートする特定の処理ハードウェアを動作させるための装置及び方法の点で本発明を実装している一方、ハードウェアデバイスのいわゆる仮想マシンの実装形態を提供することも可能である。これらの仮想マシンの実装形態は、仮想マシンプログラム５１０をサポートするホストオペレーティングシステム５２０を実行させるホストプロセッサ５３０上で実行する。典型的には、適度な速度で実行する仮想マシンの実装形態を提供するためには大きくパワーのあるプロセッサが要求されるが、そのような手法は一定の状況下で正当化されてもよく、例えば互換性又は再使用目的のために別のプロセッサにとってネイティブなコードを実行する所望がある場合などである。仮想マシンプログラム５１０はコンピュータ可読記憶媒体（非一時的媒体であってもよい）に記憶され得、アプリケーションプログラム５００にアプリケーションプログラムインターフェース（命令実行環境）を提供し、アプリケーションプログラムインターフェースは仮想マシンプログラム５１０によってモデリングされるデバイスである現実のハードウェアによって提供されるであろうアプリケーションプログラムインターフェースと同一のものである。命令セット内の変更を制御するための上述の技法は、仮想マシン環境に実装されてもよい。例えば、仮想マシンで実行するソフトウェア、又は仮想マシンを制御するソフトウェアは、そのような特徴を実装するハードウェアを利用することができる。
【００９９】
上述の実施例から、これらの実施例は機能ベースのアーキテクチャ内で命令セットを変更するための高度に制御され制約される技法を提供することが分かるであろう。そのような技法の使用を通じて、これは命令セットを変更しようとする不注意による又は悪意のある試行に対する保護を与え、ひいては機能ベースのアーキテクチャによって与えられる保護の態様をすり抜けようとするために命令セットにおける変更が使用され得る可能性を緩和する。
【０１００】
本出願において、語句「するように構成される」は、装置の要素が定義される動作を実行することができる構成を有することを意味するために使用される。この文脈において、「構成」はハードウェア又はソフトウェアの内部接続の、配置又はやり方を意味する。例えば、装置は定義される動作を提供する専用のハードウェアを有してもよく、又はプロセッサ若しくは他の処理デバイスはファンクションを実施するためにプログラムされてもよい。「するように構成される」は、定義される動作を提供するために装置要素がいかなるやり方でも変更される必要があることを含意するものではない。
【０１０１】
本発明の図示的な実施例を本明細書において添付の図面を参照して詳細に説明してきたが、本発明はこれらの正確な実施例に限定されず、当業者により添付の特許請求の範囲によって定義されるような本発明の範囲及び精神を逸脱することなく、その様々な変形、付加、及び修正がそこになされ得ることを理解されたい。例えば、本発明の範囲を逸脱することなく、従属請求項の特徴と独立請求項の特徴との様々な組合せが可能である。
【図１】
2020523680.tif 000003
【図２】
2020523680.tif 000004
【図３】
2020523680.tif 000005
【図４】
2020523680.tif 000006
【図５】
2020523680.tif 000007
【図６】
2020523680.tif 000008
【図７】
2020523680.tif 000009
【図８】
2020523680.tif 000010
【図９Ａ】
2020523680.tif 000011
【図９Ｂ】
2020523680.tif 000012
【図１０】
2020523680.tif 000013
【図１１】
2020523680.tif 000014
【国際調査報告】
2020523680.tif 000015
2020523680.tif 000016
2020523680.tif 000017