一部の処理装置は有界ポインタの使用をサポートすることができる。ポインタ自身は、例えば、アクセスされるデータ値又は実行される命令のアドレスを指し示すことができるか、又はそのようなアドレスを決定するために使用することができる。しかしながら、ポインタは、ポインタを使用する際アドレスの許容可能な範囲を示す関連付けられる範囲情報を有することもできる。これは、例えば、ポインタから決定されたアドレスが一定の境界内に留まり、振る舞いのセキュリティ又は機能的な正常性を維持することを保証するために有用であり得る。例えば、所与の処理についてある機能が定義され、定義された機能以外の動作を実行するような試行があるとエラーをトリガすることができる機能ベースのアーキテクチャに対する興味が高まっている。有界ポインタ用の範囲情報は、そのようなアーキテクチャのために定義される機能情報の一部であり得、機能ベースのアーキテクチャ内でそのような有界ポインタ(その関連付けられる機能情報を含む)は、機能と称することができる。
したがって、装置は、ポインタを使用する際、許容可能なアドレスの範囲を示す関連付けられた範囲情報を有するポインタを記憶するために使用される有界ポインタ記憶要素を含むことができる。それぞれの有界ポインタ記憶要素は、汎用メモリ内のレジスタ又はメモリ位置、例えば、スタック・メモリ上の位置であり得る。
ある命令を使用して、ポインタを取得するために、そのような有界ポインタ記憶要素を参照することができ、次いでポインタは命令の動作中に必要とされるメモリ内のアドレスを導出するために使用される。ポインタはメモリ・アドレスを直接特定するために使用することができ、又は例えば、ポインタ値へオフセットを加算することによってメモリ・アドレスを導出するために使用することができる。
一実例の実装形態において、そのような有界ポインタは特定の割り当てられたメモリ領域に関連付けられる。したがって、例えば特定のプロセスによる使用のためなど、いったんメモリ領域が割り当てられてしまうと、そのメモリ領域にアクセスする際に使用するために1つ又は複数の有界ポインタを作成することができ、そして有界ポインタに関連付けられる範囲情報はメモリ領域を形成するメモリ・アドレスの範囲を特定する。メモリ領域内のアドレスにアクセスすることが望ましい場合は、そのような有界ポインタを参照していつでもそのメモリ・アドレスを生成することができ、有界ポインタの使用により、あらゆる生成されたメモリ・アドレスがメモリ領域を形成する許容可能なメモリ・アドレスの範囲内にあるよう制約されることを保証する。特に、有界ポインタが割り当てられたメモリ領域の外でメモリ・アドレスを生成するために使用される場合、フォールトが検出され、アクセスが進行することを妨げられる。
これはセキュリティを向上させる上で非常に有用である一方で、先に言及したように、有界ポインタが、関連付けられるメモリ領域が続けて解放された後アクセス可能なままとなる「use−after−free」問題を生じることがある。プログラミング・エラーに起因してそのような有界ポインタの使用が発生する場合、これはソフトウェアの未定義の振る舞いにつながることがある。別の実例として、その使用がセキュリティ攻撃者によって引き起こされる意図的なアクションとして生じる場合、これは潜在的に情報のセキュリティ・リーク及び/又はリモート・コード実行につながり得る。したがって、有界ポインタが、関連付けられるメモリ領域が解放された後に使用されることを妨げることが望ましいであろう。本明細書において説明される技法は、use−after−free状況が起こる可能性を大きく低減させるメカニズムを提供することを目的としている。
一実例の配置構成において、メモリ内でメモリ領域を割り当てるためのメモリ割り当て回路と、有界ポインタを生成するための有界ポインタ生成回路とを備える装置が提供される。特に、有界ポインタ生成回路は、メモリ領域へのアクセスにおける使用のための少なくとも1つの取り消し可能な有界ポインタを生成するよう構成され、取り消し可能な有界ポインタは、ポインタ値及びメモリ領域のアドレス範囲を特定する範囲情報を与える。
加えて、メモリ割り当て回路(専用のハードウェア又は汎用プロセッサ上で実行するソフトウェアによって形成することができる)は、メモリのヘッダ位置においてメモリ領域用のヘッダを提供するように構成され、ヘッダは格納値がメモリ領域に関連付けられる第1のトークン値に初期化される第1のトークン・フィールドを有する。ヘッダ位置は、取り消し可能な有界ポインタによって与えられる範囲情報から導出可能であり、ひいては有界ポインタが使用される際ヘッダを配置できるようにしており、それにより取り消し可能な有界ポインタを使用させるのに先立って、ヘッダを参照してハードウェアでチェックを行うことを可能にしている。
メモリ割り当て回路は続いて起こるメモリ領域の解放に応答して、ヘッダの第1のトークン・フィールド内の格納値を修正し、その結果として第1のトークン値をもはや格納していない。
取り消し可能な有界ポインタを使用してメモリ・アドレスを生成するためのリクエストに応答して、第1のトークン・フィールド内の格納値が変更されていると判断される場合、使用認可チェックはメモリ・アドレスの生成を妨げるよう構成される。
そのような手法によって、取り消し可能な有界ポインタがメモリ・アドレスを生成するために使用される時に、ヘッダの第1のトークン・フィールド内の格納値が修正されている場合は、使用認可チェックがアクセスを妨げる。これは、use−after−free状況が起こる可能性を大きく阻害する単純で効果的なメカニズムを提供し得ることが見出されている。
使用認可チェックがメモリ・アドレスの生成を妨げることができる多くの方法がある。一実例の実装形態において、使用認可チェックは、第1のトークン・フィールド内の格納値が変更されていると判断される場合、取り消し可能な有界ポインタを無効にするように構成され、それによりメモリ・アドレスが生成されることを妨げる。
使用認可チェックがヘッダの第1のトークン・フィールド内の格納値が修正されているどうかを判断できるやり方は、実装形態に応じて変わることができる。しかしながら、一実例において、取り消し可能な有界ポインタは、第1のトークン値を格納するように構成され、取り消し可能な有界ポインタを使用してメモリ・アドレスを生成するためのリクエストに応答して、使用認可チェックは、ヘッダ位置を決定するため、及び取り消し可能な有界ポインタ内に格納された第1のトークン値とヘッダの第1のトークン・フィールド内の格納値との間に一致がない場合に取り消し可能な有界ポインタを無効にするために範囲情報を採用するように構成される。
そのような手法によって、取り消し可能な有界ポインタがメモリ・アドレスを生成するために使用される時、取り消し可能な有界ポインタ内に与えられた第1のトークン値がヘッダの第1のトークン・フィールドの内容にまだ一致するかどうか判断するためにハードウェアでチェックを行うことができる。上の議論から明らかなように、メモリ領域の解放後、これはもはや当てはまらず、したがって関連付けられるメモリ領域が解放された後に取り消し可能な有界ポインタを使用する試行がなされる状況が検出され得、この時点で取り消し可能な有界ポインタは、その取り消し可能な有界ポインタの使用を妨げるよう無効にされることができ、ひいてはリクエストされたアクセスが行われることを妨げる。
代替的な実装形態において、第1のトークン値は取り消し可能な有界ポインタそれ自身内で再現することはできず(例えば、取り消し可能な有界ポインタ内に第1のトークン値を収容するための十分な空きがないことに起因して)、他のメカニズムを使用してヘッダの第1のトークン・フィールド内の格納値がいつ修正されたかを検出することができる。そのような実装形態において、第1のトークン値は本明細書において後に第2のトークン値と称されるトークン値の形態を取ることができ、そのトークン値における修正の検出は本明細書において第2のトークン値に関して後に詳細に議論するのと同一の方法で行うことができる。
第1のトークン値は様々な方法で生成することができるが、一実例の実装形態において、装置は第1のトークン値を生成するためのトークン生成回路をさらに備える。特定の一実例において、トークン生成回路は疑似乱数生成器であり、この時第1のトークン値は割り当てられたメモリ領域及び関連付けられている取り消し可能な有界ポインタに関する使用のために生成された疑似乱数である。
いくつかの実装形態において、有界ポインタ生成回路は上述の取り消し可能な有界ポインタだけでなく、第1のトークン値を利用しない他の有界ポインタも生成するように構成することができる。異なるタイプの有界ポインタを区別することを支援するために、有界ポインタ生成回路は、それぞれ生成された有界ポインタ内に取り消し可能フィールドを提供するように構成され、取り消し可能フィールドは生成された有界ポインタが取り消し可能な有界ポインタである場合にセットされる。取り消し可能フィールドがセットされ、また有界ポインタがメモリ・アドレスを生成するために使用される場合、取り消し可能な有界ポインタが使用されるのに先立って上述の使用認可チェックをハードウェアで実施することができ、この時取り消し可能な有界ポインタによって与えられる第1のトークン値と関連付けられるメモリ領域用のヘッダの第1のトークン・フィールド内の格納値との間に一致がない場合、取り消し可能な有界ポインタは無効にされる。
有界ポインタはシステム内の様々な場所に格納することができる。一実例の配置構成において、装置は有界ポインタ・レジスタのセットを備え、それぞれの有界ポインタ・レジスタはメモリ・アドレスを生成することにおける使用のための有界ポインタを格納するように構成される。装置の処理回路が命令を実行しており、これらの命令の実行がメモリ・アドレスが有界ポインタを使用して生成されることを要求する場合、有界ポインタ・レジスタのうち指定された1つの内部で関連する有界ポインタにアクセスすることができる。有界ポインタ・レジスタは、有界ポインタを格納するための専用のレジスタ、又は有界ポインタを含む様々なタイプのデータを格納することができる汎用レジスタであることができる。
一実例において、有界ポインタは有界ポインタ・レジスタとメモリとの間を移動することができ、或いは実際にはレジスタからメモリに複製されるか、又はその逆であり、そのためすべての有界ポインタがあらゆる特定の時点で有界ポインタ・レジスタのうちの1つに存在するわけではない。
第1のトークン値が取り消し可能な有界ポインタ内に格納される実装形態において、第1のトークン値のサイズは取り消し可能な有界ポインタ内で第1のトークン値を保持するために利用可能な空間によって制約される。特に、一実例の配置構成において、第1のトークン値はそうでなければ使用されない有界ポインタの一部に配置される。いくつかの実装形態において、有界ポインタ内に格納され得る第1のトークン値のサイズは「use−after−free」状況に対する十分なレベルの保護を与えることができる。しかしながら、トークン値へ割り当てられるビット数が大きくなればなるほどuse−after−freeシナリオに対するメカニズムが堅牢となる。例えば、特定のメモリ領域で使用するためのランダムなトークン値が生成される場合、トークン値が大きくなればなるほど、有界ポインタがまだアクティブであり得る同一のトークン値が先に割り当てられた別のメモリ領域で使用するために生成される見込みは小さくなり、それにより、先に割り当てられたメモリ領域が解放された後に、その既存の有界ポインタが後に割り当てられるメモリ領域にアクセスするために使用される可能性は小さくなる(これは事実上、妨げられることが望ましい別のタイプのuse−after−freeアクセスである)。
一実例の実施例において、効果的なトークンのサイズを大きくすることが望ましい場合、第2のトークン値を第1のトークン値と組み合わせて使用することができ、ヘッダは第1のトークン値及び第2のトークン値の両方を保持するが、第2のトークン値自身は、その第2のトークン値を収容するための空間の欠如のため、取り消し可能な有界ポインタ内に与えられない。
特に、一実例の配置構成において、ヘッダはメモリ領域に関連付けられる第2のトークン値を格納するように構成される第2のトークン・フィールドをさらに備え、第2のトークン値は有界ポインタ生成回路によって生成された取り消し可能な有界ポインタにはなく、第2のトークン値が変更されていると判断される場合、使用認可チェックは取り消し可能な有界ポインタを無効にするように構成される。
使用認可チェックが、第2のトークン値がいつ変更されたかを判断することができる方法は複数ある。例えば、一実装形態において、装置は有界ポインタ・レジスタのセットに関連して提供される追加的な記憶装置を備え、取り消し可能な有界ポインタが選択された有界ポインタ・レジスタに格納される場合、追加的な記憶装置は選択された有界ポインタ・レジスタに関連して、ヘッダの第2のトークン・フィールド内で初期化された第2のトークン値を特定するように構成される。したがって、そのような実装形態によると、第2のトークン値はヘッダ領域に格納され、追加的な記憶装置は有界ポインタのセットに関連して提供され、そのため取り消し可能な有界ポインタが有界ポインタ・レジスタのうちの1つに格納される場合、追加的な記憶装置はそれに関連して第2のトークン値を維持することができ、したがって、第1及び第2のトークン値の両方をヘッダ内に保持される対応する値と比較することができるように先に議論した使用認可チェックを拡張することができ、これらのトークン値のいずれかがヘッダ内の対応する値と一致しない場合は取り消し可能な有界ポインタを無効にすることができる。
したがって、そのような一実例の配置構成において、使用認可チェックは選択された有界ポインタ・レジスタに格納された取り消し可能な有界ポインタを使用してメモリ・アドレスを生成するためのリクエストにさらに応答して、ヘッダ内に格納された第2のトークン値と、選択された有界ポインタ・レジスタに関連する追加的な記憶装置内に格納された第2のトークン値との間に一致がない場合に取り消し可能な有界ポインタを無効にする。したがって、先に言及したように、取り消し可能な有界ポインタを使用し続けるべきか、取り消すべきかどうか判断する際、第1のトークン値及び第2のトークン値の両方を参照することができる。
追加的な記憶装置は様々な方法で設けることができる。例えば、追加的な記憶装置内に格納されるそれぞれの第2のトークン値を有界ポインタ・レジスタのうちの特定の1つに関連付けるメカニズムがあるとすれば、有界ポインタ・レジスタのセットを提供する記憶装置とは物理的に別個であってもよい。代替的に、追加的な記憶装置は、有界ポインタ・レジスタのセットを提供する同一の記憶装置構造体によって設けることができ、追加的な記憶装置が有界ポインタ・レジスタのそれぞれに拡張を与え、有界ポインタをそこに記憶するだけでなく、第2のトークン値に関連付けることを可能にしているとみなすことができる。
セキュリティを向上させるため、また特に第2のトークン値が改竄される潜在的なリスクを軽減させるため、追加的な記憶装置は装置で実行中の1つ又は複数のタイプのソフトウェアにアクセスできないように構成することができる(一実装形態において、これは装置で実行中のすべてのソフトウェアであり得る)。したがって、追加的な記憶装置はハードウェア制御の直下にポピュレートされ、使用認可チェックを実施する際ハードウェアによって参照される。
代替的な実装形態において、追加的な記憶装置は要求されないこともある。例えば、装置はヘッダの第1のトークン・フィールド及び第2のトークン・フィールドのうち少なくとも1つに対して、書き込み動作がいつなされたかを特定するための通知メカニズムを備え、それにより第1のトークン値又は第2のトークン値のいずれかが変更されている場合に取り消し可能な有界ポインタを無効にするために使用認可チェックを可能にする。通知メカニズムは様々な形態を取ることができるが、一実装形態において、キャッシュ・コヒーレンシ・プロトコルに基づいており、ヘッダは装置のキャッシュ内でキャッシュされる。
第1のトークン及び第2のトークンの両方を採用するいくつかの実装形態において、続いて起こるメモリ領域の解放において、メモリ割り当て回路は、ヘッダの第1のトークン・フィールドに格納される値を修正するだけでなく、ヘッダの第2のトークン・フィールドに格納される値を修正するように構成することができるため、その後は第1のトークン値も第2のトークン値も、メモリ領域が解放された後に取り消し可能な有界ポインタに関連して維持される情報に一致するべきではない。
第2のトークン値は様々な方法で生成することができるが、一実装形態では、第1のトークン値を生成するようにも構成されるトークン生成回路を使用して生成される。したがって、一実例の実装形態において、第2のトークン値はやはりメモリ領域に関連して使用するために生成される疑似乱数である。
第1のトークン値に加えて第2のトークン値が使用される実装形態においては、取り消し可能な有界ポインタが有界ポインタ・レジスタからメモリに格納し戻される場合、第2のトークン値を示す情報をどのように維持するかという問題が生じる。先に言及したように、第2のトークン値自身は取り消し可能な有界ポインタの部分を形成せず、したがって取り消し可能な有界ポインタがメモリに格納される際、第2のトークン値はメモリに格納される取り消し可能な有界ポインタの部分を形成しない。一実例の実装形態によると、この問題はエンコード演算の使用により対処される。
特に、一実装形態において、ヘッダは、取り消し可能な有界ポインタの一部分の複製を格納するように構成され、装置は、取り消し可能な有界ポインタが選択された有界ポインタ・レジスタからメモリに格納される際、取り消し可能な有界ポインタの部分を第2のトークン値を使用して、取り消し可能な有界ポインタの部分が第2のトークン値及びエンコードされた取り消し可能有界ポインタを使用して再作成されることを可能にするやり方でエンコードすることによりエンコードされた取り消し可能有界ポインタを作成するためにエンコード演算を実施し、その後エンコードされた取り消し可能有界ポインタをメモリに格納するように構成される、コーディング制御回路をさらに備える。したがって、取り消し可能な有界ポインタはエンコードされた形態でメモリ内に格納される。後に、エンコードされた形態はメモリから取り出し、有界ポインタ・レジスタに格納するのに先立ってデコードすることができる。デコード演算が成功したとすると(ヘッダ内に格納される取り消し可能な有界ポインタの部分の複製に一致するデコードされた部分を作り出すために、ヘッダ内の第2のトークン値を使用して取り消し可能な有界ポインタのエンコードされた部分をデコードすることを必要とする)、デコードされる取り消し可能な有界ポインタを、先の使用認可チェックをパスすれば、続いて起こるメモリのアクセス動作に使用することができる。
ヘッダ内に格納される取り消し可能な有界ポインタの部分の複製があらゆる適切なフォーマットで記憶され得ることを了解されたい。したがって、取り消し可能な有界ポインタ内で使用される元々のフォーマットで記憶することができるが、所望であれば代替的に異なるフォーマットで記憶することができる(例えば、取り消し可能な有界ポインタに格納される対応するビットの、ビット方向に反転したバージョンとして記憶することができる)。
第1のトークン値は追加的に所望であればエンコード演算の間使用することができ、その場合、やはり対応するデコード演算を実施する際に参照される。
ヘッダ内に格納された複製を有する取り消し可能な有界ポインタの部分は様々な形態を取ることができるが、一実例の実装形態において、メモリ領域の現在の割り当てられたインスタンスのために生成されたあらゆる有界ポインタに共通する一部である。取り消し可能な有界ポインタ内には、メモリ領域の現在の割り当てられたインスタンスのために生成されたあらゆる有界ポインタに共通する、複数のフィールドが存在することになる。これは、例えば、メモリ領域の範囲を特定するために使用される範囲情報を含むが、一定のパーミッション・ビットも含むことができる。特定の一実例において、複製がヘッダ内に格納される取り消し可能な有界ポインタの部分は、ヘッダ位置を特定するために必要とされない範囲情報の少なくとも一部分を含む。ヘッダ位置を特定するために必要とされない範囲情報の一部を排除することにより、これは必要とされるデコード演算を実施するのに先立ってヘッダ位置を特定できるようにする。
範囲情報は様々な形態を取ることができるが、一実装形態において、メモリ領域についてのベース・アドレス及びリミット・アドレスを含み、ヘッダ位置は、ベース・アドレス及びリミット・アドレスのうちの1つを使用して決定され、複製がヘッダに格納される取り消し可能な有界ポインタの部分はベース・アドレス及びリミット・アドレスのうちのもう一方を特定する。
先に言及したように、複製がヘッダ内に格納される取り消し可能な有界ポインタの部分は、他の情報、例えば取り消し可能な有界ポインタ内で指定される少なくとも1つ又は複数のパーミッションを示す情報を含むこともできる。実際、具体的な一実装形態において、例えばエンコード/デコード演算においてパーミッション・ビットだけがエンコード/デコードされる場合、ヘッダ内に複製が格納されるのはパーミッション情報だけの場合がある。
この時、コーディング制御回路は、ヘッダの第2のトークン・フィールドに格納された値(及び、第1のトークン値もエンコード演算に使用された場合は、第1のトークン・フィールドに格納された値)を使用して取り消し可能な有界ポインタのエンコードされた部分をデコードするためのデコード演算を実施することによって、取り消し可能有界ポインタをデコードして、取り消し可能な有界ポインタの再作成された部分を作り出し、次いで取り消し可能な有界ポインタの再作成された部分が、ヘッダに格納された取り消し可能な有界ポインタの部分の複製に一致するかどうかを判断するためのチェック動作を実施するように構成することができる。特に、エンコードされていない範囲情報の部分を使用してヘッダ位置を特定することができ、ひいてはヘッダの内容を取り出せるようにしており、その後第2のトークン・フィールド(任意選択で第1のトークン・フィールドも)に格納された値を使用して取り消し可能な有界ポインタのエンコードされた部分をデコードすることができる。第2のトークン・フィールド内に格納された値がなお第2のトークン値である(また、第1のトークンもエンコード/デコードのプロセスに使用されている場合は、第1のトークン・フィールドに格納された値がなお第1のトークン値である)とすると、再作成された部分はまだヘッダに格納された取り消し可能な有界ポインタの複製された部分に一致するべきである。しかしながら、例えば関連付けられるメモリ領域が解放されているためなど、ヘッダが変更されている場合、デコード演算はヘッダ内に格納された取り消し可能な有界ポインタの複製された部分に一致する取り消し可能な有界ポインタの再作成された部分を作り出さない。そのような状況が生じる場合、コーディング制御回路は取り消し可能な有界ポインタを無効にするように構成することができる。加えて、一実装形態において、いったん取り消し可能な有界ポインタがデコードされてしまうと、取り消し可能な有界ポインタ内の第1のトークン値がヘッダの第1のトークン・フィールド内の格納値に一致することを確実にするためにチェックがやはり実施され、これに当てはまらない場合、取り消し可能な有界ポインタはやはり無効にされる。
デコード演算は様々な理由でトリガされることがある。一実例の実装形態において、コーディング制御回路は、エンコードされた取り消し可能有界ポインタがメモリから有界ポインタ・レジスタのうちの1つにロードされる時はいつでもデコード演算を実施するように構成される。したがって、そのような実装形態において、取り消し可能な有界ポインタは、メモリに格納される時はいつもエンコードされ、メモリから有界ポインタ・レジスタに取り出される時はいつもデコードされる。
しかしながら、代替的な実装形態において、エンコードされた取り消し可能有界ポインタを、それをデコードすることなく、有界ポインタ・レジスタに取り出すことも可能である。例えば、これにより有界ポインタがデコードのステップ及び対応するエンコードのステップを実施することを要求することなく、メモリ位置同士で複製できる。しかしながら、そのような実装形態において、エンコードされた有界ポインタをメモリ・アクセス動作を実施するために使用することができないことを保証する必要がある。したがって、そのような一実装形態において、それぞれの有界ポインタは、取り消し可能な有界ポインタがいつエンコードされたかを示すようにセットされるエンコード・フィールドを含む。ひいては、これにより処理ハードウェアが、有界ポインタ・レジスタ内に格納されており、まだエンコードされた形態にある取り消し可能な有界ポインタ(したがって、メモリ・アクセスに使用することができない)と、デコードされた形態にある取り消し可能な有界ポインタ(したがって、使用認可チェックをパスすれば、潜在的にメモリ・アクセスに使用することができる)とを区別できる。
そのような実施例において、エンコードされた取り消し可能有界ポインタは、その取り消し可能な有界ポインタがメモリ・アドレスを生成するために使用されるのに先立って、コーディング制御回路によってデコードされる必要がある。
ヘッダ位置がメモリ領域についての範囲情報から特定できるとすれば、関連付けられるメモリ領域に対するヘッダの物理的な位置は、様々な形態を取ることができる。一実例の実装形態において、ヘッダ位置は、割り当てられたメモリ領域の直前の一連のメモリ・アドレス、又は割り当てられたメモリ領域より固定オフセット前の一連のメモリ・アドレス;割り当てられたメモリ領域の直後の一連のメモリ・アドレス、又は割り当てられたメモリ領域より固定オフセット後の一連のメモリ・アドレス;メモリ領域のアドレスに基づく計算の実施により決定される位置における一連のメモリ・アドレス;のうちの1つであるように、メモリ領域に対して構成される。
一実装形態においてヘッダを保持するために使用される一連のメモリ・アドレスは、ソフトウェア・アドレッシング可能であり得る一方で、代替的な実装形態においては、ヘッダ位置は装置で実行中の少なくともいくつかのタイプのソフトウェアによってアドレッシング可能ではないメモリの一部分の内部にあり得る。例えば、ヘッダは非ソフトウェア・アドレッシング可能メモリ・ビットから形成することができる(例えば、ECCビットがデータ値に関連して記憶され得る方法と同様に)。所望であれば、ヘッダ位置は一定の特権を与えられたソフトウェア(カーネル、及び可能性としては適切なレベルの特権を有する1つ又は複数の他のソフトウェア・コンポーネントなど)によってアクセス可能であり得るが、低い特権を与えられたソフトウェアにはアクセスすることができない(例えば、ユーザ空間のソフトウェア)。
さらなる実例として、ヘッダ位置は、割り当てられたメモリ領域を含むアドレス空間とは別個のアドレス空間内で表現可能であり得る。そのような配置構成において、別個のアドレス空間はなおソフトウェアによってアドレッシング可能であり得るが、通常のアドレス空間がアドレッシングされるやり方とは異なるやり方においてである(例えば、この別個のアドレス空間をアドレッシングすることは、特殊なCPU命令を使用することを必要とすることがある)。そのような配置構成では、別個のアドレス空間内のヘッダ位置は、割り当てられたメモリ領域の範囲情報を使用して配置することができるように、さらに構成され得る。
ヘッダが、装置で実行中の一定のタイプのソフトウェアによってアドレッシング可能ではないメモリの一部分の内部にある場合、これはそのソフトウェアがヘッダ情報を修正するあらゆる潜在的なリスクを回避することによりさらにセキュリティを向上させることができる。
一実装形態において、複製がヘッダ内に格納される取り消し可能な有界ポインタの一部分は予め定めることができる。しかしながら、代替的に、取り消し可能な有界ポインタのどのビットがヘッダ内に格納される取り消し可能な有界ポインタの複製された部分を形成するために使用されたかを特定するために、ヘッダ内に制御フィールドが提供され得る。これは、先述のエンコード及びデコード演算における使用について、ヘッダ内に維持される取り消し可能な有界ポインタのビットの選択に関して構成可能性のレベルを設けることができる。特定の一実装形態において、制御フィールドは第1及び/又は第2のトークン・フィールドの一部分によって少なくとも部分的に提供され得、それによって例えば第1/第2のトークン値の第1の部分はエンコード/デコードを実施する際「暗号化鍵」として使用され、別の部分は(可能性としては第1の部分と重なる)取り消し可能な有界ポインタのどのビットがエンコード/デコードされるかを判断するための制御フィールド値として使用される。
使用認可チェックを実施する際、ヘッダ情報を取得するために必ずしもそのメモリがアクセスされる必要はないことに留意すべきである。例えば、装置はヘッダの第1のトークン・フィールド内の格納値の複製を維持するように構成されるキャッシュ構造をさらに備え(また任意選択で、第2のトークンを使用する実装形態では、第2のトークン・フィールド内に格納される値)、第1のトークン・フィールド内の格納値が変更されていると判断する場合、使用認可チェックはキャッシュ構造に維持される複製を参照するように構成される。現代的なデータ処理システムでは、キャッシュ・コヒーレンシ・スキームを使用して、様々なキャッシュによってシステム内に維持される内容は、そこにキャッシュされたデータの最新のバージョンを表すことを保証しており、それによってヘッダの内容がキャッシュされてあると、これらのキャッシュされた内容は、使用認可チェックが実施される時点でなお有効であり、次に第1のトークン・フィールド内の格納値が変更されているかどうかを判断するために、これらのキャッシュ内容を使用することができる。したがって、これは使用認可チェックを実施するためにかかる時間を大いに削減することができる。
実際、一部のシステムでは有界ポインタを使用するコア(このコアは、以下で現在のコア、と称する)が、キャッシュ・コヒーレンシ・スキームがヘッダのキャッシュされたバージョンへ更新を通知するまで、又は現在のコアがヘッダを更新するまで、使用認可チェックを実施することをすべて回避することが可能な場合がある。例えば、いったん有界ポインタが有界ポインタ・レジスタにロードされ、対応するヘッダがキャッシュ内に格納されると、キャッシュ・コヒーレンシ・スキームは有界ポインタに関連付けられるヘッダへの書き込みを追跡することができる。したがって、例えば別のコアがヘッダを含む位置に書き込みを行うと、これはコヒーレンシ無効化のリクエストを現在のコアに送信させることになり、したがって、このメカニズムにより現在のコアはヘッダの可能な変更を示すメッセージを受信する。結果として、別のコアによる更新に起因してそのようなコヒーレンシ無効化のリクエストを受信するまで、又はヘッダそれ自身に書き込みを行うそのような時間までは、その時間より前はヘッダが変更されていないことが既知であるため、認可チェックの実施を回避することができる。ヘッダに対していったん変更がなされると、使用認可チェックは取り消し可能な有界ポインタが無効にされると判断するように構成され得る。
上述のメカニズムを使用する取り消し可能な有界ポインタの提供が非常に有用であり得る多くの実例の使用事例がある。一実例の使用事例において、装置は、取り消し可能な有界ポインタをさらなる装置に提供するように構成し、さらなる装置によってメモリ領域へのアクセスを制御し、さらなる装置は使用認可チェックを実施するように構成され、それにより装置がメモリ領域を解放した後、さらなる装置はメモリ・アドレスを生成するための取り消し可能な有界ポインタのさらなる使用を妨げられる。したがって、そのような手法によって、装置は別の装置に渡すことができる有界ポインタを作成することができ、上述のメカニズムでは、いったん装置が関連するメモリ領域を解放すると決定すると、さらなる装置はもはや与えられた有界ポインタを使用することができないこと、特に関連付けられるメモリ領域が解放された後に有界ポインタを使用しようとするあらゆる試行がなされると有界ポインタが取り消されること、を保証する。
次に、図面を参照して特定の実例を説明する。
図1は命令を処理するための処理パイプライン4を備えるデータ処理装置2の実例を概略的に図示している。この実例において、処理パイプライン4は、フェッチ工程6、デコード工程8、発行工程10、実行工程12、及びライトバック工程14を含む複数のパイプライン工程を含むが、他のタイプの工程又は工程の組み合わせが提供されてもよいことを了解されたい。例えば、いくつかの実装形態ではレジスタのリネームを実施するためのリネーム工程を含むことができる。処理される命令は工程から工程へと移動し、命令がある工程で待ち状態にある間、別の命令はパイプライン4の異なる工程で待ち状態にあり得る。
フェッチ工程6はレベル1(L1:Level 1)の命令キャッシュ20から命令をフェッチする。フェッチ工程6は普通、連続する命令アドレスから逐次に命令をフェッチすることができる。しかしながら、フェッチ工程はまた分岐命令の結果を予測するための分岐予測器22を有することがあり、フェッチ工程6は、分岐すると予測される場合は(非逐次)分岐ターゲット・アドレスから、又は分岐しないと予測される場合は次の連続するアドレスから、命令をフェッチすることができる。分岐予測器22は、ある分岐が取られそうか、又は取られそうにないかを予測するための情報を格納するための1つ又は複数の分岐履歴テーブルを含むことができる。例えば分岐履歴テーブルは、前に実行された分岐の実際の結果を追跡するための、又は分岐についてなされた予測についての信頼度を表すカウンタを含むことができる。分岐予測器22はまた分岐命令の前のターゲット・アドレスをキャッシュするための分岐ターゲット・アドレス・キャッシュ(BTAC:Branch Target Address Cache)24を含むことができ、それによって同一の分岐命令との後続の遭遇の際、これらが予測され得る。
フェッチされた命令は、命令をデコードしてデコード命令を生成するためのデコード工程8に渡される。デコード命令は適当な処理演算を実行するために実行工程12を制御するための制御情報を含むことができる。キャッシュ20からフェッチされたいくつかのより複雑な命令について、デコード工程8はこれらの命令を複数のデコード命令にマッピングすることができ、これはマイクロ命令(μop又はuop)として知られ得る。したがって、L1の命令キャッシュ20からフェッチされた命令とパイプラインの後方の工程で見られる命令との間には1対1関係がなくてもよい。一般的には、本出願における「命令」との称し方はマイクロ命令を含むものとして解釈するべきである。
デコード命令は発行工程10に渡され、命令の実行に必要なオペランドが利用可能かどうかを判断し、オペランドが利用可能であれば実行のため命令を発行する。いくつかの実装形態はインオーダー処理をサポートしていることがあり、それによって、命令がL1の命令キャッシュ20からフェッチされたプログラム順序に対応する順序での実行のために、命令が発行される。他の実装形態はアウトオブオーダー実行をサポートしていることがあり、それによって命令は、プログラムの順序とは異なる順序で実行工程12に発行され得る。前方の命令がオペランドを待ってストールしている間、オペランドが利用可能であるプログラムの順序において後方の命令を先に実行できるため、アウトオブオーダー処理はパフォーマンスを改善するために有用であり得る。
発行工程10は命令を実行工程12に発行し、ここで命令は様々なデータ処理演算を実行するために、実行される。例えば、実行工程は、整数値に対して算術又は論理演算を実行するための算術/論理ユニット(ALU:Arithmetic/Logic Unit)30、浮動小数点形式で表現される値に対して演算を実行するための浮動小数点(FP:Floating−Point)ユニット32、及びレベル1(L1)のデータ・キャッシュ36からのデータ値をレジスタ40にロードするためのロード演算、又はレジスタ40からのデータ値をL1のデータ・キャッシュ36に格納するためのストア演算を実行するためロード/ストア・ユニット34を含む複数の実行ユニット30、32、34を含むことができる。これらは、設けることができる実行ユニットのいくつかの実例のタイプに過ぎず、多くの他の種類も設けることができることを了解されたい。処理演算を実行するために、実行工程12はデータ値をレジスタ40のセットから読み出すことができる。実行された命令の結果は次いでライトバック工程14によってレジスタ40に書き戻すことができる。
L1の命令キャッシュ20及びL1のデータ・キャッシュ36は、複数のキャッシュのレベルを含むキャッシュ・ヒエラルキの一部であってもよい。例えば、レベル2(L2:Level 2)のキャッシュ44をやはり設けることができ、任意選択でさらなるレベルのキャッシュが設けられてもよい。この実例において、L2のキャッシュ44はL1の命令キャッシュ20とL1のデータ・キャッシュ36との間で共有されるが、他の実例は別個のL2の命令及びデータ・キャッシュを有することができる。フェッチされることになる命令がL1の命令キャッシュ20にない場合、L2のキャッシュ44からフェッチすることができ、同様に命令がL2のキャッシュ44にない場合、メイン・メモリ50からフェッチすることができる。同様に、ロード命令に応答して、データはL1のデータ・キャッシュ36にない場合L2のキャッシュ44からフェッチすることができ、必要であればメモリ50からフェッチすることができる。あらゆる既知のスキームがキャッシュ・ヒエラルキを管理するために使用され得る。
プログラム命令及びデータ値を参照するためにパイプライン4によって使用されるアドレスは、仮想アドレスであってもよいが、少なくともメイン・メモリ50、及び任意選択でやはり少なくともキャッシュ・ヒエラルキのいくつかのレベルは、物理的にアドレッシングされ得る。したがってトランスレーション・ルックアサイド・バッファ(TLB:Translation Lookaside Buffer)52が、パイプライン4によって使用される仮想アドレスを、キャッシュ又はメモリにアクセスするために使用される物理アドレスにトランスレートするために設けられてもよい。例えば、TLB52はそれぞれが仮想アドレス空間の対応するページの仮想ページ・アドレスを指定する複数のエントリを含むことができ、仮想ページがアドレッシングする対応する物理ページ・アドレスは、対応するページ内の仮想アドレスを物理アドレスにトランスレートするためにマッピングされるべきである。例えば、仮想及び物理ページ・アドレスは対応する仮想アドレス及び物理アドレスの最上位部分に対応することができ、この時残りの最下位部分は仮想アドレスを物理アドレスにマッピングする際変更されないままである。アドレス・トランスレーション情報と同様に、それぞれのTLBエントリはまた、アドレスのあるページがパイプライン4のあるモードでアクセス可能かどうかを示すことなどのアクセス・パーミッションを指定する何らかの情報を含むことができる。いくつかの実装形態において、TLBエントリはまた、キャッシュ・ヒエラルキのどのレベルが読み出し若しくは書き込み動作に応じて更新されるかを定義するキャッシュ・ポリシ情報(例えば、キャッシュがライトバック又はライトスルー・モードで動作すべきであるかどうか)、又は対応するページ内のアドレスへのデータ・アクセスがメモリ・システムによって、データ・アクセスがパイプライン4によって発行された順序と比べてリオーダすることができるかどうかを定義する情報、などのアドレスの対応するページの他のプロパティを定義することができる。
図1が単一のレベルのTLB52を示す一方、TLBのヒエラルキがレベル1(L1)のTLB52が複数の最近アクセスされたページ内のアドレスをトランスレートするためのTLBエントリを含み得るように提供され得、またレベル2(L2)のTLBが多数のページについてのエントリを格納するために提供され得ることを了解されたい。必要とされるエントリがL1のTLBに存在しない場合、L2のTLBから、又はヒエラルキ内のさらなるTLBからフェッチすることができる。アクセスされることになるページについて必要とされるエントリがTLBのうちいずれにもない場合、メモリ50のページ・テーブルにアクセスするためにページ・テーブル・ウォークを実施することができる。本技法では、あらゆる既知のTLB管理スキームを使用することができる。
また、いくつかのシステムは複数のレベルのアドレス・トランスレーションをサポートすることができ、それによって、例えば、第1のTLB(又はTLBのヒエラルキ)は仮想アドレスを中間アドレスにトランスレートするために使用することができ、また1つ又は複数のさらなるTLBを使用するアドレス・トランスレーションの第2のレベルが、次いで中間アドレスをキャッシュ又はメモリにアクセスするために使用される物理アドレスにトランスレートできることを了解されたい。これは例えば、アドレス・トランスレーションの第1のレベルがオペレーティング・システムによって管理され得、アドレス・トランスレーションの第2のレベルがハイパーバイザによって管理され得る場合の仮想化をサポートするために有用であり得る。
図1に示すように、装置2は有界ポインタ・レジスタ60のセットを有することができる。有界ポインタ・レジスタのセットは図1において汎用データ・レジスタ40のセットとは物理的に別個であるように示されるが、一実装形態においては汎用データ・レジスタ及び有界ポインタ・レジスタの両方を提供するために同一の物理記憶装置が使用されてもよい。
それぞれの有界ポインタ・レジスタ60は、アクセスされることになるデータ値のアドレスを決定するために使用され得るポインタ値62、及び対応するポインタ62を使用する際アドレスの許容範囲を指定する範囲情報64を含む。有界ポインタ・レジスタ60はまたポインタの使用に関して1つ又は複数のリストリクション/パーミッションを定義することができるリストリクション情報66(本明細書ではパーミッション情報とも称する)を含むことができる。例えば、リストリクション66は、ポインタ62を使用し得る命令のタイプ、又はポインタが使用され得るパイプライン4のモードを制限するために使用することができる。したがって、範囲情報64及びリストリクション情報66は、ポインタ62が使用できる機能を定義すると考えられ得る。定義された機能以外でポインタ62を使用する試行がなされると、エラーがトリガされ得る。範囲情報64は例えば、ポインタがある既知の境界内に留まっており、重要又はセキュアな情報を含み得るメモリ・アドレス空間の他のエリアに迷い込んでいないことを保証することのために有用であり得る。汎用データ・レジスタ及び有界ポインタ・レジスタの両方のために同一の物理記憶装置が使用される一実装形態において、その時一実装形態においてポインタ値62は例えば対応する汎用レジスタについて使用されるのと同一の記憶装置の位置に格納され得る。
図2は、許容範囲が、データ又は命令への認可されていないアクセスに対して保護するために使用される命令のタイプの実例を示す。図2の上部で示すように、特定の有界ポインタ・レジスタPR(Pointer Register)1は所与のポインタ値62及び範囲情報64を含み、この実例においては許容範囲の下位境界を定義する下位境界アドレス68、及び許容範囲の上位境界を定義する上位境界アドレス69を使用して指定されている。例えば、境界68、69はアドレス範囲80000から81000を定義するために設定される。ある命令が有界ポインタ・レジスタPR1参照し、ポインタ62から決定されるアドレスがこの範囲の外にある場合、エラーがトリガされ得る。
例えば、図2のパートAで示されるように、いくつかのシステムではポインタ・レジスタ60内のポインタ62の値を範囲情報64によって指定される範囲の外にある値に設定しようとする試行があるとエラーがトリガされ得る(ここではポインタがアドレスを直接指定すると仮定している)。これはポインタ62が指定された範囲の外のあらゆる値を取ることを回避し、それによって、ポインタを使用するあらゆるアクセスが許可された範囲内に安全にあることを保証することができる。代替的に、図2のパートBで示されるように、命令がポインタ62のアドレスによって特定される位置にアクセスしようと試行すると、その時そのアドレスが指定された範囲の外にある場合、エラーがトリガされ得る。したがって、ポインタ62を指定された範囲の外の値に設定することがなお許容され得るが、そのポインタ・アドレスのデータ・アクセス(又はそのポインタから導出されるアドレス)が試行されると、その時そのアドレスが許可された範囲の外にある場合、エラーがトリガされ得る。図2のパートA及びパートBに示される両方のタイプの命令に応じて、他のシステムがエラーをトリガすることもある。
範囲情報64は様々な方法で設定することができる。例えば、セキュアなコード、又はオペレーティング・システム若しくはハイパーバイザは、所与のポインタに許可される範囲を指定することができる。例えば、命令セット・アーキテクチャは、所与のポインタ62についての範囲情報64を設定するための又は修正するための複数の命令を含むことができ、これらの命令の実行は、あるソフトウェア又はプロセッサ4のあるモード若しくは例外状態に制限することができる。範囲情報64を設定するための又は修正するためのあらゆる既知の技法を使用することができる。
ポインタへの参照を行うある命令を実行する際に実行状態12で使用され得る有界ポインタ格納要素60のセットに加えて、プログラム・カウンタ機能(PCC:Program Counter Capability)レジスタ80が、命令がレベル1の命令キャッシュ20からフェッチされる際、フェッチ工程6で類似の機能性を提供するためにやはり使用されてもよい。特に、プログラム・カウンタ・ポインタはフィールド82に格納され得、この時PCC80はまた、有界ポインタ格納要素60のセット内のポインタのそれぞれに与えられる範囲及びリストリクション情報と同様に、範囲情報84及び適当なリストリクション情報86を与える。
図3は、タグ・ビットが個々のデータ・ブロックに関連付けられて、これらのデータ・ブロックが機能を表しているかどうか(すなわち、有界ポインタ及び関連付けられるリストリクション情報)、又は通常データを表しているかどうかを特定するためにどのように使用されるか概略的に図示している。特に、メモリ・アドレス空間110は、典型的には指定されたサイズを有することになる一連のデータ・ブロック115を格納することになる。純粋に図示のために、この実例において、それぞれのデータ・ブロックは128ビット含むと仮定する。それぞれのデータ・ブロック115に関連して、タグ・フィールド120が提供され、一実例ではこれはタグ・ビットと称される単一のビット・フィールドであり、関連付けられるデータ・ブロックが機能を表すことを特定するためにセットされ、関連付けられるデータ・ブロックが通常データを表し、ひいては機能として取り扱うことができないことを示すためにクリアされる。セットされた又はクリアな状態に関連付けられる実際の値は、実装形態によって異なっていてよいが、純粋に図示のため、一実例の実装形態においては、タグ・ビットが値1を有する場合、関連付けられるデータ・ブロックが機能であることを示し、タグ・ビットが値0を有する場合は関連付けられるデータ・ブロックが通常データを含むことを示すことを了解されたい。
機能が、図3で示される機能レジスタ100などの有界ポインタ・レジスタ(本明細書では機能レジスタとも称する)60のうちの1つにロードされると、次にタグ・ビットは機能情報を伴って移動する。したがって、機能が機能レジスタ100にロードされると、ポインタ102、範囲情報104及びリストリクション情報106(以降でパーミッション情報と称する)が機能レジスタにロードされることになる。加えて、その機能レジスタに関連して、又はその中の特定のビット・フィールドとして、タグ・ビット108はその内容が機能を表すことを特定するためにセットされることになる。同様に、機能がメモリに格納し戻される場合、関連するタグ・ビット120は機能が格納されるデータ・ブロックに関連付けられてセットされることになる。そのような手法によって、機能と通常データとを区別し、ひいては通常データを機能として使用することができないことを保証することが可能である。
図1に戻ると、本明細書において説明される技法によると、有界ポインタに関連付けられる通常の情報に加えて、その有界ポインタがアクセスを制御するために使用される対応するメモリ領域に関連付けられる第1のトークン値を含む取り消し可能な有界ポインタが生成され得る。さらには、メモリ領域の割り当てられたインスタンスに関連する取り消し可能な有界ポインタに関する使用のために、メモリ内のヘッダ位置に格納されるヘッダが設けられ、そのヘッダは、格納値が、取り消し可能な有界ポインタに関して使用される第1のトークン値に初期化される第1のトークン・フィールドを有する。ヘッダ位置は取り消し可能な有界ポインタによって与えられる範囲情報から導出可能であるように構成され、したがって有界ポインタがメモリ・アドレスを生成するために使用される時にヘッダが配置されることを可能にしている。割り当てられたメモリ領域が続いて解放される際、この時第1のトークン・フィールド内の格納値が修正される。
図1は、取り消し可能な有界ポインタの使用を管理するために使用されるコンポーネント、及び対応するメモリ領域に関して設けられるヘッダを概略的に示している。特に、示されるように有界ポインタ制御回路90は有界ポインタの生成、並びに機能レジスタ60及びキャッシュ・ヒエラルキ36、44及び/又はメモリ50の間のこれらの有界ポインタの移動を制御するために設けられる。さらには、メモリ内でメモリ領域を割り当てるメモリ・アロケータ/デアロケータ回路92が設けられ、これらは例えばデータ処理装置で実施されている特定のプロセスによって使用することができ、続いてこれらのメモリ領域を解放する。メモリ・アロケータ/デアロケータ回路はまたそれぞれのメモリ領域用のヘッダを維持する役割もしている。
いくつかの実施例において、有界ポインタ制御回路90及びメモリ・アロケータ/デアロケータ92は専用のハードウェア・コンポーネントによって提供される。代替的に、それらは信頼できるコード、例えばセキュアなコード又はオペレーティング・システム若しくはハイパーバイザの制御の下でデータ処理装置の既存のハードウェアに実装することができる。これらのコンポーネントのいずれかがソフトウェアによって実装される事例では、有界ポインタのセマンティクスはなおハードウェアによって強制されるべきである。
やはり図1に示すように、追加的な記憶装置94は有界ポインタ・レジスタ60のセットと関連して設けられる。これは、有界ポインタ・レジスタ60を提供するために使用される記憶装置とは別個の記憶装置コンポーネントとして設けられてもよいか、又は同一のコンポーネント内に設けられてもよく、有界ポインタ・レジスタのそれぞれに効果的に拡張を与え、それによってこれらが有界ポインタだけではなく、追加的な記憶装置94の対応する位置に格納される一部の追加的な情報を格納することができる。特に、後にさらに詳細に議論するように、取り消し可能な有界ポインタについて、有界ポインタ・レジスタに関連付けられる追加的な記憶装置内の関連する位置は、その有界ポインタ・レジスタ内に格納される取り消し可能な有界ポインタに関連付けられるメモリ領域用に設けられるヘッダ内でやはり維持される第2のトークン値を格納するために使用することができる。
いくつかの実装形態において、取り消し可能なプログラム・カウンタ機能を提供することが望ましいことがあり、そのような事例でも追加的な記憶装置をPCCレジスタ80に関連して設けることができる。
図4は、一実例の実装形態においてメモリ・アロケータ/デアロケータ92によって実施され得るメモリ割り当て動作を図示するフロー図である。ステップ150において、新しいメモリ領域が割り当てられる必要があるかどうかが判断される。これは、例えばデータ処理装置上で実施される特定のプロセス又はタスクによる使用のために設けられる必要があるメモリの一部分により、処理回路上で実行されているソフトウェアによってトリガすることができる。いったん新しいメモリ領域が割り当てられることになると、ステップ155において複数の標準的なメモリ割り当て技法のいずれかを使用してメモリ領域用のアドレス範囲が決定され、ステップ160において、関連付けられているタスク又はプロセスによる使用のためにメモリ領域を形成するメモリ・アドレスの領域を予約するために、特定されたメモリ領域は割り当てられたとしてマークされる。取り消し可能な有界ポインタがメモリ領域のために構築される場合、関連するヘッダがソフトウェア・アドレッシング可能メモリ・ビットに配置されることになり、メモリの一部分もヘッダの格納用に予約される必要がある。
ステップ165において、取り消し可能な有界ポインタがメモリ領域用に使用されるかどうか判断される。特に、一実装形態において、取り消し可能な有界ポインタがサポートされるが、標準的な有界ポインタも使用可能であり、ひいては一部の事例では、標準的な有界ポインタを特定のメモリ領域のために使用することが決定されることがある。取り消し可能な有界ポインタを使用することにならない場合、この時点でプロセスはステップ170に進むことができ、ここで標準的な有界ポインタの使用に関するルーチンのステップを実施することができる。
しかしながら、割り当てられたメモリ領域がそれに関連する少なくとも1つの取り消し可能な有界ポインタを有することになる場合、プロセスはステップ175に進みメモリ領域用のヘッダが作成され、次いでそのヘッダはメモリ領域用に決定されるヘッダ位置に格納される。以下でより詳細に議論するように、ヘッダ位置が関連付けられている取り消し可能な有界ポインタにおいて与えられる範囲情報を使用して決定可能であるとすれば、ヘッダ位置は様々な異なる形態を取ることができる。ヘッダの内容は様々な形態を取ることができるが、説明される一実装形態において、第1のトークン(本明細書ではスモール・トークンとも称される)、第2のトークン(本明細書ではラージ・トークンとも称される)、及びメモリ領域に関連付けられる有界ポインタのために使用される一定の有界ポインタ・ビット用の値を提供する。ヘッダ内で維持される有界ポインタ・ビットは、様々な形態を取ることができるが、典型的には、メモリ領域の現在割り当てられているインスタンスに関連する使用のために作成されたあらゆる有界ポインタに共通する有界ポインタのビットである。実例として、これは範囲情報の一部分を含むことができ、それは範囲情報が特定のメモリ領域、一実施例においては、メモリ領域のベース・アドレス及びリミット・アドレスを特定する範囲情報に割り当てられた有界ポインタに共通するからである。さらには、一定のパーミッション・ビットが、メモリ領域に関連する使用のために作成された有界ポインタに共通することもあり、これらのパーミッション・ビットの1つ又は複数は、ヘッダ内に保持される情報内に含めることができる。
後の議論から明らかとなるように、一定の有界ポインタ・ビットの値は、有界ポインタが有界ポインタ・レジスタ60とメモリとの間で移動する際、エンコード演算及び対応するデコード演算における使用のために、ヘッダ内に保持される。特に、ラージ・トークンは取り消し可能な有界ポインタそれ自身に収容することができない(一実例の実装形態において、取り消し可能な有界ポインタ内に一連のビットとして組み込まれ、そうでなければ有界ポインタのフォーマットでは使用されないスモール・トークンとは対照的である)。したがって、取り消し可能な有界ポインタが有界ポインタ・レジスタ60のうちの1つに存在する間、ラージ・トークン情報は追加的な記憶装置94の対応する部分に維持することができる一方で、有界ポインタがメモリに格納されると、ラージ・トークン情報を維持することができない。したがって、一実例の実装形態において、エンコードされた部分を生成するために、取り消し可能な有界ポインタの一部分(すなわちヘッダ内で維持される部分に対応する部分)は、ラージ・トークンを使用するエンコード演算にかけられ、エンコード演算はラージ・トークンがそのエンコードされた部分を元々の内容に復元するようにデコードするために使用されることを後に可能にする形態であり、次に取り消し可能な有界ポインタのエンコードされた形態はメモリに格納される。
代替的な実装形態において、第2のトークンが与えられなくてもスモール・トークンを使用することで十分であり得る。その事例では、ヘッダはスモール・トークンの指標を与えることを必要とするに過ぎず、第2のトークン又は有界ポインタの一定のビットの値を特定することはない。さらには、エンコード演算もデコード演算も必要とされることがなく、それは取り消し可能な有界ポインタが有界ポインタ・レジスタ60とメモリ50との間でいずれかの方向に移動する際、第1のトークン値を直接取り消し可能な有界ポインタ内に組み込むことができ、ひいては維持することができるからである。しかしながら、use−after−freeシナリオを妨げるメカニズムの堅牢さは、トークンの全体的なサイズが大きい時に改善され、したがって以降で説明する実例の実装形態の目的に関しては、全体的なトークンをスモール・トークン(有界ポインタ内で直接表現できる)及びラージ・トークン(有界ポインタ内で直接表現できない)によって表現し、また取り消し可能な有界ポインタを取り消すかどうかを決定する際は両方のトークンが使用されることを仮定する。残りの図面を参照して、このことをより詳細に議論する。
図5は、有界ポインタ制御回路90によって実装される有界ポインタ作成プロセスを図示している。特に、ステップ200で定められるように、プロセスは取り消し可能な有界ポインタが作成される時に発生する一連の事象を説明している。いったん取り消し可能な有界ポインタが作成されると、ステップ205において有界ポインタのフィールドが、通常のポインタ、範囲、及びパーミッション情報を含む必要とされる情報でポピュレートされる。しかしながら、加えて関連付けられるメモリ領域のヘッダのスモール・トークン・フィールドに格納されたスモール・トークン値を組み込むよう有界ポインタがポピュレートされる。加えて、本明細書において説明される実例の実装形態において、取り消し可能な(R)ビットが有界ポインタ内に与えられ、有界ポインタが取り消し可能な有界ポインタであることを特定するためにセットすることができる。対照的に、標準的な有界ポインタが作成されている場合、第1のトークン値は有界ポインタ内に組み込まれることはなく、Rビットはクリアされる。
やはり後により詳細に議論するように、一実装形態において、エンコードされる(E)ビットが与えられ、取り消し可能な有界ポインタがエンコードされた形態にあることを特定するためにセットすることができ、また取り消し可能な有界ポインタがデコードされた形態にあることを特定するためにクリアすることができる。実装形態がEビットの情報を使用する場合、ステップ205においてEビットがクリアされるが、それは有界ポインタを作成する時、一実例では有界ポインタ・レジスタ60のうちの1つにおいてエンコードされていない形態で作成されることになるからである。
ステップ210において、取り消し可能な有界ポインタは選択された有界ポインタ・レジスタ60内に格納され、対応するメモリ領域のヘッダに与えられるラージ・トークンは選ばれた有界ポインタ・レジスタ60に関連付けられる追加的な記憶装置94に格納される。ラージ・トークンを追加的な記憶装置94に格納することが可能な様々な方法がある。有界ポインタ・レジスタ60のうちの1つにある取り消し可能な有界ポインタがメモリ・アドレスを生成するために使用される時、その有界ポインタのための適当な第2のトークンが追加的な記憶装置94からアクセスすることができるとすれば、あらゆる適切なメカニズムを使用することができる。
いくつかの実装形態において、現在その有界ポインタ・レジスタにある取り消し可能な有界ポインタに関連付けられるヘッダのいずれかに書き込みが実施される場合にコアに通知を受信させる通知メカニズムが備わっている場合、追加的な記憶装置の必要はない可能性がある。特に、その事象では、コアがそのような通知を何も受け取っておらず、且つ関連するヘッダそれ自身に書き込みを行っていない場合、ヘッダが変更されておらず、したがって領域が解放されていないこと、ひいては使用認可チェックが回避され得ることが分かる。必要とされるエンコード演算に関して、取り消し可能な有界ポインタがメモリに移される場合、この目的のために第2のトークン値を直接ヘッダからロードすることができる。
そのような通知メカニズムの特定の実例は、先に議論したキャッシュ・コヒーレンシ・スキームの実例である。特に、ヘッダがキャッシュされる場合、認可チェックを最適化することが可能な場合があり、それにより現在のコア(すなわち取り消し可能な有界ポインタを使用しているコア)は実際には、キャッシュ・コヒーレンシ・スキームがヘッダのキャッシュされたバージョンへ更新を通知するまで、又は現在のコアがヘッダを更新するまで、認可チェックを実施する必要がない。そのような場合、追加的な記憶装置94の必要性を回避することが可能な場合がある。そのうちヘッダの修正についての通知が受信され、且つ追加的な記憶装置が設けられない場合、修正されたヘッダに関連付けられ、また有界ポインタ・レジスタのうちの1つに現在存在しているすべての取り消し可能な有界ポインタは、無効にされるべきである。
図6は、メモリ・アロケータ/デアロケータ回路92によって実施され得るメモリの解放動作を図示している。ステップ250において、例えばそのメモリ領域を使用するよう意図されたプロセスが完了し、それによりメモリ領域についてさらなる必要性がないために、割り当てられたメモリ領域が解放される必要があると判断される場合、プロセスはステップ255に進み、メモリ領域が関連付けられるヘッダを有しているかどうか判断される。これはそのメモリ領域に関連する使用のために取り消し可能な有界ポインタが作成されてある状況に当てはまる。
メモリ領域が関連付けられるヘッダを有している場合、ステップ260においてヘッダは所定の値で上書きされる。ヘッダに書き込まれる正確なデータは、実装形態に応じて変わるが、上書きプロセスの目的は、ヘッダがヘッダ内に以前格納されていたスモール・トークン値及びラージ・トークン値をもはや維持しないことを保証することであり、その結果として、それらはそのメモリ領域に関連付けられる取り消し可能な有界ポインタに関して維持されるトークン情報とはもはや一致しない。
ステップ260に続いて、又はステップ255に直接続いて、メモリ領域が関連付けられるヘッダを有していない場合、プロセスはステップ265に進み、メモリ領域の将来的な割り当てのために使用することができるメモリ・アドレスのプールの一部として利用可能となるようにメモリ領域が解放される。
図7A〜図7Cは、一実例の実装形態において使用される、ヘッダの使用、及び取り消し可能な有界ポインタの形態を図示している。図7Aに示すように、メモリ割り当てプロセスの間、メモリ・アドレス空間300内のメモリ領域305は、割り当てられるメモリ領域として決定することができる。割り当てられたメモリ領域は、領域内の最初のアドレスを特定するベース・アドレス、及び領域内の最後のアドレスを特定するリミット・アドレスを有する。さらには、メモリ領域がそれに関連付けられる取り消し可能な有界ポインタを有することになる状況では、ヘッダ位置310に格納されるメモリ領域用のヘッダが生成される。ヘッダ位置は様々な形態を取ることができるが、一実装形態において、その位置は、そのメモリ領域のための取り消し可能な有界ポインタ内に与えられる割り当てられたメモリ領域についての範囲情報を使用して決定できることが要求される。一実例の実施例において、ベース・アドレス及びリミット・アドレス情報は、有界ポインタの範囲情報内でエンコードされ、したがってヘッダ位置はベース・アドレス又はリミット・アドレスのうちの1つから直接導出可能であるように構成される。示される実例において、ヘッダ位置はベース・アドレスから直接決定可能であり、特に割り当てられたメモリ領域の開始の直前のメモリ・アドレス・ビットから形成される。しかしながら、ヘッダ位置がメモリ領域に直接隣接していることは必要事項ではなく、代わりにメモリ領域の開始より固定オフセット前にあることができ、それによりヘッダ位置がベース・アドレス及び固定オフセットから決定することができる。代替的に、ヘッダ位置は割り当てられたメモリ領域の終端の直後にあるように構成することができ、それによりリミット・アドレスを使用して決定することができる。やはり、代替的に、メモリ領域の終端より固定オフセット後にあってもよい。
なおさらなる実例として、ヘッダは、その位置が何らかの定められたメカニズムを使用してメモリ領域のアドレスから決定することが可能であるとすれば、メモリ領域に対して任意の別個の位置に配置することができる。実例として、二分探索木を使用することが可能な場合があり、この場合、割り当てられたメモリ領域のアドレスを探索キーとし、ヘッダを対応する値とする。
一部の実例の実装形態において、ヘッダ位置をソフトウェア・アドレッシング可能メモリ・ビットとして与えることができるが、代替的に、ECCビットがメモリ内のデータに関連して与えられ得るのとほとんど同様の方法で、非ソフトウェア・アドレッシング可能メモリ・ビットとして与えることができる。
ヘッダのフォーマットは様々な形態を取ることができるが、あるフォーマットを図7Bのブロック315によって示す。この実例では、4つのフィールドが与えられており、すなわちスモール・トークン値を格納するためのスモール・トークン・フィールド320、ラージ・トークン値を格納するためのラージ・トークン・フィールド335、メモリ領域に関連付けられる取り消し可能な有界ポインタに与えられる情報の特定のビットを格納するための追加的なフィールドである。特に、フィールド325は範囲情報の一定の部分を格納するために与えられ得る。一実例の実装形態において、このフィールドに格納される部分はヘッダ位置を特定するために必要とされない部分である。ベース・アドレスがヘッダ位置を特定するために使用される図7Aの実例を考えると、フィールド325はリミット・アドレスを格納することができるため、リミット・フィールドと称される。しかしながら、ヘッダ位置を特定するために使用されるのがリミット・アドレスである場合、ベース・アドレスをフィールド325において特定することができ、そのフィールドはベース・フィールドと称される。
一実例の実装形態では、フィールド325で十分な場合もあるが、所望であれば有界ポインタからさらなる情報のビットをヘッダ内で再現することもできる。例えば、パーミッション・フィールド330は、有界ポインタのパーミッション・ビットの少なくとも一部分を格納するよう設けることができる。典型的には、パーミッション・フィールドは、割り当てられたメモリ領域に関連する使用のために作成されるあらゆる有界ポインタに共通であるこれらのパーミッション・ビットを格納するために使用される。
図7Cは、実例の取り消し可能な有界ポインタ340、特にそこで与えることができる様々なフィールドを図示している。示されるように、取り消し可能な有界ポインタは、ポインタ値を格納するためのポインタ・フィールド345、メモリ領域のベース・アドレスを特定するベース・フィールド350、リミット・アドレスを特定するためのリミット・フィールド355、様々なパーミッション・ビットを格納するためのパーミッション・フィールド360、スモール・トークン値を格納するためのスモール・トークン・フィールド365、及び示される追加的なビット・フィールドを含む。特に、有界ポインタが取り消し可能な有界ポインタであることを特定するためにセットされ、有界ポインタが標準的な有界ポインタである場合にはクリアされる、Rビット・フィールド370を使用することができる。さらには、図3を参照して先に議論したTビット情報を、Tビット・フィールド380に格納することができる。任意選択で、有界ポインタの内容がエンコードされているか、又はそうでないかを特定するために使用されるEビット・フィールド375を設けることができる。
いくつかの実装形態において、Eビットの使用は必須ではない。例えば一実装形態において、取り消し可能な有界ポインタが有界ポインタ・レジスタ60のうちの1つに格納される時いつもデコードされ、メモリ50に格納される時いつもエンコードされる可能性がある。その事例の場合、Eビットの情報は推論することができ、別個のフィールドを設ける必要性はない。しかしながら、エンコードされた有界ポインタが有界ポインタ・レジスタ60のうちの1つに存在することが望ましい実装形態では、Eビット・フィールド375を設けることができ、それにより特定の取り消し可能な有界ポインタが現在エンコードされた形態(メモリ・アクセスを生成する時に使用することができない)にあるかどうか、又はデコードされた形態(使用認可チェックのプロセスをパスすれば、メモリ・アクセスを実施する時に使用することができる)にあるかどうかを確かめることができる。
一実例の実装形態において、有界ポインタが生成される時は、有界ポインタ・レジスタ60のうちの1つ、例えば図7Cに示される有界ポインタ・レジスタ385で作成される。有界ポインタが有界ポインタ・レジスタ内に格納される時、部分390などの追加的な記憶装置94の関連付けられている部分は、関連するラージ・トークンを格納するため、すなわち対応するメモリ領域用のヘッダ315のラージ・トークン・フィールド335にラージ・トークンを格納するために使用される。
メモリ・アドレスを生成する際使用される有界ポインタについては、まずそれは有界ポインタ・レジスタ60のうちの1つに存在しなければならず、したがって有界ポインタが使用される時、追加的な記憶装置はラージ・トークン情報をキャプチャする。図7Cで示されるように、追加的な記憶装置は、所望であれば少なくとも一部のタイプのソフトウェアによってソフトウェア・アクセス不能に構成することができ、したがってラージ・トークン値のソフトウェア修正についての可能性を妨げることによりラージ・トークン情報のセキュリティを向上させる。
取り消し可能な有界ポインタがメモリ・アドレスを生成するために使用される時、図8に図示するようなハードウェア制御の下で使用認可チェック・プロセスを実装することができる。
特に、命令がメモリ・アドレスを生成させる実行パイプライン内で実行されている時、ステップ400においてプロセッサ・ハードウェアは取り消し可能な有界ポインタがメモリ・アドレスを生成するために使用されることを判断することができ、この時点でプロセスはステップ405に進むことができる。ステップ405において、取り消し可能な有界ポインタ内に与えられる範囲情報の少なくとも一部分は、メモリ領域用のヘッダを特定するために使用される。図7Aの実例において、ベース・フィールド350内に格納されるベース・アドレス情報がこの目的のために使用されることを考えるが、先に議論したように、代替的な実装形態では、この目的のために使用されるのはリミット・アドレス情報であってもよい。
いったんヘッダ位置が特定されると、ステップ410で、ヘッダのスモール・トークン・フィールド及びラージ・トークン・フィールドに保持されるトークン値が取り出される。ヘッダのスモール・トークン・フィールド及びラージ・トークン・フィールドを取得するために主メモリにアクセスする必要はなくてもよいことに留意すべきである。例えば、多くのシステムでは、処理パイプライン4によるアクセスのためにデータをキャッシュするために使用することができる、先に議論したレベル1及びレベル2のキャッシュ36、44などの1つ又は複数のレベルのキャッシュがある。したがって、使用認証が実施される必要がある場合にアクセス回数を改善するために、ヘッダの内容をキャッシュすることが可能である。
その後、ステップ415において、取り消し可能な有界ポインタのスモール・トークン値及び関連付けられている追加的な記憶装置のラージ・トークン値が、ヘッダから取り出された値に一致するかどうか判断される。一致しない場合、プロセスはステップ425に進み、取り消し可能な有界ポインタが取り消され、それによってメモリ・アドレスを生成するリクエストが失敗させられ、取り消し可能な有界ポインタのすべてのさらなる使用を妨げる。
しかしながら、チェック415をパスしたと仮定すると、ステップ420で取り消し可能な有界ポインタはメモリ・アドレスを生成するために使用することができる。いったんメモリ・アドレスが生成されていると、生成されたメモリ・アドレスが本当に関連付けられるメモリ領域の範囲内に入ること、及びリクエストされるアクセスのタイプがパーミッション情報に関して実施できることを保証するために、通常の境界及びパーミッションのチェックのすべてが実施される、ことに留意すべきである。
先に言及したように、ラージ・トークンが使用される実装形態において、取り消し可能な有界ポインタが有界ポインタ記憶要素60とメモリとの間で転送される際、エンコード及び関連するデコードのメカニズムが使用され得る。特に、取り消し可能な有界ポインタをメモリに格納する際、有界ポインタの一部分を、取り消し可能な有界ポインタのその部分がデコード演算の間の後の時点で第2のトークン値及びエンコードされた有界ポインタを使用して再作成される方法で、ラージ・トークンを使用してエンコードすることができる。実施され得るエンコード演算の実例が、図9のフロー図によって図示されている。ステップ450において、メモリに格納される取り消し可能な有界ポインタがあるかどうか判断され、その状況が生じれば、プロセスはステップ455に進み、有界ポインタ制御回路90はエンコード演算を実施し、一方で有界ポインタを関連する有界ポインタ・レジスタ60からメモリに移動させる。特に、ステップ455において有界ポインタの特定された部分は、取り消し可能な有界ポインタを格納する有界ポインタ・レジスタに関連付けられる追加的な記憶装置94に格納されたラージ・トークンを使用してエンコードされる。リミット・フィールド及びパーミッション・ビットのサブセットがヘッダ内に保持される図7Bの実例を考えると、これらはラージ・トークンを使用してエンコードされる有界ポインタの部分を形成するビットである。特に、ヘッダはその情報の複製を含んでいるため、後に関連するデコード演算を実施する時に、ラージ・トークン・フィールド335の内容が変更されたかどうか、したがってデコードが実施される時に取り消し可能な有界ポインタを取り消すかどうかを判断することができる。図10のフロー図を参照して、後でこのことをより詳細に議論する。
いったんステップ455でエンコード演算を実施してしまうと、エンコードされた取り消し可能有界ポインタはステップ460でメモリに格納され、有界ポインタのフォーマットがEビットを含む場合は、Eビットがセットされる。次いで、ステップ465において、関連する有界ポインタ・レジスタ及び関連付けられている追加的な記憶装置の内容が、所望であれば無効にされ得る。この時点で、取り消し可能な有界ポインタはメモリに移行されているが、ラージ・トークン値を考慮するエンコードされた形態にある。ステップ465で、関連する有界ポインタ・レジスタ及び関連付けられている追加的な記憶装置の内容を無効にすることの代替として、所望であればその情報を単に保持することができ、この場合、取り消し可能な有界ポインタはエンコードされた形態でメモリに複製されてしまっている一方で、取り消し可能な有界ポインタはなお有界ポインタ・レジスタに残ったままであることが了解されよう。
一実施例において、取り消し可能な有界ポインタが有界ポインタ・レジスタのうちの1つからメモリに格納される時はいつでもエンコード演算が実施される。そのようにエンコードされた有界ポインタは、続いて有界ポインタ・レジスタ60のうちの1つに格納し戻すためにメモリから取り出される際、有界ポインタ・レジスタに書き込まれるのに先立ってデコードすることができる。特に有界ポインタのフォーマットが、有界ポインタがエンコードされているか、そうでないかを特定する情報を含まない状況では、いつもこの手法が取られ、代わりに取り消し可能な有界ポインタがいつもエンコードされた形態でメモリに格納され、また非エンコードされた形態でレジスタ内に格納されることが予め定められる。しかしながら、Eビットを含む有界ポインタのフォーマットについては、エンコードされた有界ポインタはメモリから有界ポインタ・レジスタに取り出されることが可能であるが、とはいえ、有界ポインタのそのエンコードされた形態はデコードされてしまうまではメモリ・アドレスを生成するために使用することができない。これは、例えば有界ポインタをメモリの異なる領域同士の間で移行させる特定の状況で有用であると証明でき、そのプロセスの間、有界ポインタは有界ポインタ・レジスタのうちの1つにロードすることができ、次いで異なるメモリ・アドレスに格納し戻される。
図10は、一実例の実装形態におけるデコード演算を図示するフロー図である。ステップ500において、有界ポインタがデコードされると決定される場合、プロセスはステップ505に進み、範囲情報の少なくとも非エンコードされた部分を使用して関連付けられるメモリ領域用のヘッダを特定する。図7A〜図7Cを参照して先に議論した実例を考えると、リミット・フィールド情報はエンコードされる範囲情報の部分であるため、ベース・アドレス情報はヘッダを特定するために使用される情報となる。しかしながら、逆にヘッダを特定するために使用されるのがリミット情報である場合、エンコードされていたのはベース情報ということになり、ステップ505では、そのリミット・アドレスがヘッダを特定するために使用されることになる。
ステップ510において、ヘッダの内容が取り出され、その後ステップ515において取り消し可能な有界ポインタのエンコードされた部分は、ヘッダ315のラージ・トークン・フィールド335内の値を使用してデコードされる。ラージ・トークン・フィールド335内に保持される値が、取り消し可能な有界ポインタがエンコードされた時のラージ・トークン値とまだ同じあると仮定すると、これは取り消し可能な有界ポインタの関連部分をデコードされた形態で再作成することになる。ステップ520において、デコードされる部分がヘッダ内に格納された有界ポインタのビット値に一致するかどうか判断される。図7Bの実例を考えると、これはデコードされたリミット・アドレス情報及び様々なパーミッション・ビット値を、ヘッダ315のフィールド325、330に保持される対応するデータと比較することを伴う。
あらゆる理由のため、ステップ520において不一致が検出され、ステップ530において取り消し可能な有界ポインタは無効にされる。そうでなければ、ステップ525において、取り消し可能な有界ポインタ内のスモール・トークン値が、ヘッダ315のスモール・トークン・フィールド320内の値に一致するかどうか判断される。一致しない場合、やはりこれはステップ530において取り消し可能な有界ポインタを無効化させるが、一致する場合プロセスはステップ535に進み、デコードされた取り消し可能な有界ポインタは選ばれた有界ポインタ・レジスタに格納され、ヘッダから取り出されたラージ・トークン値は関連付けられている記憶装置94内の適当な位置に格納される。さらには、Eビットが使用される実施例では、取り消し可能な有界ポインタ内のEビットはこの時点でクリアされ、取り消し可能な有界ポインタがデコードされた形態にあることを確かにする。
図11は、前述のエンコード及びデコードのプロセスを概略的に図示している。図11の上部に示されるように、エンコードされていない有界ポインタ600は、図7Cを参照して先に議論された、この実例では有界ポインタをメモリに格納する時にエンコードされる有界ポインタの部分を形成するリミット・フィールド及びパーミッション・フィールド610、615を含む様々なフィールドのすべてを含む。先に言及したように、この目的のためにすべてのパーミッション・ビットが含められなくてもよい。追加的な記憶装置605は、対応するラージ・トークン値を格納し、そのラージ・トークン値を使用してエンコード演算620を実施し、結果としてエンコードされた取り消し可能有界ポインタ622がメモリに格納される。これは、リミット・フィールド及びパーミッション・フィールド610、615以外の元々のエンコードされていない有界ポインタの様々な部分を含んでおり、リミット・フィールド及びパーミッション・フィールド610、615の代わりにエンコードされた部分625がエンコードされた取り消し可能有界ポインタ内に存在する。
続いてエンコードされた取り消し可能有界ポインタ622をデコードするよう決定される場合、ベース・フィールド630がアクセスされ、対応するメモリ領域に関連するメモリ内に格納されるヘッダ635を特定するために使用される。次いで、ヘッダからラージ・トークンが取り出され、デコードされたリミット情報及びパーミッション情報を作り出すためにエンコードされた部分625を使用してデコード演算640を実施するために使用される。
デコードされたリミット情報及びパーミッション情報は、スモール・トークン値とともにマッチング・プロセス645に入力され、マッチング・プロセス645はヘッダ635からリミット情報、パーミッション情報、及びスモール・トークン情報もやはり受信する。一致が検出されると、デコードされた取り消し可能な有界ポインタは関連する有界ポインタ・レジスタに格納され、ヘッダ635からのラージ・トークン値は追加的な記憶装置605に格納される。したがって、図11の下部に示されるように、元々のエンコードされていない有界ポインタが再作成されている。ステップ645において、一致が検出されない場合、取り消し可能な有界ポインタは無効にされる/取り消される。
図11から明らかなように、Eビットが使用される実装形態では、取り消し可能な有界ポインタがエンコードされていない形態の場合Eビットはクリアされるが、有界ポインタがエンコードされた形態の時はセットされる。
エンコード、及び関連付けられるデコード演算は様々な形態を取ることができる。主要な要求事項は、エンコード演算によって作り出されたエンコード値が、同一のトークン値がエンコードの際使用されたように使用される状況において、元々の取り消し可能な有界ポインタの同一の連結されたフィールド値にデコードできることである。一部の事例では、エンコードされた値が、あらゆる他のトークン値を使用して同一の連結されたフィールド値にデコードできないことが、やはり望ましいことがある。しかしながら、いくつかの実装形態において、この後者の制限は、use−after−freeシナリオに対する十分な程度の弾力性を促進するために必要とされないと考えることができる。
図12A及び図12Bは、ラージ・トークンのビット数が、エンコードされる有界ポインタの関連部分のビット数と直接同一ではない状況において、使用することができる2つの実例のエンコード・スキームを概略的に図示している。特に、ある適切なエンコード・スキームは、有界ポインタの関連ビットとラージ・トークンの関連ビットとの間で適用されるXORバイナリ演算を使用することである。ラージ・トークン内及び有界ポインタの関連部分内に同一のビット数がある状況では、これは単純である。代わりに、図12Aに示されるように、エンコードされる必要がある有界ポインタ内のビット数700が、ラージ・トークン705内のビット数を超える場合、一実装形態において、ラージ・トークンは、回転などのあらゆる適切なスキームを使用して追加的なビット710を追加するよう拡張することができる。その後、XOR演算715は、エンコードされたビット720を作り出すために、有界ポインタ部分700内のビットと部分705、710によって形成された拡張されたラージ・トークンとのそれぞれの対応する対に適用することができる。
図12Bは、ラージ・トークンがエンコードされる必要がある有界ポインタの関連するビット数よりも大きい場合の、代替的な手法を図示している。この事例では、中間的なエンコード745を生成するために、関連する有界ポインタのビット700及びラージ・トークンの対応するビット数730を使用してXOR演算740が適用される。次いで、ラージ・トークンの残りのビット735を使用して、エンコードされたビット755を作り出すために、中間的なエンコードの補完的な演算を実施することができ、示される実例ではこれは回転750である。
図12A及び図12Bの手法の両方について、同一のラージ・トークンが使用されると仮定すると、元々の有界ポインタ・ビット700を再作成させる対応するデコード演算が実施され得ることが了解されよう。
しかしながら、図12A及び図12Bは、適切なエンコード・スキームの具体的な実例を図示するために与えられるに過ぎないことに留意すべきであり、またエンコード・プロセスの間に使用されていたのと同一のトークン値を使用して有界ポインタ・ビットの再作成を可能にするとすれば、あらゆる他の適切なエンコード・スキームを使用することができることが理解されよう。
確かに有界ポインタを取り消し、対応するメモリ領域が解放されてしまった後にそれが使用されないことを保証することができる非常に有益である多くの状況がある。一実例の使用事例が、図13に示されており、第1の装置800は関連付けられているメモリ815を有しており、一時的に第2の装置805へ/からのアクセスを許可したいメモリ領域820を割り当てることができる。本明細書において説明されるスキームにより、第1の装置800は、メモリ領域820と関連する使用のために取り消し可能な有界ポインタ810を生成することができ、本明細書において説明されるメカニズムの結果として、メモリ領域820に関連してヘッダ825も作成される。
次いで、取り消し可能な有界ポインタ810は第2の装置805に渡され、第2の装置805がメモリ領域820へのアクセスを有することができるようにしている。次いで、第2の装置は、メモリ・アドレスを生成するために取り消し可能な有界ポインタを使用する際、ハードウェアで使用認可チェック830を実施する。
結果として、そのうち第1の装置800はメモリ領域820を解放するよう決定する際、先述のメカニズムは、続いて第2の装置805が取り消し可能な有界ポインタ810を使用しようとすると、使用認可チェック830が失敗し、取り消し可能な有界ポインタが取り消されることを保証し、したがって、第2の装置805による、そのさらなる使用を妨げている。
図面を参照して議論した実例において、取り消し可能な有界ポインタをメモリに格納する際にエンコードされた取り消し可能な有界ポインタの部分は、予め定められることを仮定している。特に、図7Bを参照して、その実例ではエンコードされる有界ポインタの部分を形成するのは、リミット・アドレス情報及び所定のパーミッション・ビットであることを仮定している。しかしながら、代替的な実装形態において、使用される実際のビットは構成可能になされ得る。例えば、ヘッダは、取り消し可能な有界ポインタのどのビットがヘッダ内に格納される取り消し可能な有界ポインタの複製された部分を形成するために使用されたか、を特定する制御フィールドを備えることができる。例えば、マスク・フィールドを使用して、取り消し可能な有界ポインタのどのビットがヘッダ315のフィールド325、330内の値によって表現されるかを正確に特定することができ、これらはリミット・アドレス及び一定のパーミッション・ビットであるよう予め定められる必要はない。マスク・フィールドの存在のために、エンコードの時、取り消し可能な有界ポインタのどのビットをエンコード演算への入力として使用するかを決定することができ、同様にデコードの時、デコード演算の間使用されるトークン値が先のエンコード演算において使用されたのと同一のトークン値である時、元々のビットが再作成されることを保証するために、どのビットをデコード演算にかけるかを決定することができる。
本明細書において説明される技法は、use−after−freeシナリオが発生する見込みを大きく軽減させるメカニズムを提供する。use−after−freeシナリオを妨げる確率は、使用されるトークンのサイズに依存する。したがって、トークン・サイズと発生するあらゆるuse−after−freeシナリオを妨げる確率との間にはトレードオフがある。したがって、トークン・サイズは、実装形態に応じて適当に選ぶことができる。いくつかの実装形態において、スモール・トークンを使用するだけで十分である場合があり、そのような事例では、説明したようなエンコード、及びデコード演算の必要がないこともあるが、それはスモール・トークンは全体的に取り消し可能な有界ポインタ内に収容することができるからである。しかしながら、適切なサイズのトークン全体を作り出すために、しばしば大きなトークン及びスモール・トークンの両方を使用することが適当であると考えられる。純粋に実例として、大きなトークン・フィールドとスモール・トークン・フィールドとの連結されたサイズが40ビットである場合、特定の選ばれた値を備えるトークンを生成する確率は、約数百万分の一である。
所望であれば、攻撃者が本明細書において説明される対策をすり抜ける見込みを軽減するための追加的なステップを取ることができる。例えば、攻撃者が大量の乱数を再作成し、異なるトークン値を指定しながらメモリ・アクセスを再試行し続けることが可能であろう。しかしながら、所望であれば、処理装置は、例えば最初のアクセス失敗の後に攻撃コンポーネントがさらなる試行を実施することを停止させることにより、そのようなアクティビティを妨げるように構成することができる。
本出願において、語句「するように構成される」は、装置の要素が定義される動作を実行することができる構成を有することを意味するために使用される。この文脈において、「構成」はハードウェア又はソフトウェアの内部接続の、配置構成又はやり方を意味する。例えば、装置は定義される動作を提供する専用のハードウェアを有してもよく、又はプロセッサ若しくは他の処理デバイスは機能を実施するためにプログラムされてもよい。「するように構成される」は、定義される動作を提供するために装置要素がいかなるやり方でも変更される必要があることを含意するものではない。
本発明の図示的な実例を本明細書において添付の図面を参照して詳細に説明してきたが、本発明はこれらの正確な実例に限定されず、当業者により添付の特許請求の範囲によって定義されるような本発明の範囲及び精神を逸脱することなく、その様々な変形、付加、及び修正がそこになされ得ることを理解されたい。例えば、本発明の範囲を逸脱することなく、従属請求項の特徴と独立請求項の特徴との様々な組み合わせが可能である。