JP2022065654A - 無効なメモリ参照に対する保護のためのシステム、コンピュータ実装方法、およびコンピュータプログラム製品（無効なメモリ参照に対する保護） - Google Patents

Abstract

【課題】本発明は、無効なメモリ参照に対する保護のためのシステム、コンピュータ実装方法、およびコンピュータプログラム製品を提供する。【解決手段】一例として、システムは、非一時的なコンピュータ可読媒体に記憶されたコンピュータ実行可能コンポーネントを実行するプロセッサを含むことができる。コンピュータ実行可能コンポーネントは、エントリコンポーネントと、転用コンポーネントとを含む。エントリコンポーネントは、オブジェクトがメモリに割り当てられた際に、境界情報を格納するためのテーブルにエントリを割り当てることができる。転用コンポーネントは、オブジェクトアドレスの未使用ビットを転用して、テーブルのエントリへのインデックスを格納することができる。【選択図】図６

Description

本開示は、コンピュータ装置に関し、より具体的には、ヒープオブジェクト（heap-objects）に関するハードウェアベースのメモリエラー軽減（memory-error mitigation）を容易にする技術に関する。

従来、ヒープオブジェクトに固有のエラーを検出または防止するための手法が数多く提案されている。

本発明は、無効なメモリ参照に対する保護のためのシステム、コンピュータ実装方法、およびコンピュータプログラム製品を提供する。

本発明の１つ以上の実施形態に対する基本的な理解のために、以下に本発明の概要を示す。本概要は、重要な要素や不可欠な要素を特定したり、特定の実施形態の範囲または特許請求の範囲を限定したりすることを意図したものではない。本概要は専ら、後述する詳細な説明の前置きとして、本発明の概念を簡略化して提示することを目的とする。本明細書に記載の１つ以上の実施形態において、ヒープオブジェクトに関するハードウェアベースのメモリエラー軽減を容易にする、システム、装置、コンピュータ実装方法、もしくはコンピュータプログラム製品またはそれらの組み合わせが説明される。

一の実施形態によれば、システムが提供される。システムは、非一時的なコンピュータ可読媒体に記憶されたコンピュータ実行可能コンポーネントを実行するプロセッサを含む。コンピュータ実行可能コンポーネントは、エントリコンポーネントと転用コンポーネントとを含む。エントリコンポーネントは、オブジェクトがメモリに割り当てられた際に、境界情報を格納するためのテーブルにエントリを割り当てることができる。転用コンポーネントは、オブジェクトアドレスの未使用ビットを転用して、テーブルのエントリへのインデックスを格納することができる。

他の実施形態によれば、コンピュータ実装方法が提供される。方法は、オブジェクトがメモリに割り当てられた際に、プロセッサにより、境界情報を格納するためのテーブルにエントリを割り当てることを含むことができる。方法はさらに、プロセッサにより、オブジェクトアドレスの未使用ビットを転用して、テーブルのエントリへのインデックスを格納することを含むことができる。

さらに他の実施形態によれば、コンピュータプログラム製品が提供される。コンピュータプログラム製品は、プログラム命令が実装されたコンピュータ可読記憶媒体を含むことができる。プログラム命令はプロセッサによって実行可能であり、プロセッサに動作を実行させることができる。動作は、オブジェクトが割り当てられた際に、境界情報を格納するためのテーブルにエントリを割り当てることを含む。動作はさらに、オブジェクトアドレスの未使用ビットを転用して、テーブルのエントリへのインデックスを格納することを含む。

図１は、本明細書に記載の１つ以上の実施形態に係る、それぞれの境界メタデータ（bounds-metadata）の場所に基く、境界チェック（bounds-checking）型手法のグループ分けを例示する図である。 図２は、本明細書に記載の１つ以上の実施形態に係る、ヒープオブジェクトに関するハードウェアベースのメモリエラー軽減を容易にすることが可能なシステムを例示するブロック図である。 図３は、本明細書に記載の１つ以上の実施形態に係る、オブジェクトポインタの未使用ビット（unused bits）を再利用して、ヒープオブジェクトの空間的・時間的安全性（spatial and temporal safety）を確保する手法の概要を概念的に例示する図である。 図４は、本明細書に記載の１つ以上の実施形態に係る、プログラム実行時のポインタの寿命（life-cycle）の概要を概念的に例示する図である。 図５は、本明細書に記載の１つ以上の実施形態に係る、境界チェックフレームワークの構成レイアウトを例示する図である。 図６は、本明細書に記載の１つ以上の実施形態に係る、ＢＩテーブル（BITable）を例示する図である。 図７は、本明細書に記載の１つ以上の実施形態に係る、プログラムの６４ビット仮想アドレス空間（64-bit Virtual-Address space）のレイアウトを例示する図である。 図８は、本明細書に記載の１つ以上の実施形態に係る、ハードウェアベースの境界チェックを実装するためのハードウェア構成を例示する図である。 図９は、本明細書に記載の１つ以上の実施形態に係る、ハードウェアベースの境界チェックに伴う速度低下（slowdown）のシナリオを例示する図である。 図１０は、本明細書に記載の１つ以上の実施形態に係る、ハードウェアベースの境界チェックフレームワークの下で境界外アクセス（out-of-bounds accesses）が検出された関数を例示するグラフである。 図１１は、本明細書に記載の１つ以上の実施形態に係る、境界外の原因となったＳＰＥＣ－ＣＰＵ２０１７アプリケーションにおける命令を例示するグラフである。 図１２は、本明細書に記載の１つ以上の実施形態に係る、ＢＩテーブル管理のためのソフトウェアインスツルメンテーション（software instrumentation）による性能への影響を例示するグラフである。 図１３は、本明細書に記載の１つ以上の実施形態に係る、ハードウェアベースの境界チェックによる性能への影響を例示するグラフである。 図１４は、本明細書に記載の１つ以上の実施形態に係る、ＢＩキャッシュミス（BICache miss）を含む命令１０００個あたりのロードを例示するグラフである。 図１５は、本明細書に記載の１つ以上の実施形態に係る、ＢＩキャッシュミスを含むロードの割合を例示するグラフである。 図１６は、本明細書に記載の１つ以上の実施形態に係る、異なるＢＩキャッシュサイズごとの、境界チェックに伴う平均速度低下を例示するグラフである。 図１７は、本明細書に記載の１つ以上の実施形態に係る、異なるＢＩキャッシュサイズごとの、ＢＩキャッシュミス率（BICache miss-rates）を例示するグラフである。 図１８は、本明細書に記載の１つ以上の実施形態に係る、境界チェックに関連するメモリ帯域幅のオーバーヘッド（memory bandwidth overhead）を例示するグラフである。 図１９は、本明細書に記載の１つ以上の実施形態に係る、ＢＩテーブルに関連するメモリ帯域幅のオーバーヘッドを例示するグラフである。 図２０Ａは、本明細書に記載の１つ以上の実施形態に係る、メモリ内のＢＩテーブルを初期化するための動作フローを例示する図である。 図２０Ｂは、本明細書に記載の１つ以上の実施形態に係る、メモリ内のＢＩテーブルを初期化するための動作フローを例示する図である。 図２０Ｃは、本明細書に記載の１つ以上の実施形態に係る、メモリ内のＢＩテーブルを初期化するための動作フローを例示する図である。 図２０Ｄは、本明細書に記載の１つ以上の実施形態に係る、メモリ内のＢＩテーブルを初期化するための動作フローを例示する図である。 図２０Ｅは、本明細書に記載の１つ以上の実施形態に係る、メモリ内のＢＩテーブルを初期化するための動作フローを例示する図である。 図２０Ｆは、本明細書に記載の１つ以上の実施形態に係る、メモリ内のＢＩテーブルを初期化するための動作フローを例示する図である。 図２０Ｇは、本明細書に記載の１つ以上の実施形態に係る、メモリ内のＢＩテーブルを初期化するための動作フローを例示する図である。 図２１Ａは、本明細書に記載の１つ以上の実施形態に係る、メモリ割り当て関数（memory allocation function）を処理するための動作フローを例示する図である。 図２１Ｂは、本明細書に記載の１つ以上の実施形態に係る、メモリ割り当て関数を処理するための動作フローを例示する図である。 図２１Ｃは、本明細書に記載の１つ以上の実施形態に係る、メモリ割り当て関数を処理するための動作フローを例示する図である。 図２１Ｄは、本明細書に記載の１つ以上の実施形態に係る、メモリ割り当て関数を処理するための動作フローを例示する図である。 図２１Ｅは、本明細書に記載の１つ以上の実施形態に係る、メモリ割り当て関数を処理するための動作フローを例示する図である。 図２２Ａは、本明細書に記載の１つ以上の実施形態に係る、ロード命令（load instruction）を処理するための動作フローを例示する図である。 図２２Ｂは、本明細書に記載の１つ以上の実施形態に係る、ロード命令を処理するための動作フローを例示する図である。 図２２Ｃは、本明細書に記載の１つ以上の実施形態に係る、ロード命令を処理するための動作フローを例示する図である。 図２２Ｄは、本明細書に記載の１つ以上の実施形態に係る、ロード命令を処理するための動作フローを例示する図である。 図２２Ｅは、本明細書に記載の１つ以上の実施形態に係る、ロード命令を処理するための動作フローを例示する図である。 図２２Ｆは、本明細書に記載の１つ以上の実施形態に係る、ロード命令を処理するための動作フローを例示する図である。 図２２Ｇは、本明細書に記載の１つ以上の実施形態に係る、ロード命令を処理するための動作フローを例示する図である。 図２２Ｈは、本明細書に記載の１つ以上の実施形態に係る、ロード命令を処理するための動作フローを例示する図である。 図２２Ｉは、本明細書に記載の１つ以上の実施形態に係る、ロード命令を処理するための動作フローを例示する図である。 図２２Ｊは、本明細書に記載の１つ以上の実施形態に係る、ロード命令を処理するための動作フローを例示する図である。 図２２Ｋは、本明細書に記載の１つ以上の実施形態に係る、ロード命令を処理するための動作フローを例示する図である。 図２３は、本明細書に記載の１つ以上の実施形態に係る、ポインタを例示する図である。 図２４は、本明細書に記載の１つ以上の実施形態に係る、ポインタを例示する図である。 図２５は、図２４のポインタに対して実行される加算演算（addition operation）を例示する図である。 図２６は、本明細書に記載の１つ以上の実施形態に係る、ヒープオブジェクトに関するハードウェアベースのメモリエラー軽減を容易にすることが可能なコンピュータ実装方法を例示するフローチャートである。 図２７は、本明細書に記載の１つ以上の実施形態を容易にすることが可能な動作環境を例示するブロック図である。

以下の詳細な説明は例示に過ぎず、実施形態もしくはその適用物もしくは用途、またはその両方を制限することを意図するものではない。さらに、上述の「背景技術」もしくは「発明の概要」、または「発明を実施するための形態」に示される、いずれの明示的または黙示的な情報によっても拘束されるものではない。

以下、添付図面を参照して各実施形態について説明する。図中、同様の要素については同様の符号にて示す。以下の説明において、各実施形態のより完全な理解を目的として、多くの具体的詳細を示して説明する。ただし、種々の場合において、各実施形態はこれらの具体的詳細を含まずに実施可能である。

ＣやＣ＋＋のようなメモリ安全でない言語（memory-unsafe languages）で書かれたアプリケーションは、ユーザーコードを用いて明示的にメモリを管理するため、バッファオーバーフロー（buffer-overflows）や解放済みメモリ使用（use-after-free）などのメモリの安全性に関わるエラーが発生しやすい。これらのエラーは従来、モリスワーム（Morris worm）やハートブリード（Heartbleed）などの有名な攻撃を含め、数多くの攻撃に悪用されてきた。さらに、これらのエラーは、米国の非営利団体であるＭＩＴＲＥ社によって、最も危険なソフトウェアバグの一つとして位置付けされている。あるテクノロジー企業が最近行った調査によると、当該企業の製品ソフトウェア（production-software）において確認された共通脆弱性識別子（ＣＶＥ：Common Vulnerabilities and Exposures）の約７０％は、依然としてこれらのエラーが原因であることが明らかになった。特に、ヒープ破損（heap corruption）、境界外アクセス（out-of-bounds accesses）、解放済みメモリ使用を含む、ヒープオブジェクトに固有のエラーが、２０１９年のＣＶＥのほぼ５０％を占めている。

現在までに、これらのエラーを検出または防止するための手法が数多く提案されており、それらはブラックリスト型とホワイトリスト型の手法に大別される。ブラックリスト型のアプローチは、（一部の）安全でない場所へのアクセスを（例えば、オブジェクトの周囲にトリップワイヤを挿入するなどして）防止するもので、性能面での過大なオーバーヘッドや、プログラムソースコードを侵襲的に変更しなければならないなどの導入障壁が、一般的に少ない。しかし、ブラックリスト型のアプローチでは完全なカバーができないため、一部のエラーが検出されずに残ってしまい、自由に悪用されてしまう。これに対して、ホワイトリスト型のアプローチは、承認（例えば、すべてのポインタの逆参照（dereferences）がオブジェクト境界（object-bounds）内にあることを検証する境界チェックメカニズム）に基づいて安全なプログラム動作を実施し、メモリの空間的・時間的安全性（spatial and temporal memory-safety）のより正確な確保を可能にする。しかし、ホワイトリスト型のアプローチは多くの場合、大きな速度低下（slowdown）を伴い、２４％～１１６％の速度低下が発生し得る。さらに、ホワイトリスト型のアプローチは、ソースコードやバイナリレイアウトに破壊的な変更（disruptive changes）を必要とすることが多く、その採用を難しくしている。メモリの安全性を強化するための実用的な手法としては、ホワイトリスト型のアプローチの性能や互換性に関する欠点を無くしつつ、その強固なセキュリティを利用することが理想である。

上述したように、Ｃ／Ｃ＋＋で書かれたアプリケーションでは、安全性のチェックなしにポインタの操作が許可されているため、ポインタが無効なメモリ領域を逆参照するメモリエラーが発生しやすい。空間的エラー（境界外アクセス）は、未検証（unvalidated）の入力を用いたポインタ演算（pointer-arithmetic）により、バッファポインタがバッファ境界（buffer-bounds）を超えてメモリにアクセスすることで発生する可能性がある。同様に、時間的エラー（例えば、解放済みメモリ使用）は、ダングリングポインタ（メモリが再使用された解放済みのオブジェクトを指すポインタ）を使用した読み出しまたは書き込みから発生する可能性がある。これらのエラーによるメモリリークやメモリ破損を悪用して、データの機密性を侵害したり、権限昇格（privilege escalation）を試みたり、システム整合性を破壊したりするなどの攻撃が行われている。メモリの安全性を強化し、メモリエラーを防止することで、製品ソフトウェアに対するこのような攻撃の防止を図ることができる。メモリの安全性の強化およびメモリエラーの防止のために、種々の手法が実施可能である。

かかる手法には、トリップワイヤ、ランダム化、タグ付きメモリのいずれかを用いて、オブジェクト境界を越えるメモリアクセスを確率的に検出可能な確率的手法（probabilistic techniques）が含まれる。トリップワイヤを利用した手法の一例として、Ｇｏｏｇｌｅ ＬＬＣ（カリフォルニア州マウンテンビュー）が提供するアドレスサニタイザ（ＡＳＡＮ：AddressSanitizer）が挙げられる。トリップワイヤを利用した手法は一般的に、オブジェクトの周囲にレッドゾーン（red-zones）またはトリップワイヤを挿入して、オブジェクトの境界を少しだけ超えるような一般的な空間的バグ（spatial bugs）を検出する。ランダム化を利用した手法の一例として、ＤｉｅＨａｒｄが挙げられる。ランダム化を利用した手法は一般的に、メモリアロケータ（memory-allocator）のサポートによりメモリレイアウトをランダム化して、バグの検出を容易にする。ハードウェアベースのメモリタギング手法の一例として、Ａｒｍ Ｌｉｍｉｔｅｄ社（英国ケンブリッジ）が提供するＭＴＥ（Memory Tagging Extension）が挙げられる。ハードウェアベースのメモリタギング手法は一般的に、オブジェクトとポインタのペアにランダムな４ビットのタグ（「色」）を割り当て、「色」の不一致に基づいて、確率的にバグを検出することを容易にする。確率的手法は、速度低下や互換性の問題を最小限に抑えることができるため、比較的容易に採用できるが、その設計上、エラー検出を完全にカバーできない場合がある。

また、かかる技術には、オブジェクトのベースおよび境界を追跡し、すべてのオブジェクトアクセスに対して境界チェックを実施することで、安全なプログラム動作を正確に実施可能な、境界チェック型手法も含まれる。図１に示すように、境界チェック型手法１００は、それぞれの境界メタデータの場所に基づいてグループ分けすることができる。例えば、境界チェック型手法１００は、隣接境界グループ（adjacent bounds group）１１０を含む。隣接境界グループ１１０は、ＣＣｕｒｅｄやＣｙｃｌｏｎｅのようなファットポインタ（fat-pointer）を利用した手法を含む。ファットポインタを利用した手法では、ベースと境界のメタデータを、実際のポインタ値と並んで別個のワードに格納することができる。このようにベースと境界のメタデータを格納することにより、実際のポインタが逆参照された際に、境界チェックの実行を容易にして空間的エラーを検出することができる。同様に、ファットポインタを利用した手法の一部の例では、ポインタを２５６ビットの「能力（capabilities）」に置き換えることができる。能力には、アドレス、境界情報、許可ビット（permission bits）やその他のメタデータを含むことができ、境界チェックと共に、きめ細かなコンパートメント化（fine-grain compartmentalization）の実行を図ることができる。しかしながら、境界チェック型手法のうち隣接境界グループ１１０は通常、ソースコードの変更を必要とし、また、バイナリレイアウトの変更を必要とするため、ライブラリコードとの互換性に影響を与える。

境界チェック型手法の他の例は、ローファットポインタ（Low-Fat-pointer）を用いた手法であるインライン境界グループ（inline bounds group）１２０である。ローファットポインタを用いた手法では、バイナリレイアウトに影響を与えることなく、ポインタ内にオブジェクト境界をインラインでエンコードすることができる。ローファットポインタを用いた手法の一例として、コンパクトな浮動小数点フォーマット（floating-point format）を使用して、オブジェクトのベースアドレスおよび境界アドレス（の最下位ビット（least significant bits））を、６４ビットポインタの上位１８ビットに格納することができる。ローファットポインタを用いた手法の他の例として、サイズ調整された（size-aligned）ベースアドレスにおけるメモリのサイズ別のパーティション（size-specific partitions）にオブジェクトを割り当て、ポインタ値にベースと境界を暗黙的にエンコードすることができる。これらのローファットポインタを用いた手法の例では、ポインタがインライン境界（inline-bounds）を越えることがないように、（ハードウェア内で、またはコンパイラ／インスツルメンテーション（instrumentation）によって挿入された明示的な命令を介して）ポインタ演算を追跡することができる。しかしながら、境界チェック型手法のうちインライン境界グループ１２０は通常、ダングリングポインタ内の境界を利用する挿入されたチェック（inserted check）が、ポインタの参照先メモリが再使用された後でも依然として合格となるため、時間的な安全性を確保できない。

境界チェック型手法の他の例は、分離境界グループ（disjoint bounds group）１３０である。分離境界グループ１３０における境界チェック型手法は、境界メタデータを（ポインタごとまたはオブジェクトごとに）シャドウメモリ内の分離テーブル（disjoint table）に格納することができ、バイナリレイアウトに対する変更を回避することができる。境界テーブルは通常、ポインタ値を使用して、線形テーブルルックアップ（linear table lookup）として、またはマルチレベルトライルックアップ（multi-level trie lookup）を使用してインデックスされる。このような境界チェック型手法は、ポインタの逆参照またはすべてのポインタ演算に対して、（ソフトウェアによって挿入されるか、またはハードウェアによって暗黙的に挿入される）テーブルルックアップを用いた境界チェックを実行することで、空間的エラー（一部の設計においては、時間的エラーも）を検出することができる。分離境界グループ１３０のうち、純粋にソフトウェアベースの手法は、ポインタ演算時やテーブルルックアップ用に境界メタデータを伝達（propagate）するための追加命令を必要とするため、大きな性能オーバーヘッド（例えば、平均で５０％～１１２％）が発生する可能性がある。また、分離境界グループ１３０のうち、ハードウェアベースの手法は、マイクロコードまたは専用ハードウェアを使用して境界を伝達し、チェックを実行することにより、ソフトウェアベースの手法と比較してオーバーヘッドを小さくすることができる。しかしながら、このようなハードウェアベースの手法は、境界メタデータにアクセスするためにポインタ値を使用して高コスト（expensive）のテーブルルックアップを行うため、中程度または大きな速度低下が継続して発生する可能性がある。

上述した種々のメモリ保護手法とは異なり、本開示の実装態様は、オブジェクト境界を正確に実施して空間的エラーを防止可能なハードウェアベースの境界チェッカーを用いる。このハードウェアベースの境界チェックフレームワークの実施形態によれば、ダングリングポインタの境界を効率的に無効化して、時間的エラーを検出することが容易になる。実用上、このハードウェアベースの境界チェックフレームワークの実施形態は、性能オーバーヘッドを低減し、またバイナリレイアウトの変更を回避できることが望ましい。そのために、本開示の実装態様は、ポインタを一意のインライン識別子（unique inline identifier）と関連付けることが可能な境界メタデータ設計を含み、当該識別子は、分離境界テーブルへのインデックスに使用することができる。本開示の１つ以上の実装態様は、境界チェック型手法として、インラインインデックス・分離境界グループ（inline index, disjoint bounds group）１４０を含む。

図２は、本明細書に記載の１つ以上の実施形態に係る、ヒープオブジェクトに関するメモリエラー軽減を容易にすることが可能なシステム２００を例示するブロック図である。システム２００は、コンピュータ実行可能コンポーネントを記憶するための非一時的なコンピュータ可読記憶媒体（記憶媒体）２１０と、１つ以上の通信バス２３０を介して記憶媒体２１０に動作可能に接続され、記憶媒体２１０に記憶されたコンピュータ実行可能コンポーネントを実行するための１つ以上のプロセッサ２２０と、を含む。図２に示すように、コンピュータ実行可能コンポーネントは、エントリコンポーネント（entry component）２４０と、転用コンポーネント（re-purpose component）２５０とを含む。

エントリコンポーネント２４０は、オブジェクトがメモリに割り当てられた際に、境界情報を格納するためのテーブルにエントリを割り当てることができる。転用コンポーネント２５０は、オブジェクトアドレスの未使用ビット（unused bits）を転用（re-purpose）して、テーブルのエントリへのインデックスを格納することができる。一の実施形態において、転用コンポーネント２５０は、オブジェクトアドレスの未使用ビットを再利用して、アクセス可能なメモリアドレスの範囲を追跡することができる。

一の実施形態において、記憶装置２１０に記憶されたコンピュータ実行可能コンポーネントはさらに、チェックコンポーネント（check component）２６０を含むことができる。チェックコンポーネント２６０は、アドレス内のインデックスビット（index bits）を使用して境界情報にアクセスすることにより、ロード命令およびストア命令に対する境界チェックをハードウェアで実行することができる。一の実施形態において、チェックコンポーネント２６０は、配列の境界（array bounds）をチェックすることができる。一の実施形態において、チェックコンポーネント２６０は、配列参照（array reference）が境界内（in-bounds）か境界外かを判定し、境界外の配列参照の発生を軽減（mitigate）することができる。

一の実施形態において、記憶装置２１０に記憶されたコンピュータ実行可能コンポーネントはさらに、伝達コンポーネント（propagation component）２７０を含むことができる。伝達コンポーネント２７０は、後続のオブジェクトアドレスが割り当てステートメント（assignment statements）またはポインタ演算を介して導出される際に、インデックスを自動的に伝達することができる。一の実施形態において、伝達コンポーネント２７０は、オブジェクトアドレスが割り当てステートメントにコピーされる際に、未使用ビットで追加の情報（extra information）を伝達することができる。一の実施形態において、伝達コンポーネント２７０は、オブジェクトアドレスが関数呼び出し（function call）の引数として渡される際に、未使用ビットで追加の情報を伝達することができる。一の実施形態において、伝達コンポーネント２７０は、オブジェクトアドレスがアドレスの計算に使用される際に、未使用ビットで追加の情報を伝達することができる。本実施形態が利用するコンピュータ実行可能コンポーネントの機能については、以下でさらに詳しく説明する。

ハードウェアで境界チェックを行うための低コストかつ低侵襲型フレームワークを、以下に開示する。本開示の手法は、ヒープオブジェクトに関するメモリの安全性を低コストでありながら正確に確保するための、ハードウェア対応の（hardware-enabled）ポインタ境界チェックフレームワークを用いる。一の実施形態において、ヒープオブジェクトに関する本開示の境界チェックフレームワークは、ＬＬＶＭインスツルメンテーション（LLVM-instrumentation）を用いて、プログラム中のｍａｌｌｏｃ／ｆｒｅｅ呼び出しを、境界情報を維持するためのカスタムライブラリ関数（custom library-functions）に置き換えることで実装することができる。

以下でさらに詳しく説明するように、本開示の手法を実装することにより、ポインタ逆参照に対するオブジェクト境界の正確な実施を通じてヒープオブジェクトのメモリエラーを軽減し、境界外アクセスや解放済みメモリ使用のエラーを防止することが容易になる。本開示の手法は、性能に対する影響を最小限にしつつ、オブジェクト境界の正確な実施を容易にする。さらに、本開示の手法は、ソースコードまたはバイナリレイアウトに変更を加えることなく実装することができる。本開示の手法の実施形態によれば、垂直統合型（vertically integrated）のハードウェア／ソフトウェア（ＨＷ／ＳＷ）エコシステムにおいて、ハードウェアによる境界チェックを再検討（re-think）することにより、ヒープオブジェクトのメモリエラーを軽減することができる。その際、Ｃ／Ｃ＋＋メモリ割り当て関数、命令セットアーキテクチャ（ＩＳＡ）、およびハードウェアに対する変更は最小限に抑えられる。

本開示の手法の一態様は、ポインタ内の「未使用ビット」を転用して、当該ポインタを介して正当に（legitimately）アクセス可能なアドレスの範囲をチェックまたは追跡する。６４ビットアーキテクチャでは、オブジェクトポインタは通常、４８ビット以下の情報を持つ仮想アドレスを格納するため、ポインタ内に未使用ビットが存在する。本開示の手法は、これらの未使用ビットを活用して、（ａ）オブジェクトが割り当てられる際に、境界情報を格納するための境界テーブルにエントリを割り当て、（ｂ）オブジェクトポインタの未使用ビット（例えば、上位ビット）を転用して、境界テーブルのエントリへのインデックスを格納する、（ｃ）後続のアドレスが割り当てステートメントまたはポインタ演算を介して導出される際に、インデックスを自動的に伝達する、もしくは、（ｄ）アドレス内のインデックスビットを使用して適切な境界情報にアクセスすることにより、ロード命令およびストア命令に対する境界チェックをハードウェアで実行する、または、これら（ａ）～（ｄ）の組み合わせを実行する。

本開示の手法はこれらの未使用ビットを活用することにより、ヒープオブジェクトの空間的・時間的安全性の確保を容易にし、ヒープの境界外の読み出し・書き込みや、解放済みメモリ使用などのエラーを防止することができる。ヒープエラーの軽減に加えて、本開示の手法の１つ以上の実施形態は一般に、グローバルオブジェクトおよびスタックオブジェクト（globals and stack-objects）のメモリ安全性の確保にも適用可能である。かかるエラーは、テクノロジー企業の調査に関して先に述べたＣＶＥのほぼ５０％を占め、さらに、Ｇｏｏｇｌｅ ＬＬＣ（カリフォルニア州マウンテンビュー）が提供するＯＳＳ－Ｆｕｚｚサービスで検出されたメモリ安全性のバグのほぼ６０％を占めているため、防止することが望ましい。

図３は、本明細書に記載の１つ以上の実施形態に係る、オブジェクトポインタの未使用ビット（例えば、上位ビット）を再利用して、ヒープオブジェクトの空間的・時間的安全性を確保する手法の概要を概念的に例示する図である。図３に示すように、本開示の手法は概して、オブジェクトポインタの未使用ビット（例えば、上位ビット）を転用して、当該オブジェクトポインタに対応する境界メタデータを含む境界情報テーブル（ＢＩテーブル（BITable））内のエントリへのインデックスを格納する。一の実施形態において、ＢＩテーブルは、プロセスごと（per-process）のＢＩテーブルである。１つ以上の実施形態において、本開示の手法は、Ｃライブラリのメモリ割り当て関数をインターセプトして、ｍａｌｌｏｃでＢＩテーブルにエントリを割り当て、ｆｒｅｅで当該エントリを無効にする。図３に示すように、ＢＩテーブルは、ヒープ上の各オブジェクトの境界メタデータのチェックや追跡を容易にすることができる。かかるメタデータは、ハードウェアでのロード／ストア実行時の境界チェック動作を通じて、ポインタ逆参照に対する境界チェックを実行するのに使用可能である。本開示の手法は、オブジェクトポインタの未使用ビット（例えば、上位ビット）に格納された境界テーブルエントリへのインデックスを用いて、オブジェクトのライフタイム（lifetime）中における境界外アクセスを検出する。図３に示すように、本開示の手法はさらに、オブジェクトの解放後、無効な境界テーブルエントリを指すダングリングポインタ内のインデックスを用いて、解放済みメモリ使用エラーを検出する。

注目すべき点として、本開示の手法は、ファットポインタを用いた従来のアプローチとは異なり、バイナリレイアウトに対する変更を容易に回避することができる。さらに、本開示の手法は、あるポインタが別のポインタに割り当てられたり、関数呼び出しで渡されたり、配列のインデックス作成やポインタ演算において別のアドレスを計算するために使用されたりする際に、インデックス伝達のためのオーバーヘッド（プログラムのセマンティクス（program semantics）によって「自動的に」発生する可能性がある）が発生しない。これに対して、既存の手法では、ポインタメタデータを伝達させるために追加の命令やマイクロオペレーション（micro-ops）が必要になる可能性がある。一の実施形態において、インデックスの伝達は、「追加の」命令をフェッチしたり実行したりすることなく、「自動的」に行われる。

さらに、少なくとも次の２つの理由から、実際の境界チェックによる性能への影響は最小限に抑えることができる。第一に、所与のバッファに関連付けられたすべてのアドレスは同一のインデックスを持つことができるので、アドレスのインデックスビットと境界情報は、多くの場合、オンチップの境界情報（ＢＩ）キャッシュ（on-chip BI cache）で利用可能である。実装例のシミュレーションでは、８ＫＢのオンチップＢＩキャッシュを使用した場合、境界情報のヒット率が９８％超となった。第二に、ロード操作またはストア操作（load or store operation）に対する境界チェックは、当該ロード操作またはストア操作のアドレス変換（address translation）と並行して行うことができる。そしてこれは多くの場合、ロード命令またはストア命令に余分な遅延を追加することなく行うことができる。最後に、（インデックスによって特定可能な）境界情報の場所はポインタ値とは無関係であるため、本開示の手法によれば、解放済みメモリが再使用された後でも、ダングリングポインタの無効な境界ステータス（invalid-bounds status）を維持することができる。さらに、本開示の手法は、境界メタデータの場所がポインタ値とリンクしていることが多い既存のハードウェアベースの境界チェック手法とは異なり、追加のコストを必要とすることなく時間的安全性を確保することができる。

一の実施形態において、ヒープオブジェクトに関する本開示の境界チェックフレームワークは、１つ以上の仮定（assumptions）を含む脅威モデル（threat model）を含むことができる。仮定は例えば、プログラムには、境界外アクセス、解放済みメモリ使用、二重解放（double-free）、無効解放（invalid-free）などのヒープメモリの安全性に関するバグが存在する可能性がある、というものである。また、仮定は例えば、このようなメモリバグを悪用しようと、攻撃者（adversary）によって未検証の入力（unverified inputs）がプログラムに渡される可能性がある、というものである。また、仮定は例えば、攻撃者は、ユーザプログラムコードを変更してバグを導入したり、境界メタデータに直接アクセスしたり改ざんしたりすることはできない、というものである。また、仮定は例えば、境界メタデータを管理するために本開示のフレームワークが使用可能なメモリアロケータ関数（memory-allocator functions）は、バグが存在せず信頼できる、というものである。

本開示の境界チェックフレームワークの一態様は、プログラムの仮想アドレス空間内のＢＩテーブルに、オブジェクトの境界メタデータをそのライフタイムにわたって格納する。一の実施形態において、ＢＩテーブルは、プロセスごとのＢＩテーブルである。本開示の境界チェックフレームワークの他の態様は、プログラム実行時に（at runtime）、すべてのオブジェクトアクセスに対してハードウェアベースの境界チェックを行う。

図４は、本明細書に記載の１つ以上の実施形態に係る、プログラム実行時のポインタの寿命（life-cycle）の概要を概念的に例示する図である。図４に示すように、オブジェクトの作成時に、ＢＩテーブルにエントリ（ＢＩエントリ（BIEntry））を作成することができる。ＢＩエントリは、オブジェクトのベースアドレスとサイズの格納に使用可能である。他の実施形態において、ＢＩエントリは、オブジェクトの上境界と下境界（upper and lower bounds）に対するアドレスの格納に使用可能である。ＢＩテーブル内の対応するエントリへのインデックスは、ポインタの未使用ビット内に埋め込むことができる。本明細書において「インデックスビット」という用語は、ＢＩテーブル内の対応するエントリへのインデックスが埋め込まれる、ポインタの未使用ビットを意味する。実装を簡単にするため、以下の説明では、ポインタの上位２４ビット（top 24-bits）がインデックスビットとして使用可能であるものとして説明する。ただし、本開示の実施形態のインデックスビットは、ポインタの連続（contiguous）ビットまたは上位２４ビットに限定されない。一の実施形態において、インデックスビットは不連続（non-contiguous）である。一の実施形態において、ポインタの１つ以上のビットが、当該ポインタのインデックスビットに先行する。さらに、図４に示すように、ハードウェアは、上位ビット内のインデックスを用いて対応するＢＩエントリにアクセスすることができ、ポインタが逆参照された際に、境界チェックを実行して境界外アクセスを検出することができる。さらに、図４に示すように、オブジェクト解放時には、対応するＢＩエントリを無効化することができる。対応するＢＩエントリを無効化することで、これら解放済みオブジェクトを指すダングリングポインタが後に使用された場合に、時間的エラーの検出が容易になる。

図５は、本明細書に記載の１つ以上の実施形態に係る、境界チェックフレームワークの構成レイアウト５００を例示する図である。図５に示すように、ソフトウェア要素によってＢＩテーブルを管理することができる。例えば、ｍａｌｌｏｃ関数やｆｒｅｅ関数のフックを用いて、これらの関数の呼び出しをインターセプトし、関連するＢＩテーブルの動作（ＢＩエントリの割り当てや無効化など）を実行することができる。このようなフックは、プログラムのコンパイル時にリンカによって追加可能な共有ライブラリ（shared-library）で定義することができる。さらに、このようなフックは、ソースコードの変更を必要としたり、バイナリレイアウトの変更に伴う互換性の問題が発生したりすることなく、プログラムのコンパイル時に追加することができる。さらに、図５に示すように、このバイナリ（binary）が動作するハードウェア要素は、すべてのロード命令もしくはストア命令またはその両方に対して境界チェックを透過的に（transparently）実行し、メモリ安全性違反（memory safety violations）を検出することができる。また、ロード命令もしくはストア命令またはその両方の実行をハードウェアで変更することにより、ＢＩテーブルにアクセスして境界チェック用の境界メタデータを取得するようにすることもできる。また、境界情報キャッシュ（ＢＩキャッシュ）を追加することにより、メモリ内のＢＩテーブルへのアクセスによる速度低下を制限することができる。

図６は、本明細書に記載の１つ以上の実施形態に係る、ＢＩテーブル６００を例示する図である。上述したように、ＢＩテーブル６００はプログラムの仮想アドレス空間内に保持することができる。ＢＩテーブル６００は、プログラム内の各ヒープオブジェクトの境界メタデータを格納することができる。さらに、ＢＩテーブル６００は、ヒープオブジェクトに対する各ロード命令もしくはストア命令またはその両方ごとにアクセスし、境界チェックを実行することができる。

図６に示すように、ＢＩテーブル６００は複数のＢＩエントリ（例えば、ＢＩエントリ６１０）を含む線形テーブル（linear table）として構成することができる。各ＢＩエントリは、ベースアドレスフィールド６２０とオブジェクトサイズフィールド６３０とを含む。図６において、ＢＩテーブル６００の各ＢＩエントリは、６４ビットのベースアドレスフィールドと６４ビットのオブジェクトサイズフィールドとを含む１６バイトのＢＩエントリとして実装される。一の実施形態において、ＢＩテーブル６００の各ＢＩエントリは、４８ビットのベースアドレスフィールドと４８ビットのオブジェクトサイズフィールドとを含む１２バイトのＢＩエントリとして実装してもよい。ＢＩテーブル６００の各ＢＩエントリは、ヒープオブジェクトと関連付けることができる。所与のオブジェクトに対応するＢＩテーブル６００の特定のＢＩエントリにアクセスするには、１回のテーブルルックアップ（single table-lookup）を行うだけでよい（ＢＩＴａｂｌｅ［ｉｎｄｅｘ］）。この１回のテーブルルックアップでは、オブジェクト割り当て時にポインタ６５０に埋め込み可能なインデックス６４０を使用することができる。これに対して、図１を参照して上述した境界チェック型手法のうち、分離境界グループ１３０の一部の実装形態を用いて境界メタデータにアクセスする場合は、ポインタ値そのものを用いた複数レベルのテーブルルックアップ（multi-level table lookups）が必要な可能性がある。

ＢＩテーブル用のメモリ空間は、プログラムの初期化時にｍｍａｐ呼び出しでＭＡＰ＿ＡＮＯＮＹＭＯＵＳフラグを指定して予約することができ、これにより、アクセス時に物理ページを遅延割り当て（allocated lazily）することが容易になる。したがって、ＢＩテーブルが消費するメモリは、プログラム内でメモリ割り当てされた（malloced）オブジェクトの数に比例して増大する。ＢＩテーブルのベースの仮想アドレスとそのサイズは、専用ハードウェアレジスタ（それぞれＢＴＢＡＳＥおよびＢＴＳＩＺＥ）に格納することができる。一の実施形態において、これらの専用ハードウェアレジスタは、特権ソフトウェア（privileged software）から、またはハードウェア内部からのみアクセス可能である。ＢＩテーブルのベースの仮想アドレスとそのサイズは、ｘ８６アーキテクチャのページテーブルベース（page-table base）を格納するＣＲ３レジスタと同様に、コンテキストスイッチによって他のプロセス状態と共に保存もしくは復元またはその両方を行うことができる。これにより、ハードウェアが境界チェックを行いながら、ＢＩエントリの仮想アドレスをＢＴＢＡＳＥ ＋ ｉｎｄｅｘ＊１６として計算するのを容易にすることができる。ＢＩテーブルのサイズから、ｆｒｅｅで無効化されたエントリの再使用が必要であるかを決定可能である。一般的にＢＩテーブルは、プログラム内のライブオブジェクト（メモリ割り当て済みであり解放済みでないオブジェクト）の最大数を収容可能な大きさを有している必要がある。ＢＩテーブルのサイズは１６００万エントリ（後述するＳＰＥＣ－ＣＰＵ２０１７のワークロードのうち、ライブオブジェクトの最大数は２４０万であった）に設定可能であるが、ユーザはコンパイル時にそれより小さい値を選択してメモリの消費を抑えることができる。

ＬＬＶＭベースのインスツルメンテーションを用いて、ｍａｉｎが実行される前に、ｍａｌｌｏｃ／ｆｒｅｅフックを初期化することができる。一の実施形態において、ＬＬＶＭベースのインスツルメンテーションでは、ｍａｌｌｏｃ／ｆｒｅｅフックを初期化する関数を挿入することができる。これらのフックにより、プログラムからの後続のｍａｌｌｏｃやｆｒｅｅの呼び出しをインターセプトすることができる。これらの後続の呼び出しでは、内部メモリの割り当て関数の呼び出しや、ＢＩエントリの作成または削除が行われる。特別な命令(ｓｅｔＢＩＥｎｔｒｙ／ｇｅｔＢＩＥｎｔｒｙ)を用いて、信頼済みフック関数（trusted hook functions）内でＢＩエントリを更新またはチェックすることができる。ＢＩテーブルに対する不正な読み出しや書き込みの防止を図るために、これらの特別な命令を使用して、他の非特権ソフトウェア（unprivileged software）（信頼済みメモリアロケータ関数の外部）からのＢＩテーブルへのアクセスを禁止することができる（これは、信頼済みコンパイラまたはランタイムによるバイナリ検査（binary inspection）で実施可能である）。一の実施形態において、ｃｒｅａｔｅＢＩＥｎｔｒｙおよびｄｅｌｅｔｅＢＩＥｎｔｒｙの機能は、ＢＩテーブルの安全性を図るための新たなＩＳＡ命令として実装することができ、非特権的な使用（unprivileged usage）は、ｍａｌｌｏｃ／ｆｒｅｅ関数でのみ許可される（バイナリ検査でこれを確実にすることができる）。ハードウェアは、非特権ソフトウェアからのＢＩテーブルへのロード/ストアを明示的に防止することができる。

ｍａｌｌｏｃ／ｆｒｅｅで呼び出し可能な関数フックの例を、一覧１および２に示す。ｍａｌｌｏｃがインターセプトされると、ｒｅａｌ＿ｍａｌｌｏｃを呼び出すことができる。返されたベースアドレスおよび要求されたオブジェクトサイズは、ｓｅｔＢＩＥｎｔｒｙ命令によってｍａｌｌｏｃがインターセプトされた際に、ＢＩエントリに格納することもできる。最初の１６００万回のｍａｌｌｏｃでは、新しいＢＩエントリをＢＩテーブルで使用することができる。それ以外の場合は、解放されたＢＩエントリのインデックス値を格納可能なＦＩＦＯを用いて、ｆｒｅｅで無効になったＢＩエントリの１つをＦＩＦＯ順に再使用することができる。そして、このＢＩエントリのインデックスは、ポインタの上位２４ビットに埋め込まれ、プログラムに返される。ｆｒｅｅがインターセプトされた際に、このポインタの上位２４ビットのインデックスを用いて、ｇｅｔＢＩＥｎｔｒｙ命令によりＢＩエントリを取得することができる。また、このポインタの上位２４ビットのインデックスは、ポインタ値がオブジェクトのベースアドレスと一致しているかの検証に用いることもできる。そして、ＢＩエントリを無効にすることができ（例えば、対応するオブジェクトのベースアドレスおよびオブジェクトサイズを０に設定することができ）、ｒｅａｌ＿ｆｒｅｅを呼び出してオブジェクトを解放することができる。

一覧１

一覧２

図７は、本明細書に記載の１つ以上の実施形態に係る、プログラムの６４ビット仮想アドレス空間のレイアウト７００を例示する図である。上述したように、本開示の境界チェックフレームワークの１つ以上の実施形態においては、ヒープオブジェクトポインタの上位２４ビットを、ＢＩテーブル内の対応するＢＩエントリのインデックスで置き換えることができる。４レベルのページテーブルを持つ６４ビットのＬｉｎｕｘ（登録商標）システムにおいては、プログラムは通常、４８ビットのユーザ仮想アドレス空間（user Virtual-Address space）を使用可能である。インデックスビットが４８ビットのユーザアドレスの上位８ビットと重複する可能性があるため、図７に示すように、２４ビットのインデックスビットを含むヒープアドレスとプログラムアドレスとの衝突を避けるために、プログラムの仮想アドレス空間を２テラバイト（ＴＢ）の領域に制限することができる。本開示の境界チェックフレームワークの実施形態における、珍しいシナリオ（uncommon scenarios）の対処例は、以下でより詳細に説明する。このような珍しいシナリオの例としては、プログラムが２ＴＢより大きい仮想アドレス空間を必要とする場合、ポインタにおいて十分なインデックスビットが使用できない場合、ＢＩテーブルのサイズが不十分な場合、などがある。

レイアウト７００において、ヒープは０ｘ０から０ｘＦＦＦＦＦＦＦＦＦＦまで上向きに成長（grow upwards）し、スタックは０ｘ７ＦＦＦＦＦＦＦＦＦＦＦから０ｘ７Ｆ００００００００００まで下向きに成長（grow downwards）する。残りの２５４ＴＢのユーザ仮想アドレス空間（すなわち、４８ビットの仮想アドレス空間の残りの部分）は、ＰＲＯＴ＿ＮＯＮＥメモリ保護引数を使用したｍｍａｐ呼び出しで予約することができる。レイアウト７００において、スタックアドレスとの衝突を回避するために、ヒープオブジェクトについてはインデックス値０ｘ７Ｆの使用をスキップすることができる。また、カーネルアドレスとの衝突を回避するために、レイアウト７００における０ｘＦＦＦＦ８０～０ｘＦＦＦＦＦＦまでのインデックス値の使用をスキップすることができる。インデックス０ｘ０はＮＵＬＬポインタ（例えば、ポインタ値「０」）用に予約して、有効なプログラム動作であるＮＵＬＬポインタでのｆｒｅｅ呼び出しをサポートすることができる。

本開示の境界チェックフレームワークにおける境界外アクセスや解放済みメモリ使用の検出は、ロードやストアに対してハードウェアが挿入する境界チェックに依存する。以下、かかるハードウェアベースの境界チェックの設計および実装の一例を説明する。本開示の境界チェックフレームワークのこの例においては、ヒープオブジェクト（上位２４ビットにインデックスが存在することで識別可能）に対するすべてのロードおよびストアは、ロード／ストア実行の一部として、ハードウェアベースの境界チェックを含めることができる。境界チェックでは、インデックスを用いて対応するＢＩテーブルのエントリを検索し、オブジェクトのベースアドレスおよびサイズを取得することができる。ハードウェアベースの境界チェックでは、この取得したオブジェクトのベースアドレスおよびサイズに基づいて、アクセスが［ｂａｓｅ ａｄｄｒｅｓｓ，ｂａｓｅ ａｄｄｒｅｓｓ＋ｏｂｊｅｃｔ ｓｉｚｅ］内であることを確認することができる。この範囲内にない場合、境界外の例外（out-of-bounds exception）を発生させることができる。ＢＩエントリのベースアドレスおよびオブジェクトサイズが０の場合、解放済みメモリ使用の例外（use-after-free exception）を発生させることができる。ＢＩエントリが再使用されていた場合、境界の不一致によりダングリングポインタのアクセスが高確率で検出されるが、これに対して境界外の例外としてフラグを立てることができる。

図８は、本明細書に記載の１つ以上の実施形態に係る、ハードウェアベースの境界チェックを実装するためのハードウェア構成８００を例示する図である。ハードウェアベースの境界チェックの場合、境界チェック対象のＢＩエントリのアドレスは、ＢＩテーブルＢａｓｅレジスタと、ロード／ストアアドレスからのインデックスビットとを用いて、ＢＴＢＡＳＥ＋Ｉｎｄｅｘ＊１６として計算することができ、アドレス変換は通常のロード（regular load）と同じにすることができる。境界チェックは、ロード／ストアの仮想アドレスの準備ができた時点で実行開始することができ、また、ロード／ストアの実行に影響を与えることなくそれと並行して続けることができる。ハードウェアベースの境界チェックは、ロード／ストアのコミットステージ（commit-stage）のクリティカルパス上にのみ存在する。コミットステージは、チェックが合格の場合のみ、ロード／ストアをコミットし、そうでなければ、境界チェックが完了するまで停止する。図８に示すように、ＢＩテーブルのエントリは、ハードウェア構成８００内の専用キャッシュ（ＢＩキャッシュ（BICache））にキャッシュすることができる。専用キャッシュは、Ｌ１－Ｄキャッシュ（L1-Dcache）と同様なものとすることができる。ＢＩキャッシュは、ロード/ストア時にＬ１－Ｄキャッシュと並行してアクセスしてハードウェアベースの境界チェックを行えるため、ハードウェアベースの境界チェックによる性能への影響は最小限に抑えることができる。ＢＩキャッシュにヒットするハードウェアベースの境界チェックは、ロード／ストアのレイテンシ（latency）にほとんど、あるいはまったく影響を与えない。

図９は、本明細書に記載の１つ以上の実施形態に係る、ハードウェアベースの境界チェックに伴う速度低下のシナリオを例示する図である。図９に示すように、速度低下が発生するのは通常、境界チェックがＢＩキャッシュミスとなり、かつ対応するロード／ストア命令がコミットステージに到達するまで境界チェックが保留（pending）となっている場合のみである。

一の実施形態において、本開示の境界チェックフレームワークは、ＢＩテーブルのエントリ用に専用の８キロバイト（ＫＢ）、８ウェイ（8-way）のＢＩキャッシュを用いることができる。ＢＩテーブルへのすべてのアクセス（境界チェックのため、およびｍａｌｌｏｃやｆｒｅｅからＢＩテーブルへのロードとストアのため）は、ＢＩキャッシュを経由させることができる。ＢＩキャッシュの設計は、ＶＩＰＴ（Virtually-Indexed Physically Tagged）方式とすることができる。また、Ｌ１－Ｄキャッシュとほぼ同様の設計とすることができ、レイテンシもＬ１－Ｄキャッシュとほぼ同様とすることができる（ただし、サイズはそれより大幅に小さい）。このような設計にすることにより、ハードウェアベースの境界チェックがＢＩキャッシュでヒットした場合に、ロード／ストアの実行に影響を与えないようにすることができる。ＢＩキャッシュでミスした場合は、簡略化のために、ＢＩエントリはメモリから処理（service）することができる。一の実施形態において、オーバーヘッドの削減をさらに図るため、エントリを最終レベルのキャッシュ（last-level cache）にキャッシュすることもできる。ロード／ストアキューのエントリは、ＢＩキャッシュミスにより境界チェックが遅れた場合に、保留中の境界チェックのステータスを格納するために拡張することができる。保留中の境界チェックのステータスの格納には、４８ビットのＢＩエントリアドレス、１ビットのｃｈｅｃｋＩｓｓｕｅｄフラグ、および１ビットのｃｈｅｃｋＣｏｍｐｌｅｔｅフラグを格納することを含むことができる。

一の実施形態において、本開示の境界チェックフレームワークは、一部の命令についてＩＳＡサポート（ISA support）を利用して、特権を持たない攻撃者（unprivileged adversary）によるＢＩテーブルへの不正アクセスを防止することができる。かかる命令は、ｉｎｉｔＢＩＴａｂｌｅ命令を含むことができる。オペレーティングシステム（ＯＳ）は、ｉｎｉｔＢＩＴａｂｌｅ命令を用いて、ハードウェアのＢＴＢＡＳＥレジスタにおけるＢＩテーブルのベースアドレスをプログラム初期化時に任意の仮想アドレスに設定するとともに、ＢＴＳＩＺＥレジスタにおけるサイズを設定することができる。非特権ソフトウェアからのＢＴＢＡＳＥレジスタもしくはＢＴＳＩＺＥレジスタまたはその両方へのアクセスに対して、例外を発生させることができる。

かかる命令はさらに、信頼済みのｍａｌｌｏｃ／ｆｒｅｅ関数に対してＢＩエントリの書き込みや読み出しを許可するｓｅｔＢＩＥｎｔｒｙ命令やｇｅｔＢＩＥｎｔｒｙ命令を含むことができる。例えば、ｓｅｔＢＩＥｎｔｒｙ命令により、特定のＢＩエントリ（ＢＩＴａｂｌｅ［ｉｎｄｅｘ］＝｛ｂａｓｅ，ｓｉｚｅ｝）を設定することができる。また、ｓｅｔＢＩＥｎｔｒｙ命令は、ｍａｌｌｏｃやｆｒｅｅでＢＩエントリを割り当てたり無効にしたりするのに用いることができる。ｇｅｔＢＩＥｎｔｒｙ命令により、ｆｒｅｅがＢＩエントリを読み出し、解放対象のポインタが有効であるかどうか（ＢＩＴａｂｌｅ［ｉｎｄｅｘ］．ｂａｓｅ＝＝ｐｔｒ＿ｖａｌ）をチェックすることができる。信頼済みのコンパイラまたはランタイムによって、ｓｅｔＢＩＥｎｔｒｙ命令もしくはｇｅｔＢＩＥｎｔｒｙ命令またはその両方が、信頼済みのメモリアロケータ関数でのみ用いられることを容易に確実にすることができる。さらに、ＢＩテーブルがマッピングされているアドレスに対する非特権ソフトウェアによる明示的なロードやストアを、ハードウェアによって容易に防止することができる。これにより、特権を持たない攻撃者がＢＩテーブルのアドレスを推測したとしても、ＢＩテーブルに対して読み出しや書き込みができないようにすることができる。

一の実施形態において、ｍａｌｌｏｃおよびｆｒｅｅのフック関数は、ロック（locks）を使用してＢＩテーブルおよびＢＩテーブルの管理データ構造（例えば、フリーエントリＦＩＦＯ（free-entry FIFO））のアトミック更新（atomic updates）を可能にすることにより、スレッドセーフな方法（thread-safe manner）で実装することができる。さらに、異なるコアにわたるＢＩキャッシュ（ＶＩＰＴ設計）間のコヒーレンスは、既存のキャッシュ－コヒーレンスファブリック（cache-coherence fabric）をハードウェアに用いることにより維持することができる。ＢＩテーブルに対する一のコアからの更新を、他のコアからのアクセスに反映させることができ、追加のソフトウェア介入（extra software intervention）の必要はない。プログラム自体がスレッドセーフに書かれており（例えば、異なるスレッドから同一のオブジェクトに対するアクセスとｆｒｅｅとの間にデータ競合（data race）が発生しない）、かつ内部のメモリアロケータ自体がスレッドセーフである限り、本開示の境界チェックフレームワーク、はマルチスレッドプログラム（multi-threaded programs）との互換性を維持することができる。

上述したように、本開示の境界チェックフレームワークの実施形態を実装した場合、いくつかの珍しいシナリオが発生する場合がある。例外的なケースとして、ＢＩテーブルがプログラムのすべてのＢＩエントリを格納できない場合がある。例えば、プログラムのアクティブオブジェクト数がＢＩテーブルのサイズを超える場合、ＢＩテーブルは当該プログラムのすべてのＢＩエントリを格納できない場合がある。他の例として、ポインタ内で十分な数のインデックスビットが利用できない場合、ＢＩテーブルはプログラムのすべてのＢＩエントリを格納できない場合がある。

このような場合、オーバーフローテーブル（overflow-table）を用いて、境界メタデータを格納することができる。メタデータがオーバーフローテーブルに保持されているポインタは、そのインデックスビットに特別な値を埋め込むことで識別可能である。このようなポインタについては、ポインタ値そのものを用いてオーバーフローテーブルを検索することができる。このようなテーブルルックアップでは、高コストなマルチレベルのテーブルルックアップが必要になる場合があるため、プログラムにおいて、使用頻度の低いＢＩエントリのみをオーバーフローテーブルに配置するようにすることができる。本開示の境界チェックフレームワークを実装して評価したＳＰＥＣ－ＣＰＵ２０１７のワークロードでは、１６００万のエントリ容量のＢＩテーブルで十分以上であり（最大で３００万未満のエントリが使用）、オーバーフローテーブルは必要としなかった。

以下、本開示の境界チェックフレームワークの１つ以上の実施形態において検出可能な、メモリの安全性に関するバグの種類について例示する。また、以下ではさらに、攻撃者による境界チェックメタデータへのアクセスを防止する例を詳しく説明する。また、本開示の境界チェックフレームワークの１つ以上の実施形態を用いて検出可能な、新しい潜在的なバグについても以下で説明する。

本開示の境界チェックフレームワークの実装例を、Ｈｏｗ２Ｈｅａｐエクスプロイトスイート（How2Heap exploit suite）のうち２５のエクスプロイト（exploits）でテストした。Ｈｏｗ２Ｈｅａｐエクスプロイトスイートは、境界外アクセス、解放済みメモリ使用、無効解放、二重解放のようなヒープの空間的・時間的安全性に関するバグを利用するものである。本開示の境界チェックフレームワークの実装例では、これら２５のプログラムすべてにおいてバグを検出し、例外を発生させて、エクスプロイトの目的が達成される前にプログラムを終了させることができた。これらのうち、本開示の境界チェックフレームワークの実装例では、８件のエクスプロイトで境界外アクセスが、１０件のエクスプロイトで解放済みメモリ使用が、７件のエクスプロイトで無効／二重解放が検出された。

境界外アクセスについては、ロード/ストアと並行して挿入される境界チェックによりＢＩエントリをチェックし、アクセスがロードやストアのオブジェクト境界内であることを確認することができる。解放済みメモリ使用については、ロード/ストアに対する境界チェックによってＢＩエントリがベース＝０、サイズ＝０であることが判明した場合は、オブジェクトが最近解放されたか、またはＢＩエントリが初期化されていない（オブジェクトがメモリ割り当てされていない）かのいずれかである。この場合、本開示の境界チェックフレームワークの実装例では、両方のシナリオに対してエラーのフラグを立てることができ、２５件のエクスプロイトのうち１０件において、これらのバグを特定できた。ＢＩエントリがメモリ解放（Free）と解放済みメモリ使用（Use-After-Free）との間で再割り当てされた場合、解放済みメモリ使用を境界外アクセスとして高確率で検出することができる。また、オーバーフローテーブルを使用することで、ＢＩエントリの再使用を完全に回避することもできる。二重解放と無効解放については、解放対象のポインタ（pointer-to-be-freed）が対応するＢＩエントリのオブジェクトベースと一致するかを検証する、ｆｒｅｅに対するＢＩエントリチェックで不一致が検出された場合、無効解放または二重解放のバグを示している可能性がある。ポインタの上位ビットのインデックスが有効な値でない場合、またはＢＩエントリのオブジェクトベースが一致しない場合は、無効解放バグのフラグを立てることができる。あるいは、ＢＩエントリのベースとサイズが０の場合、二重解放バグのフラグを立てることができる。

本開示の境界チェックフレームワークの１つ以上の実施形態において、ロードまたはストアの境界をチェックするために用いられる２種類のメタデータは、（ｉ）境界を含むＢＩテーブルにおけるＢＩエントリ、および（ｉｉ）ＢＩテーブルにアクセスするために用いられるポインタ内のインデックスビット、である。以下、本明細書の記載の１つ以上の実施形態による、この２種類のメタデータを保護する例を説明する。

ＢＩテーブルの保護については、特権を持たない攻撃者が、ＢＩテーブルを直接読み出したり変更したりすることはできない。ＢＩテーブルがマッピングされている仮想メモリに対する非特権ソフトウェアによるロードやストアの実行は、ハードウェアによって阻止することができる。このチェックは、ＢＴＢａｓｅからＢＴＢａｓｅ＋ＢＩＴａｂｌｅＳｉｚｅまでのアドレス範囲に対する特権のないロードやストアを阻止することにより、ロード/ストアユニットによって実施することができる。非特権ソフトウェアに対してＢＩテーブルへのアクセスを許可するｓｅｔＢＩＥｎｔｒｙおよびｇｅｔＢＩＥｎｔｒｙ命令は通常、信頼済みのメモリアロケータ関数内でのみ許可される（これは、信頼済みのコンパイラまたはランタイムによって実施することができる）。概して、特権ＯＳもしくはシステムソフトウェア、またはハードウェアのみがＢＩテーブルに直接アクセスすることができる。

ポインタのインデックスビットの保護については、攻撃者が被害者コード（victim code）を変更して、任意にポインタを上書きしたり、ワイルドポインタ（wild pointers）を生成したりすることはできないとの想定が可能である。しかし、攻撃者が被害者コードに含まれる安全でないポインタ演算を利用して、未検証の入力を用いてオーバーフローまたはアンダーフロー（underflow）を引き起こし、インデックスビットを破損させようと試みる可能性がある。このような破損は、本明細書に記載の１つ以上の実施形態に従って実装される境界チェックにおいてエラーとして検出される場合が多い。また、ＣＰＵのレジスタを拡張してポインタのインデックスビットを個別に格納し、インデックスビットをポインタ演算から明示的に分離することによっても、インデックスビットの破損を防ぐことができる。

以下、本開示の境界チェックフレームワークの実施形態により実装され、Ｇｅｍ５でモデリングされた境界チェック例に対する試験例の結果について説明する。本試験例は、ｃｌａｎｇ－１１とＧｌｉｂｃ－ｖ２．２７を使用してコンパイルされた１３個のＣ／Ｃ＋＋ＳＰＥＣ－ＣＰＵ２０１７バイナリを用いて行った。以下、ポインタアクセスをオブジェクトの割り当て境界（allocation-bounds）に対してチェックした際に、本境界チェック例が検出した境界外アクセスについて説明する。ここで、ＢＩエントリは、ｍａｌｌｏｃによって割り当てられた１６バイトの整列サイズ（16-Byte aligned size）を格納している。本開示の境界チェックフレームワークの１つ以上の実施形態はさらに、プログラムによって要求されるオブジェクトサイズをＢＩエントリに格納することによって、バイト粒度の境界チェック（byte-granularity bounds-checks）をサポートする。

図１０に、本試験例の結果を示す。具体的には、図１０は、本開示の境界チェックフレームワークの実施形態によって境界外アクセスが検出された関数を例示するグラフ１０００である。図１０は、本開示の境界チェックフレームワークの実装例によって、Ｇｅｍ５シミュレータ上で１１０億個の命令に対して実行された１３個のＳＰＥＣ Ｃ／Ｃ＋＋バイナリにわたって境界外アクセスが検出された関数を示す。全体として、図１０に示すように、この境界チェックフレームワークの実装例では、８７行のコードで境界外アクセスが検出された。８７行のコードのうち、８０行のコードは、高度に最適化されたＧｌｉｂｃ－ｖ２．２７の文字列処理用の関数（ｓｔｒｌｅｎ、ｓｔｒｃｈｒ、ｓｔｒｃｍｐなどを含む）で、７行のコードは、ｂｌｅｎｄｅｒプログラムの４つのユーザ関数であった。この試験例では、これらのアクセスが境界外となった最大バイト数は、Ｇｌｉｂｃ関数の６２バイトで、ｂｌｅｎｄｅｒ関数ではわずか４バイトであった。

本試験例で検出されたこれらのバグはいずれも、メモリからＳＩＭＤレジスタにデータをロードするＳＩＭＤ命令が原因であることが確認された。図１１は、本明細書に記載の１つ以上の実施形態に係る、境界外の原因となったＳＰＥＣ－ＣＰＵ２０１７アプリケーションにおける命令を例示するグラフ１１００である。図１１に示すように、Ｇｌｉｂｃ文字列処理関数におけるこのような命令は、ＳＩＭＤ移動（ＭＯＶＤＱＡ、ＭＯＶＤＱＵ、ＭＯＶＨＰＤ、ＭＯＶＬＰＤ）、比較（ＰＣＭＰＥＱＢ）、または最小化（ＰＭＩＮＵＰ）の命令を含む。また、図１１に示すように、ｂｌｅｎｄｅｒにおけるこのような命令は、ＳＩＭＤ演算命令（ＭＵＳＳ、ＡＤＳＳ、ＳＵＢＳＳ）を含む。調査により判明したところでは、ｂｌｅｎｄｅｒのバグは、Ｏ３フラグ（O3 flag）でコンパイルした場合に、コンパイラが非整列の１６バイトＳＩＭＤロード（unaligned 16-byte SIMD loads）を使用してオブジェクト境界にあるメモリにアクセスすると、部分的に境界外アクセスが発生することにより、発生したものであった。これらのバグは、ＳＩＭＤ演算を使用していないためＯ０フラグ（O0 flag）を用いることで消滅した。Ｇｌｉｂｃ関数におけるバグは、Ｕｂｕｎｔｕ１８．０４で配布された共有ライブラリ（ｌｉｂｃ．ａ）に存在し、またメモリアクセス時の境界外バイト数が最大６２バイトになるため、より深刻なものと考えられる。

境界外アクセスのコード行数が最も多い（２０行）関数であるｓｔｒｌｅｎについて調べたところでは、そのバグの半数以上（２０件中１１件）は、１６バイトのオペランド（１つはメモリから、もう１つはレジスタから）のバイト単位（byte-wise）の比較を行うためのＰＣＭＰＥＱＢ命令に起因するものであった。ｓｔｒｌｅｎ関数はこれらを用いて、入力文字列のＮＵＬＬ文字（「＼０」）の高速チェックを実行し、文字列の長さを計算する。Ｇｌｉｂｃ－ｖ２．２７のｌｉｂｃ．ａのオブジェクトダンプ（object-dump）から生成されたｓｔｒｌｅｎのアセンブリコードの例を一覧３に示す。このコードでは、１６バイトの比較を３つ（他の場所では最大４つ）同時に発行した後、テストおよびジャンプ命令を使用して、ＮＵＬＬが発生した場合に比較を停止する。この安全でないコードは、文字列オブジェクトの外側にある最大４７バイト（１６バイト比較を４回行う場合は最大６３バイト）のメモリにアクセスできる。これらのバイナリをデフォルトバージョンのＡＳＡＮでもテストしたが、これらのバグのいずれも検出することはできなかった。これは、ＡＳＡＮでは、共有ライブラリのバグを検出するために共有ライブラリの再コンパイルを必要とするためである。さらに、ＡＳＡＮのデフォルト実装（default implementation）では、本開示の境界チェックフレームワークの実施形態ではｂｌｅｎｄｅｒにおいて検出された、非整列ロード（unaligned loads）による部分的な境界外アクセスを検出しなかった。

一覧３

以下、上述した試験例を実施するための評価方法の概要を示す。また、以下ではさらに、本開示の境界チェックフレームワークの１つ以上の複数の実施形態を実装する際に発生し得る、例示的なソフトウェアおよびハードウェア変更によるオーバーヘッドについて説明する。

評価方法として、本開示の境界チェックフレームワーク（ｍａｌｌｏｃ／ｆｒｅｅフックを含む）の実施形態を実現するためのソフトウェア変更を、共有ライブラリとしてパッケージ化（packaging）した。さらに、評価方法として、ＬＬＶＭ１０で追加されたインスツルメンテーションを利用して、プログラムｍａｉｎの前に初期化関数（initialization function）を追加した。本開示の境界チェックフレームワークの実施形態を実現するためのハードウェア変更は、Ｇｅｍ５ ｖ２０．０でモデリングした。性能評価のための評価方法として、ＳＰＥＣ－ＣＰＵ２０１７で公開されている１６種類のＣ／Ｃ＋＋ベンチマークのうち、１３種類のベンチマークをｒｅｆデータセットと共に利用した（３種類のワークロードは、本評価方法では動作しなかった）。さらに、評価手法として、インスツルメンテーション後のバイナリ（instrumented binaries）をネイティブマシン（Ｉｎｔｅｌ社（カリフォルニア州サンタクララ）が提供するＸｅｏｎ ＣＰＵ Ｅ－２１７４Ｇ、３．８０ＧＨｚ）上で完了まで実行（ＩＳＡの変更をＣコードでエミュレート）し、インスツルメンテーション前のバイナリ（uninstrumented binaries）と比較することで、ソフトウェアインスツルメンテーションのオーバーヘッドを評価した。ハードウェアのオーバーヘッドについての評価方法として、インスツルメンテーション後のバイナリを使用し、Ｇｅｍ５のシステムコールエミュレーションモード（System-Call Emulation mode）において、境界チェックを行う場合と行わない場合とでバイナリを実行した。さらに、評価方法として、初期化フェーズをスキップしてキャッシュをウォームアップ（warmup）するために最初の１００億個の命令を早送りし，１０億個の命令の統計情報を追跡した。本評価方法がＧｅｍ５のために使用したハードウェア構成を表１に示す。

図１２は、本明細書に記載の１つ以上の実施形態に係る、ＢＩテーブル管理のためのソフトウェアインスツルメンテーションによる性能への影響を例示するグラフ１２００である。具体的には、グラフ１２００は、ｍａｌｌｏｃ／ｆｒｅｅ呼び出しをインターセプトしてＢＩテーブルを更新する共有ライブラリとリンクしたアプリケーションの実行時間（execution times）を示している。グラフ１２００は総じて、ｍａｌｌｏｃ／ｆｒｅｅインスツルメンテーションに関連付けられる速度低下の評価を容易にするものである。グラフ１２００に示す実行時間は、インスツルメンテーション前のバイナリの実行時間に正規化されている。グラフ１２００に示す各実行時間は、対応するプログラムをネイティブシステム上で完了まで実行し、全体の実行時間を測定することによって得られたものである。ネイティブ実行（native execution）を容易にすると共に、ＢＩテーブル管理のオーバーヘッドをモデリングするために、複数のＢＩエントリを、ポインタにインデックスビットを埋め込まずにｍａｌｌｏｃで割り当て、ｆｒｅｅでランダムにＢＩエントリを削除した。図１２に示すように、ＢＩテーブル管理のためのソフトウェアインスツルメンテーション（境界チェックなし）によって、すべてのプログラムわたって平均約０．５％の速度低下が追加される可能性がある。ｍａｌｌｏｃの頻度が高いワークロード（例えば、ｇｃｃやｐｅｒｌｂｅｎｃｈ）では、ＢＩテーブル更新のためのキャッシュアクセスが増加するため、最大１．８％～２．４％の速度低下が発生する可能性がある。ｍａｌｌｏｃがほとんど使用されないその他のワークロードでは、性能への影響は無視できる程度である。

図１３は、本明細書に記載の１つ以上の実施形態に係る、ハードウェアベースの境界チェックによる性能への影響を例示するグラフ１３００である。具体的には、グラフ１３００は、境界チェックと共に実行されるインスツルメンテーション後のバイナリの命令１０億個あたりの実行時間を、境界チェックを実行しない対応するバイナリの実行時間にそれぞれ正規化して示したものである。グラフ１３００は総じて、インスツルメンテーション後のバイナリを用いたＧｅｍ５におけるハードウェアベースの境界チェックに関連付けられる速度低下の評価を容易にするものである。図１３に示すように、ハードウェアベースの境界チェックによって、平均約１％の速度低下が追加される可能性がある。これらのオーバーヘッドの主な要因は、ＢＩキャッシュミスに伴い境界チェックで発生するメモリアクセスである。ｍａｌｌｏｃの頻度が高いワークロード（例えば、ｘａｌａｎｃｂｍｋ、ｇｃｃ、ｐａｒｅｓｔ）では、バッファが小さくなるため、同じインデックスを共有するバッファアクセスが少なくなる傾向がある。これにより、境界メタデータの作業セット（working-sets）が大きくなる可能性があり、そのため、ＢＩキャッシュミス率が高くなったり（例えば、２％～１６％）、速度低下が大きくなったり（例えば、１％～６％）する可能性がある。ＢＩキャッシュヒット率が９９％超のその他のワークロードでは、速度低下は無視できる程度である。

図１４および１５は、ＢＩキャッシュミスが発生したロードに関するシナリオの内訳の例を示す図である。具体的には、図１４は、本明細書に記載の１つ以上の実施形態に係る、ＢＩキャッシュミスを含む命令１０００個あたりのロードを例示するグラフ１４００である。図１５は、本明細書に記載の１つ以上の実施形態に係る、ＢＩキャッシュミスを含むロードの割合を例示するグラフ１５００である。境界チェックがＢＩキャッシュヒットの場合、速度低下が発生することはないため、ｘａｌａｎｃｂｍｋ、ｇｃｃ、ｐａｒｅｓｔなどのワークロードにおける速度低下を理解すべく、これらのワークロードでＢＩキャッシュミスが発生するシナリオを評価した。評価の結果、総じてＢＩキャッシュミスの９８％超がロード操作時の境界チェックで発生し、ストア時のミスはわずか２％であることが分かった。

グラフ１４００および１５００は、ロード処理が行われた場所に基づく、ロード操作時のＢＩキャッシュミスの内訳を示している（それぞれ、絶対数と割合で示す）。グラフ１４００および１５００に示すように、ｘａｌａｎｃｂｍｋワークロードが最もＢＩキャッシュミスが多く（ミス率が最も高い）、その結果、速度低下が最も大きい。一方、ｇｃｃワークロードはｐａｒｅｓｔワークロードよりもミス率は高いが、ｇｃｃワークロードの方が速度低下は小さい。概して、ｇｃｃワークロードの速度低下が小さいのは、ロードがＬ１－ヒットである場合（これは、Ｌ１－ミスとなったロード時のＢＩキャッシュミスよりも性能への影響が大きい）のＢＩキャッシュミスの割合が非常に小さいためである。このように、Ｌ１－キャッシュヒット時のＢＩキャッシュアクセスに局所性（locality）がないことが、ｘａｌａｎｃｂｍｋおよびｐａｒｅｓｔのワークロードの速度低下の主な要因となり得る。ただしこれは、ＢＩエントリ割り当てアルゴリズムを、特にこれらのベンチマークで一般的なサブキャッシュラインオブジェクト（sub-cacheline objects）に対して局所鋭敏な（locality-sensitive）ものにすることで対処可能であり、それによりこれらのワークロードのオーバーヘッドを低減することができる。

図１６および１７は、ＢＩキャッシュサイズごとの、境界チェックに伴う速度低下の例を示す図である。具体的には、図１６は、本明細書に記載の１つ以上の実施形態に係る、異なるＢＩキャッシュサイズごとの、境界チェックに伴う平均速度低下を例示するグラフ１６００である。図１７は、本明細書に記載の１つ以上の実施形態に係る、異なるＢＩキャッシュサイズごとの、ＢＩキャッシュミス率を例示するグラフ１７００である。上述した境界チェックのオーバーヘッドの評価例では、８ＫＢのデフォルトＢＩキャッシュサイズを利用したが、グラフ１６００および１７００は、その他のＢＩキャッシュサイズにおける評価を示している。具体的には、グラフ１６００および１７００は、ＢＩキャッシュのサイズを１ＫＢから６４ＫＢまで変化させたときの、境界チェックに伴う速度低下と、ＢＩキャッシュミス率とを示している。グラフ１６００および１７００に示すように、ＢＩキャッシュのサイズが大きくなるにつれて、速度低下が７％（１ＫＢ）、３％（４ＫＢ）、１％（８ＫＢ）と減少していく。ただし、ＢＩキャッシュのサイズをさらに大きくした場合の速度低下の減少度合いは、わずかである可能性がある。これは、８ＫＢを超えると、ほとんどのワークロードのミス率が１％未満となる可能性があり、平均ＢＩキャッシュミス率が総じてさほど減少しないためである。

図１８および１９は、本開示の境界チェックフレームワークの実施形態の実装に伴うメモリオーバーヘッドの例を示す図である。具体的には、図１８は、本明細書に記載の１つ以上の実施形態に係る、境界チェックに関連するメモリ帯域幅のオーバーヘッドを例示するグラフ１８００である。図１９は、本明細書に記載の１つ以上の実施形態に係る、ＢＩテーブルに関連するメモリオーバーヘッドを例示するグラフ１９００である。グラフ１８００に示すように、境界チェックによって、アプリケーションによるメモリ帯域幅消費が平均約２９％増加する可能性がある。ただし、このアプリケーションによるメモリ帯域幅消費は、ＢＩキャッシュの設計に応じて変化し得る。例えば、ＢＩエントリを共有の最終レベルキャッシュ（shared last-level cache）に追加でキャッシュすることにより、必要な帯域幅を減らすことができる。幸い、ＤＤＲ４ ＤＲＡＭであれば、速度低下を生じることなく、追加の帯域幅要件を満たすことができる。メモリの消費については、ＢＩテーブルが１エントリあたり１６バイトの１６００万エントリで構成されている場合、ＢＩテーブルは最大で２５６ＭＢを消費する可能性がある。この構成では、ＢＩテーブルは平均３９％のメモリを追加で消費する可能性がある。一の実施形態において、８００万の１２バイトエントリ（４８ビットのベースと境界を格納）で構成された、メモリ最適化された（memory optimized）ＢＩテーブル設計（例えば、ＢＩテーブル－ＭｅｍＯｐｔ）の場合、追加のメモリ消費は約１７％とすることができる。これらのオーバーヘッドは、ＢＩテーブルが必要とするメモリが、プログラムメモリの使用量ではなくｍａｌｌｏｃの数に応じて増大するため、図１を参照して上述した境界チェック型手法うち分離境界グループ１３０のようなシャドウメモリを使用した手法に比べて、はるかに小さくすることができる。

以下、空間的・時間的安全性を確保するための他のハードウェアベースの手法について説明し、本開示のハードウェアベースの境界チェックフレームワークと比較する。他の境界チェック手法に対する本開示の境界チェックフレームワークの１つの特徴的な要素として、本開示の境界チェックフレームワークによれば、非常に低コストでありながら、境界情報の伝達およびルックアップが容易に行える。

図１を参照して上述したように、分離境界グループ１３０における１つの手法は、シャドウメモリから境界メタデータにアクセスすることによって境界チェックを行うが、この場合、空間的安全性しか確保されない。分離境界グループ１３０における他の手法では、この設計を拡張して、取り消し（revoke）可能な一意の識別子（これもシャドウメモリに格納されている）とポインタを関連付けることにより、適度なコスト（例えば、平均２４％の速度低下）で時間的安全性を確保する。境界チェック時のこのようなシャドウメモリへのアクセスは、単一のオブジェクトの異なるワードに対してロード／ストアを行うためにシャドウメモリにおける異なる場所へのアクセスが行われるため、時間的な局所性（temporal locality）が限られる。本開示の境界チェックフレームワークの１つ以上の実施形態においては、ポインタ内のインデックスビットを使用してＢＩテーブルにアクセスすることができ、これにより容易に、単一のオブジェクトに対するすべてのロード／ストアが同一のＢＩテーブルエントリを使用することを確実にすることができる。これにより、９８％超のＢＩキャッシュヒット率を実現可能な低コストの境界チェック（例えば、１％の速度低下）を実行することが容易になる。

分離境界グループ１３０の他の手法では、空間的および時間的安全性を確保する。すなわち、能力ＩＤ（Capability-ID）を用いてインデックスされた別個の能力テーブル（capability-table）に格納された能力とポインタを関連付け、境界チェックの境界を取得する。しかし、メモリにスピルしたポインタ（pointers spilled to memory）の場合、５レベルのＰｏｉｎｔｅｒ－Ａｌｉａｓ Ｔａｂｌｅに対して２回目の高コストなルックアップを必要とするため、ポインタ値から能力ＩＤを導出することは高コストになる可能性がある。この手法では、能力ＩＤを低コストで派生ポインタ（derived pointers）に伝達し、能力および識別子をキャッシュするために、ハードウェアにおける投機的ポインタ追跡メカニズム（speculative pointer-tracking mechanism）を提案し、平均的速度低下を１５％に抑えているが、高コストのテーブルルックアップにより、最悪の場合４０％もの速度低下を招く可能性がある。さらに、ポインタ演算を介して能力ＩＤを転送するには、投機的なポインタ追跡メカニズムが必要となる。これに対して、本開示の境界チェックフレームワークの実施形態は、ポインタの未使用ビット内に埋め込まれたインデックスを用いてルックアップ可能なＢＩテーブルを利用するため、追加のコストを必要とすることなく、派生ポインタに自動的にＢＩテーブルを転送することができ、最悪の場合でも速度低下を約７％に抑えることができる。

分離境界グループ１３０のその他の手法によって、空間的・時間的安全性が確保できる場合もあるが、これらの手法における境界チェックは追加の明示的な命令（extra explicit instructions）を必要とし、また境界テーブルが２レベルのトライ（two-level trie）として構成されているため高コストなテーブルルックアップを伴うことから、大きなオーバーヘッド（例えば、平均５０％～６０％）が生じる。これに対して、本開示の境界チェックフレームワークの実施形態では、時間的な局所性が高く、ロード／ストア実行時にハードウェアに透過的に挿入可能なテーブルルックアップを最大１回行うだけでよい境界チェックを実装することができる。

隣接境界グループ１１０の手法は、メモリの安全性を確保することはできるが、バイナリレイアウトを変更しなければならず、それにより既存のライブラリコードとの互換性に影響が生じる。インライン境界グループ１２０の手法は、未使用のポインタビットを境界メタデータ用に転用することによって互換性の問題を回避できるが、時間的な安全性を確保することができない。本開示された境界チェックフレームワークの実施形態によれば、レガシー共有ライブラリ（legacy shared-libraries）との互換性を維持すると共に、既存の共有ライブラリに渡されるポインタに関するメモリ安全性（時間的安全性および空間的安全性の両方）を確保することもでき、さらに、速度低下を無視できる程度にとどめることもできる。

トリップワイヤを用いた確率的手法では、オブジェクトまたはサブオブジェクトの粒度（granularity）でマジックバリュー（magic-values）（すなわち、トリップワイヤ）を挿入し、ハードウェアでこれらのマジックバリューをチェックすることで、トリップワイヤを作動させる境界外アクセスを検出することにより、低コストのメモリエラー検出を実現することができる（例えば、２％～１８％の速度低下）。しかし、このような手法では、トリップワイヤを超えてメモリにアクセスするような、より大きな境界外アクセスを検出することができない。本開示の境界チェックフレームワークの実施形態によれば、同等またはそれ以上の性能で、すべての境界外アクセスを正確に検出することが可能となる。

メモリタギングを用いた確率的手法は、オブジェクトとポインタのペアにタグまたは「色」を割り当て、これらのタグを両者別々に保持し、ポインタ逆参照時にポインタとアクセスされたメモリのタグが一致するかどうかをチェックする。この手法では速度低下を無視できる程度（例えば、５％より小さい速度低下）にできるが、異なるオブジェクトに再使用される４ビットのタグ（ポインタの上位ビットに格納される）を使用するため、エラーを確率的にしか検出できず、検出漏れ（false-negatives）につながる。本開示の境界チェックフレームワークの実施形態においてもポインタビットを転用できるが、上記とは対照的に、実際の境界情報へのインデックスを格納するために当該ポインタビットを使用する。したがって、本開示の境界チェックフレームワークの実施形態によれば、同等の速度低下で、オブジェクト境界の正確な実施（高いカバー率）を実現することができる。

図２０Ａ乃至２０Ｇは、本明細書に記載の１つ以上の実施形態に係る、メモリ内のＢＩテーブルを初期化するための動作フロー２０００を例示する図である。図２０Ａに示すように、動作フロー２０００は、アプリケーションまたはユーザプログラムがランタイムに入る状態２００２を含む。状態２００２から、動作フロー２０００は図２０Ｂに示す状態２００４に移行する。状態２００４において、アプリケーションは、２つの引数を含むＢＩテーブル初期化呼び出し（initialization call）を生成する。ＢＩテーブル初期化呼び出しの第１の引数は、マスク値（例えば、０ｘｆｆ００）を含む。このマスク値は、ポインタ内のどの未使用ビットを、ＢＩテーブル内の対応するＢＩエントリのインデックス情報の格納に使用するかを定義するものである。ＢＩテーブル初期化呼び出しの第２の引数は、サイズ値（例えば、１２８）を含む。このサイズ値は、初期化時にＢＩテーブルに割り当てられるＢＩエントリの数を定義するものである。状態２００４から、動作フロー２０００は図２０Ｃに示す状態２００６に移行する。

状態２００６において、アプリケーションは、境界チェックライブラリ（ＢＣ＿Ｌｉｂｒａｒｙ）に対してＢＩテーブル初期化呼び出しを発行する。状態２００６から、動作フロー２０００は図２０Ｄに示す状態２００８に移行する。状態２００８において、ＢＣ＿Ｌｉｂｒａｒｙの作成ルーチン（creation routine）が、ＢＩテーブル初期化呼び出しに含まれるサイズ値に基づいて、メモリの領域をＢＩテーブルに割り当てることにより、メモリ内にＢＩテーブルを作成する。状態２００８から、動作フロー２０００は図２０Ｅに示す状態２０１０に移行する。状態２０１０において、ＢＣ＿Ｌｉｂｒａｒｙの初期化ルーチン（initialization routine）が、ＢＩテーブルの各ＢＩエントリに初期値を入力（populate）することによって、ＢＩテーブルを初期化する。状態２０１０から、動作フロー２０００は図２０Ｆに示す状態２０１２に移行する。

状態２０１２において、ＢＣ＿Ｌｉｂｒａｒｙの専用レジスタルーチン（special register routine）が、複数の専用ハードウェアレジスタに、ＢＩテーブルに対応する値を入力する。図２０Ｆに示すように、複数の専用ハードウェアレジスタは、境界テーブルレジスタ（ＢＴＲ）、境界マスクレジスタ（ＢＭＲ）、および境界テーブルサイズレジスタ（ＢＴＳＲ）を含む。ＢＴＲは、メモリ内の割り当て領域に存在するＢＩテーブルのベースアドレスを格納する。ＢＭＲは、状態２００６にてアプリケーションがＢＣ＿Ｌｉｂｒａｒｙに発行したＢＩテーブル初期化呼び出しからマスク値を格納する。ＢＴＳＲは、状態２００６にてアプリケーションがＢＣ＿Ｌｉｂｒａｒｙに発行したＢＩテーブル初期化呼び出しからサイズ値を格納する。このサイズ値は、ＢＩテーブルを構成するＢＩエントリの数を定義するものである。状態２０１２から、動作フロー２０００は図２０Ｇに示す状態２０１４に移行する。状態２０１４において、ＢＣ＿Ｌｉｂｒａｒｙのハンドラルーチン（handler routine）が、ＢＩテーブル上での操作に使用可能なｂｔ＿ｈａｎｄｌｅｒを設定する。一の実施形態において、ｂｔ＿ｈａｎｄｌｅｒは、グローバル変数（global variable）である。一の実施形態において、ｂｔ＿ｈａｎｄｌｅｒは、ＢＩテーブルのベースアドレス、ＢＩテーブル初期化呼び出しのサイズ値、ＢＩテーブル初期化呼び出しのマスク値、またはこれらの組み合わせに関連するデータを格納する複数のフィールドで構成される。

図２１Ａ乃至２１Ｅは、本明細書に記載の１つ以上の実施形態に係る、メモリ割り当て機能を処理するための動作フロー２１００を例示する図である。図２１Ａに示すように、動作フロー２１００は、アプリケーションが、メモリ領域の割り当てを要求するためのメモリ割り当て呼び出し（memory allocation call）を生成する状態２１０２を含む。メモリ割り当て呼び出しは、要求したメモリ領域割り当てのサイズを定義する長さ値（length value）を含む引数を含む。状態２１０２から、動作フロー２１００は図２１Ｂに示す状態２１０４に移行する。状態２１０４において、アプリケーションは、ヒープライブラリ（Ｈｅａｐ＿Ｌｉｂｒａｒｙ）のメモリ割り当て関数に対して、メモリ割り当て呼び出しを発行する。図２１Ｂに示すように、メモリ割り当て関数は、ＢＩテーブルにエントリを作成するための２つの引数を含むＢＩエントリ作成呼び出し（BIEntry creation call）を生成する（ｐ＝ｃｒｅａｔｅＢＩ（ｐ，ｌｅｎ））。さらに、メモリ割り当て関数は、元のメモリ割り当て呼び出し（original memory allocation call）を処理し、要求されたメモリ領域を割り当てる（ｐ＝ｏｒｉｇｉｎ＿ｍａｌｌｏｃ（ｌｅｎ））。ＢＩエントリ作成の２つの引数は、新たに割り当てられたメモリ領域のベースアドレスを定義するポインタ値を含む第１の引数と、割り当てられたメモリ領域のサイズを定義する長さ値を含む第２の引数とを含む。状態２１０４から、動作フロー２１００は図２１Ｃに示す状態２１０６に移行する。

状態２１０６において、ＨＥＡＰ＿Ｌｉｂｒａｒｙのメモリ割り当て関数が、ＢＣ＿ＬｉｂｒａｒｙのＢＩエントリ作成関数に対して、ＢＩエントリ作成呼び出しを発行する。状態２１０６から、動作フロー２１００は図２１Ｄに示す状態２１０８に移行する。状態２１０８において、ＢＩエントリ作成関数は、割り当てられたメモリ領域に関連付けられた境界メタデータを格納するために、ＢＩテーブル内の空きＢＩエントリ（free BIEntry）を検索する。状態２１０８から、動作フロー２１００は図２１Ｅに示す状態２１１０に移行する。状態２１１０において、ＢＩエントリ作成関数は、空きＢＩエントリに対して、割り当てられたメモリ領域のベースアドレスを定義するポインタ値と、割り当てられたメモリ領域のサイズを定義する長さ値とを入力する。ＢＩエントリ作成関数はさらに、空きＢＩエントリのインデックス値（ｉｄｘ）をポインタ値に埋め込み、メモリ割り当て関数に返される新たなポインタ値を作成する。

図２２Ａ乃至２２Ｋは、本明細書に記載の１つ以上の実施形態に係る、ロード命令を処理するための動作フロー２２００を例示する図である。図２２Ａに示すように、動作フロー２２００は、アプリケーションがアドレスＲａからロード命令を実行可能な状態２２０２を含む。状態２２０２から、動作フロー２２００は図２２Ｂに示す状態２２０４に移行する。状態２２０４において、境界保護ユニット（ＢＰＵ：bound protection unit）は、ＲａレジスタおよびＢＭＲからアドレス値およびマスク値を抽出することができる。状態２２０４から、動作フロー２２００は図２２Ｃに示す状態２２０６に移行する。状態２２０６において、ＢＰＵは、ロード命令に関連付けられたヒープオブジェクトのメモリアドレスを抽出すると共に、アドレスおよびマスク値からインデックス値を抽出することができる。状態２２０６から、動作フロー２２００は図２２Ｄに示す状態２２０８に移行する。状態２２０８において、Ｒａから導出されたメモリアドレスとマスク値とがロード命令によって利用され、ヒープオブジェクトからバイトをロードすることができる。状態２２０８から、動作フロー２２００は図２２Ｅに示す状態２２１０に移行する。

状態２２１０において、ＢＰＵは、アプリケーションに関連付けられたＢＩテーブルのベースアドレスを含むＢＴＲと、ＲａおよびＢＭＲから導出されたインデックスとを用いて、アドレスＲａに対応するＢＩエントリのアドレスを決定することができる。状態２２１０から、動作フロー２２００は図２２Ｆに示す状態２２１２に遷移する。状態２２１２において、ＢＰＵは、状態２２１０にて決定されたＢＩエントリのアドレスを用いて、ロード命令に対する適切なＢＩエントリを取得する。状態２２１２から、動作フロー２２００は図２２Ｇに示す状態２２１４に移行する。状態２２１４において、ＢＰＵは、インデックス値を、ＢＴＳＲから取得したＢＩテーブルのサイズ値と比較して、インデックス値が有効であるか否かを評価することができる。状態２２１４から、動作フロー２２００は図２２Ｈに示す状態２２１６に移行する。

状態２２１６において、状態２２１４での評価によってインデックス値が無効であると判定された場合、ＢＰＵは例外値（exception value）を生成し、境界ステータスレジスタ（ＢＳＲ：bounds status register）に格納することができる。あるいは、状態２２１４での評価によってインデックス値が有効であると判定された場合、ＢＰＵは、ＢＩエントリアドレスを含むＢＩロード命令（BI load instruction）を境界キャッシュに発行することができる。状態２２１６から、動作フロー２２００は図２２Ｉに示す状態２２１８に移行する。状態２２１８において、境界キャッシュが境界メタデータを含んでいる場合、ＢＰＵはＢＩロード命令に応答して、境界キャッシュからヒープオブジェクトに対応する当該境界メタデータを取得することができる。あるいは、境界キャッシュが境界メタデータを含んでいない場合、ＢＰＵは、ＢＩロード命令に応答して、メモリ内のＢＩテーブルからヒープオブジェクトに対応する当該境界メタデータを取得することができる。状態２２１８から、動作フロー２２００は図２２Ｊに示す状態２２２０に移行する。

状態２２２０において、ＢＰＵは、境界メタデータと状態２２０６で抽出されたヒープオブジェクトのメモリアドレスとを比較して、ロード対象のメモリアドレスが有効であるか否かを評価することができる。状態２２２０から、動作フロー２２００は図２２Ｋに示す状態２２２２に移行する。状態２２２２において、状態２２２０での評価によってメモリアドレスが無効であると判定された場合、ＢＰＵは例外値を生成し、ＢＳＲに格納することができる。あるいは、状態２２２０での評価によってヒープオブジェクトのメモリアドレスが有効であると判定された場合、ＢＰＵは、アプリケーションによって実行されるロード命令を続行させることができる。

図２３は、本明細書に記載の１つ以上の実施形態に係る、ポインタ２３００を例示する図である。一部の場合において、配列のインデックス作成やポインタ演算の結果、ＢＩテーブルへのインデックスとして使用されるポインタの未使用ビット（またはインデックスビット）に演算が「オーバーフロー」して、未使用ビットを「破損」（corrupt）する可能性がある。かかる場合に境界外参照（out-of-bounds reference）が検出されないためには、破損したインデックス値が、ＢＩテーブル内の有効なＢＩエントリを参照している必要があると共に、ポインタのポインタ値ビット（またはアドレスビット）が当該ＢＩエントリの境界内の有効なアドレスに対応している必要がある。このような事態が発生する可能性は低いが、ポインタを変更して、このような事態が発生する可能性を低減したり、回避したりすることができる。そのために、ポインタ２３００は、インデックスビット２３２０（例えば、ビット４２～６３）とアドレスビット２３３０（例えば、ビット０～３９）との間の保護帯域（guard band）を促進する保護ビット（guard bits）２３１０（例えば、ビット４１および４０）を含む。図２４および２５を参照して以下で詳述するように、保護ビット２３１０は、「適度な大きさの（moderately sized）」オフセットがアドレスに加算されたりアドレスから減算されたりする場合に、インデックスビット２３２０を保護することができる。

図２４は、本明細書に記載の１つ以上の実施形態に係る、ポインタ２４００を例示する図である。図２４に示すように、ポインタ２４００は、インデックスビット２４２０と、アドレスビット２４３０と、インデックスビット２４２０とアドレスビット２４３０との間に介在する保護ビット２４４０と、を含む。図２４において、保護ビットは、左から右に「１０」の２進値で構成される。ポインタ２４００に適度な大きさのオフセット（例えば、＜２^４０）を加算すると、保護ビット２４４０の下位ビット（例えば、ビット４０）が「０」の２進値から「１」の２進値に反転するキャリー（carry）が発生する可能性があるが、それがインデックスビット２４２０にオーバーフローして、インデックスビット２４２０を破損することはないと考えられる。さらに、ポインタ２４００から適度な大きさのオフセットを減算すると、保護ビット２４４０のビット４１が「１」の２進値から「０」の２進値に反転するボロー（borrow）が発生する可能性があるが、それがインデックスビット２４２０にオーバーフローして、インデックスビット２４２０を破損することはないと考えられる。

例えば、図２５に示すように、負の「１」の２進値をポインタ値２４００に加算することができる（または、「１」の２進値をポインタ値２４００から減算することができる）。保護ビット２４４０の上位ビット（例えば、ビット４１）に負の「１」の２進値を加算することで、負の１の６４ビット表現において、ビット４１の左側の「１」の２進値を実質的にゼロにするキャリーを発生させることができる。したがって、ビット４１の左側のビットは合計で、図２４のポインタ２４００によって表される元のアドレスにおけるこれらのビットに等しくなる。図２３乃至２５を参照して上述したインデックスビットの破損緩和（corruption mitigation）手法によって、１テラバイト（ＴＢ）超のアドレス空間を使用し、４００万超の配列に対して境界情報を追跡するアプリケーションまたはユーザプログラムの実行が容易になる。当該手法はこれを実現しながら、境界外の配列参照を防止すると共に、適度な大きさのオフセット（例えば、＜２^４０）に伴うポインタ演算における「インデックス破損」を防止または軽減することができる。

図２６は、本明細書に記載の１つ以上の実施形態に係る、ヒープオブジェクトに関するハードウェアベースのメモリエラー軽減を容易にするコンピュータ実装方法２６００を例示するフローチャートである。説明を簡潔にするために、本明細書の他の実施形態における要素と同様の要素については説明を省略する。

ステップ２６０２にて、コンピュータ実装方法２６００は、オブジェクトがメモリに割り当てられた際に、プロセッサ（例えば、エントリコンポーネント２４０を含む）を用いて、境界情報を格納するためのテーブルにエントリを割り当てることを含むことができる。ステップ２６０４にて、コンピュータ実装方法２６００は、プロセッサ（例えば、転用コンポーネント２５０を含む）を用いて、オブジェクトアドレスの未使用ビットを転用して、テーブルのエントリへのインデックスを格納することを含むことができる。

一の実施形態において、コンピュータ実装方法２６００はさらに、プロセッサ（例えば、チェックコンポーネント２６０を含む）を用いて、アドレス内のインデックスビットを使用して境界情報にアクセスすることによって、ロード命令およびストア命令に対してハードウェアで境界チェックを実行することを含むことができる。一の実施形態において、コンピュータ実装方法２６００はさらに、プロセッサ（例えば、伝達コンポーネント２７０を含む）を用いて、後続のオブジェクトアドレスが割り当てステートメントまたはポインタ演算を介して導出される際に、インデックスを自動的に伝達することを含むことができる。一の実施形態において、コンピュータ実装方法２６００はさらに、プロセッサを用いて、配列の境界をチェックすることを含むことができる。一の実施形態において、コンピュータ実装方法２６００はさらに、プロセッサを用いて、配列参照が境界内であるか境界外であるかを判定することを含むことができる。一の実施形態において、コンピュータ実装方法２６００はさらに、プロセッサを用いて、境界外の配列参照の発生を軽減することを含むことができる。

一の実施形態において、コンピュータ実装方法２６００はさらに、プロセッサを用いて、オブジェクトアドレス内の未使用ビットを使用して、アクセス可能なメモリアドレスの範囲をチェックすることをさらに含むことができる。一の実施形態において、コンピュータ実装方法２６００はさらに、プロセッサを用いて、オブジェクトアドレスが割り当てステートメントにコピーされる際に、未使用ビットで追加の情報を伝達することをさらに含むことができる。一の実施形態において、コンピュータ実装方法２６００はさらに、プロセッサを用いて、オブジェクトアドレスが関数呼び出しの引数として渡される際に、未使用ビットで追加の情報を伝達することをさらに含むことができる。一の実施形態において、コンピュータ実装方法２６００はさらに、プロセッサを用いて、オブジェクトアドレスがアドレスの計算に使用される際に、未使用ビットで追加の情報を伝達することをさらに含むことができる。

上記では、ヒープオブジェクトを誤ったメモリ参照から保護することを主に説明したが、本明細書に記載のメカニズムは、グローバルオブジェクトやスタック上に割り当てられたオブジェクトなど、他の種類のオブジェクトにも適用可能である。グローバルオブジェクトは、プログラム起動時にプログラム内の各グローバルオブジェクトについて、ＢＩエントリをＢＩテーブルに割り当てることで保護することができる。スタックオブジェクトも保護することができる。スタックオブジェクトを保護する１つの方法として、プログラムを構成するソース言語ファイル（例えば、ＣファイルやＣ＋＋ファイル）を前処理する前処理ステップを追加する方法がある。ソース言語ファイルの前処理として、ファイル内の各関数について、当該関数が直接的または間接的に自身を再帰的に呼び出すことができるか否かを判定する静的解析を行うことができる。関数が自身を再帰的に呼び出すことができない場合、前処理として、当該関数を編集して、関数内の自動オブジェクト（automatic objects）の宣言（declarations）を静的オブジェクトに変換（translate）することができる。そして、プログラム起動時に、これらの静的オブジェクトについてのＢＩエントリを、上述したグローバルオブジェクトについてのＢＩエントリの割り当てと同様に割り当てることができる。再帰的に呼び出すことができる関数内のオブジェクトは、別の方法で処理することができる。この場合、別の処理ステップにおいて、関数のプロローグとエピローグを編集して、当該関数内の各オブジェクトに対してＢＩエントリの割り当ておよび解放を行うためのコードを含めることができる。あるいは、すべての再帰的関数および非再帰的関数を同様に処理し、各関数のプロローグとエピローグを編集して、適切なＢＩエントリの割り当ておよび解放を行うためのコードを含めることができる。

また、ポインタの定義時にＮＵＬＬ値（すなわち０）を割り当てることにより、初期化されていないポインタ（uninitialized pointers）の使用を防ぐことも可能である。これにより、初期化されていないポインタの「ガベージ（garbage）」を使ってメモリの読み出しや書き込みが行われてしまう逆参照バグ（de-referencing bugs）からプログラムを保護することができる。

なお、上述した保護メカニズムを含めても含めなくても、プログラムの構築は可能である。例えば、適切な「ｍａｋｅ」フラグを使用することで、性能の低下を生じることなく、必要に応じて保護メカニズムを含まないプログラムを構築することができる。

本開示の主題の種々の態様を理解するための背景情報として、図２７および以下の説明において、本開示の主題の種々の態様を実現可能な好適な環境を概説する。図２７は、本開示の種々の態様を実現するための好適な動作環境２７００を示す図である。動作環境２７００は、コンピュータ２７１２を含むことができる。また、コンピュータ２７１２は、処理ユニット２７１４、システムメモリ２７１６、およびシステムバス２７１８を含むことができる。システムバス２７１８は、システムメモリ２７１６を含むシステムコンポーネントを処理ユニット２７１４に接続する。処理ユニット２７１４は、種々の入手可能なプロセッサのうちの任意のものとすることができる。デュアルマイクロプロセッサおよび他のマルチプロセッサアーキテクチャを処理ユニット２７１４として採用してもよい。システムバス２７１８は、複数種類のバス構造のうち任意のものとすることができる。これらのバス構造は、インダストリスタンダードアーキテクチャ（ＩＳＡ）、マイクロチャネルアーキテクチャ（ＭＳＡ）、拡張ＩＳＡ（ＥＩＳＡ）、インテリジェントドライブエレクトロニクス（ＩＤＥ）、ＶＥＳＡローカルバス（ＶＬＢ）、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）、カードバス、ユニバーサルシリアルバス（ＵＳＢ）、アドバンストグラフィックスポート（ＡＧＰ）、Ｆｉｒｅｗｉｒｅ（ＩＥＥＥ１３９４）、および小型コンピュータシステムインタフェース（ＳＣＳＩ）を含む種々の利用可能なバスアーキテクチャのうち、任意のものを使用したメモリバスもしくはメモリコントローラ、周辺バスもしくは外部バス、もしくはローカルバスまたはこれらの組み合わせを含む。また、システムメモリ２７１６は、揮発性メモリ２７２０および不揮発性メモリ２７２２を含むことができる。起動時などにコンピュータ２７１２内の要素間で情報を転送するための基本ルーチンを含む基本入出力システム（ＢＩＯＳ）は、不揮発性メモリ２７２２に記憶される。一例として、不揮発性メモリ２７２２は、ＲＯＭ、プログラマブルＲＯＭ（ＰＲＯＭ）、電気的プログラマブルＲＯＭ（ＥＰＲＯＭ）、電気的消去可能プログラマブルＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリ、または不揮発性ＲＡＭ（たとえば、強誘電体ＲＡＭ（ＦｅＲＡＭ））を含むことができる。また、揮発性メモリ２７２０は、外部キャッシュメモリとして機能するＲＡＭを含むことができる。一例として、ＲＡＭは、スタティックＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、ダブルデータレートＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ）、エンハンストＳＤＲＡＭ（ＥＳＤＲＡＭ）、シンクリンクＤＲＡＭ（ＳＬＤＲＡＭ）、ダイレクトラムバスＲＡＭ（ＤＲＲＡＭ）、ダイレクトラムバスダイナミックＲＡＭ（ＤＲＤＲＡＭ）、およびラムバスダイナミックＲＡＭなどの多くの形態で利用可能である。

コンピュータ２７１２はさらに、取り外し可能／取り外し不能かつ揮発性／不揮発性コンピュータ記憶媒体を含むことができる。例えば、図２７にはディスクストレージ２７２４が示されている。また、ディスクストレージ２７２４は例えば、磁気ディスクドライブ、フロッピーディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ－１００ドライブ、フラッシュメモリカード、またはメモリスティックなどのデバイスを含むことができる。また、ディスクストレージ２７２４は例えば、光ディスクドライブを含む他の記憶媒体と独立して、またはそれと組み合わせて用いられる記憶媒体を含むことができる。光ディスクドライブは、例えばＣＤ－ＲＯＭ装置、ＣＤ－Ｒドライブ、ＣＤ－ＲＷドライブ、またはＤＶＤ－ＲＯＭドライブである。ディスクストレージ２７２４とシステムバス２７１８との接続を容易にするために、インタフェース２７２６のような取り外し可能または取り外し不能インタフェースが通常用いられる。また図２７には、ユーザと、好適な動作環境２７００における基本的なコンピュータリソースとの間の仲介として機能するソフトウェアが図示されている。かかるソフトウェアは、たとえば、オペレーティングシステム２７２８を含むことができる。オペレーティングシステム２７２８は、ディスクストレージ２７２４に記憶することができ、コンピュータ２７１２のリソースの制御と割り当てを行う。システムアプリケーション２７３０は、プログラムモジュール２７３２およびプログラムデータ２７３４（これらは例えば、システムメモリ２７１６またはディスクストレージ２７２４に記憶される）を介して、オペレーティングシステム２７２８によるリソース管理を利用する。なお、本開示は、種々のオペレーティングシステムまたはオペレーティングシステムの組み合わせによって実現可能である。ユーザは、入力装置２７３６を介してコンピュータ２７１２にコマンドまたは情報を入力する。入力装置２７３６の一例としては、マウスなどのポインティングデバイス、トラックボール、スタイラス、タッチパッド、キーボード、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナ、ＴＶチューナカード、デジタルカメラ、デジタルビデオカメラ、ウェブカメラなどが挙げられる。これらおよび他の入力装置は、インタフェースポート２７３８を介してシステムバス２７１８によって処理ユニット２７１４に接続される。インタフェースポート２７３８の例としては、シリアルポート、パラレルポート、ゲームポート、ＵＳＢなどが挙げられる。出力装置２７４０は、入力装置２７３６と同じ種類のポートのうちのいくつかを使用する。したがって、例えばＵＳＢポートを使用して、コンピュータ２７１２に入力を行ったり、コンピュータ２７１２から出力装置２７４０に情報を出力したりすることができる。出力アダプタ２７４２が図示されているが、これは他の出力装置２７４０の中でも、モニタ、スピーカ、プリンタのような一部の出力装置２７４０については専用のアダプタが必要であることを示すものである。出力アダプタ２７４２は例えば、出力装置２７４０とシステムバス２７１８との間の接続手段として機能するビデオカードおよびサウンドカードを含む。なお、他の装置もしくは装置のシステムまたはその組み合わせによって、リモートコンピュータ２７４４のような、入力機能および出力機能の両方が提供される。

コンピュータ２７１２は、リモートコンピュータ２７４４などの１つ以上のリモートコンピュータへの論理接続を用いるネットワーク環境において動作することができる。リモートコンピュータ２７４４は、コンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースの機器、ピア装置やその他の一般的なネットワークノードなどとすることができ、一般的には、コンピュータ２７１２について上述した要素の多くまたはすべてを含むこともできる。図においては、簡略化のためにメモリストレージ装置２７４６のみをリモートコンピュータ２７４４と共に示している。リモートコンピュータ２７４４はネットワークインタフェース２７４８を介してコンピュータ２７１２に論理的に接続され、次いで通信接続２７５０を介して物理的に接続される。ネットワークインタフェース２７４８は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、セルラーネットワークなどの有線もしくは無線またはその両方の通信ネットワークを含む。ＬＡＮ技術は、ファイバ分散データインタフェース（ＦＤＤＩ）、銅線分散データインタフェース（ＣＤＤＩ）、イーサネット（登録商標）、トークンリングなどを含む。ＷＡＮ技術は、一例として、ポイントツーポイントリンク、回線交換網（例えば、サービス総合デジタル網（ＩＳＤＮ）とその変形）、パケット交換網、およびデジタル加入者線（ＤＳＬ）を含む。通信接続２７５０は、ネットワークインタフェース２７４８をシステムバス２７１８に接続するために使用されるハードウェア／ソフトウェアを指す。図中、通信接続２７５０は例示としてコンピュータ２７１２の内部に図示しているが、コンピュータ２７１２の外部にあってもよい。一例に過ぎないが、ネットワークインタフェース２７４８に接続するためのハードウェア／ソフトウェアは、通常の電話回線用モデム、ケーブルモデム、ＤＳＬモデムなどのモデム、ＩＳＤＮアダプタおよびイーサネットカードなどの内部技術および外部技術を含むことができる。

本発明は、任意の可能な技術詳細レベルで統合されたシステム、方法もしくはコンピュータプログラム製品またはそれらの組み合せとすることができる。コンピュータプログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を記憶したコンピュータ可読記憶媒体を含むことができる。コンピュータ可読記憶媒体は、命令実行装置によって使用される命令を保持し、記憶することができる有形の装置とすることができる。コンピュータ可読記憶媒体は、一例として、電子記憶装置、磁気記憶装置、光学記憶装置、電磁記憶装置、半導体記憶装置またはこれらの適切な組み合わせとすることができる。コンピュータ可読記憶媒体のより具体的な一例としては、ポータブルコンピュータディスケット、ハードディスク、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ（またはフラッシュメモリ）、ＳＲＡＭ、ＣＤ－ＲＯＭ、ＤＶＤ、メモリスティック、フロッピーディスク、パンチカードまたは溝内の隆起構造などに命令を記録した機械的に符号化された装置、およびこれらの適切な組み合せが挙げられる。本明細書で使用されるコンピュータ可読記憶装置は、電波もしくは他の自由に伝播する電磁波、導波管もしくは他の伝送媒体を介して伝播する電磁波（例えば、光ファイバケーブルを通過する光パルス）、またはワイヤを介して送信される電気信号のような、一過性の信号それ自体として解釈されるべきではない。

本明細書に記載のコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピュータ装置／処理装置へダウンロード可能である。あるいは、ネットワーク（例えばインターネット、ＬＡＮ、ＷＡＮもしくはワイヤレスネットワークまたはこれらの組み合わせ）を介して、外部コンピュータまたは外部記憶装置へダウンロード可能である。ネットワークは、銅製伝送ケーブル、光伝送ファイバ、ワイヤレス伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイコンピュータもしくはエッジサーバまたはこれらの組み合わせを備えることができる。各コンピュータ装置／処理装置内のネットワークアダプタカードまたはネットワークインタフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、当該コンピュータ可読プログラム命令を、各々のコンピュータ装置／処理装置におけるコンピュータ可読記憶媒体に記憶するために転送する。本発明の動作を実施するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、集積回路用構成データ、または、スモールトークやＣ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語や類似のプログラミング言語などの手続き型プログラミング言語を含む、１つ以上のプログラミング言語の任意の組み合わせで記述されたソースコードもしくはオブジェクトコードのいずれかとすることができる。コンピュータ可読プログラム命令は、スタンドアロン型ソフトウェアパッケージとして完全にユーザのコンピュータ上で、または部分的にユーザのコンピュータ上で実行可能である。あるいは、部分的にユーザのコンピュータ上でかつ部分的にリモートコンピュータ上で、または、完全にリモートコンピュータもしくはサーバ上で実行可能である。後者の場合、リモートコンピュータは、ＬＡＮやＷＡＮを含む任意の種類のネットワークを介してユーザのコンピュータに接続してもよいし、外部コンピュータに（例えば、インターネットサービスプロバイダを使用してインターネットを介して）接続してもよい。いくつかの実施形態において、例えばプログラマブル論理回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブル論理アレイ（ＰＬＡ）を含む電子回路は、本発明の態様を実行する目的で当該電子回路をカスタマイズするために、コンピュータ可読プログラム命令の状態情報を利用することによって、コンピュータ可読プログラム命令を実行することができる。

本発明の各態様は、本明細書において、本発明の実施形態に係る方法、装置（システム）、およびコンピュータプログラム製品のフローチャートもしくはブロック図またはその両方を参照して説明されている。フローチャートもしくはブロック図またはその両方における各ブロック、および、フローチャートもしくはブロック図またはその両方における複数のブロックの組み合わせは、コンピュータ可読プログラム命令によって実行可能である。上記のコンピュータ可読プログラム命令は、機械を生産するために、汎用コンピュータ、専用コンピュータ、または他のプログラマブルデータ処理装置のプロセッサに提供することができる。これにより、かかるコンピュータまたは他のプログラマブルデータ処理装置のプロセッサを介して実行されるこれらの命令が、フローチャートもしくはブロック図またはその両方における１つ以上のブロックにて特定される機能／動作を実行するための手段を創出する。上記のコンピュータ可読プログラム命令はさらに、コンピュータ、プログラマブルデータ処理装置もしくは他の装置またはこれらの組み合わせに対して特定の態様で機能するよう命令可能なコンピュータ可読記憶媒体に記憶することができる。これにより、命令が記憶された当該コンピュータ可読記憶媒体は、フローチャートもしくはブロック図またはその両方における１つ以上のブロックにて特定される機能／動作の態様を実行するための命令を含む製品を構成する。また、コンピュータ可読プログラム命令を、コンピュータ、他のプログラマブル装置、または他の装置にロードし、一連の動作を当該コンピュータ、他のプログラマブル装置、または他の装置上で実行させることにより、コンピュータ実行プロセスを生成することができる。これにより、当該コンピュータ、他のプログラマブル装置、または他の装置上で実行される命令が、フローチャートもしくはブロック図またはその両方における１つ以上のブロックにて特定される機能／動作を実行する。

本開示の図面におけるフローチャートおよびブロック図は、本発明の種々の実施形態に係るシステム、方法およびコンピュータプログラム製品の可能な実装形態のアーキテクチャ、機能性、および動作を示している。この点に関して、フローチャートまたはブロック図における各ブロックは、特定の論理機能を実行するための１つ以上の実行可能な命令を含む、命令のモジュール、セグメント、または部分を表すことができる。他の一部の実装形態において、ブロック内に示した機能は、各図に示す順序とは異なる順序で実行してもよい。例えば、連続して示される２つのブロックは、実際には、関係する機能に応じて、略同時に実行してもよいし、場合により逆順で実行してもよい。なお、ブロック図もしくはフローチャートまたはその両方における各ブロック、および、ブロック図もしくはフローチャートまたはその両方における複数のブロックの組み合わせは、特定の機能または動作を行う専用ハードウェアベースのシステムによって、または専用ハードウェアとコンピュータ命令との組み合わせによって実行可能である。

以上、１つ以上のコンピュータ上で動作するコンピュータプログラム製品のコンピュータ実行可能命令との一般的な関連の中で本主題を説明してきたが、当業者であれば理解できるように、本開示は、他のプログラムモジュールと組み合わせて実施することもできる。プログラムモジュールは一般に、特定のタスクを実行する、もしくは特定の抽象データ型を実装する、またはその両方を行うルーチン、プログラム、コンポーネント、データ構造などを含む。さらに、当業者であれば理解できるように、本発明のコンピュータ実装方法は、他のコンピュータシステム構成において実施可能である。これらのコンピュータシステム構成には、コンピュータ、携帯型コンピュータ装置（例えば、ＰＤＡや電話）、マイクロプロセッサベースのまたはプログラム可能な消費者向け電子機器または産業用電子機器の他、シングルプロセッサまたはマルチプロセッサのコンピュータシステム、ミニコンピュータ装置、メインフレームコンピュータなどが含まれる。例示した態様は、通信ネットワークを介してリンクされたリモート処理装置によってタスクが実行される分散型コンピュータ環境において実施することもできる。ただし、本開示の態様のすべてではなくとも一部は、スタンドアロンのコンピュータ上で実施することができる。分散型コンピュータ環境において、プログラムモジュールは、ローカルおよびリモート両方のメモリ記憶装置に記憶することができる。例えば、１つ以上の実施形態において、コンピュータ実行可能コンポーネントはメモリから実行することができる。当該メモリは、１つ以上の分散メモリユニットを含むか、またはそれらで構成することができる。本明細書において、「メモリ」および「メモリユニット」という用語は交換可能である。さらに、本明細書に記載の１つ以上の実施形態は、コンピュータ実行可能コンポーネントのコードを分散方式で実行することができ、例えば、複数のプロセッサが組み合わさってまたは協働して、１つ以上の分散メモリユニットからコードを実行することができる。本明細書において、「メモリ」という用語は、１つの場所における単一のメモリもしくはメモリユニット、または１つ以上の場所における複数のメモリもしくはメモリユニットを包含することができる。

本明細書において、「コンポーネント」、「システム」、「プラットフォーム」、「インタフェース」などの用語は、コンピュータ関連のエンティティもしくは１つ以上の特定の機能を有する動作機械に関連するエンティティを指すか、もしくはこれらを含むか、またはその両方として用いることができる。本明細書で開示するエンティティは、ハードウェア、ハードウェアとソフトウェアの組み合せ、ソフトウェア、または実行中のソフトウェアのいずれかとすることができる。コンポーネントは一例として、プロセッサ上で動作するプロセス、プロセッサ、オブジェクト、実行ファイル、実行スレッド、プログラム、もしくはコンピュータまたはこれらの組み合わせとすることができる。例えば、サーバ上で動作するアプリケーションおよび当該サーバの両方を、１つのコンポーネントとすることができる。プロセスもしくは実行スレッドまたはその両方に、１つ以上のコンポーネントが存在することができる。そして、コンポーネントは、１台のコンピュータに局所化するか、もしくは２台以上のコンピュータに分散するか、またはその両方とすることができる。他の例として、それぞれのコンポーネントは、種々のデータ構造が記憶された種々のコンピュータ可読媒体から実行することができる。これらのコンポーネントは、１つ以上のデータパケットを有する信号に従うなどして、ローカルもしくはリモートまたはその両方のプロセスを介して通信することができる（例えば、一のコンポーネントからのデータは、ローカルシステム内で、分散システム内で、もしくは他のシステムとのネットワーク（インターネットなど）を介して、またはこれらの組み合わせによって、信号を介して他のコンポーネントと相互作用する）。さらに他の例として、コンポーネントは、プロセッサによって実行されるソフトウェアまたはファームウェアアプリケーションによって動作する電気回路または電子回路によって動作する機械部品によって実現される、特定の機能を有する装置とすることができる。かかる場合、プロセッサは装置の内部にあっても外部にあってもよく、ソフトウェアまたはファームウェアアプリケーションの少なくとも一部を実行することができる。さらに他の例として、コンポーネントは、機械部品なしで電子コンポーネントを介して特定の機能を実現する装置とすることができる。ここで、電子コンポーネントは、当該電子コンポーネントの機能の少なくとも一部を付与するソフトウェアまたはファームウェアを実行するためのプロセッサまたは他の手段を含むことができる。一の態様において、コンポーネントは、仮想マシンを介して、（例えば、クラウドコンピューティングシステム内で）電子コンポーネントをエミュレートすることができる。

さらに、「または／もしくは／あるいは（ｏｒ）」という用語は、排他的な意味ではなく、包含的な意味で用いられるものとする。すなわち、別段の指定がない限り、または文脈から明らかでない限り、「ＸがＡまたはＢを使用する」と言った場合、自然な包含的置換のいずれかを意味するものとする。すなわち、「ＸがＡを使用する」、「ＸがＢを使用する」、または「ＸがＡおよびＢの両方を使用する」場合、これらの例はいずれも「ＸがＡまたはＢを使用する」に当てはまる。さらに、本明細書および添付図面で使用する冠詞「ａ」および「ａｎ」（「ある／１つの／一の」）は、別段の指定がない限り、または文脈から単数を意味していることが明らかでない限り、概して「１つまたは複数」を意味すると解釈されるべきである。また、本明細書において、「例（example）」や「例示的な（exemplary）」という用語は、例、事例、または例示として提供される内容であることを意味するために用いられる。ここで断っておくが、本明細書に開示する主題はかかる例によって限定されない。さらに、「例」や「例示的」なものとして本明細書に記載したいかなる態様または設計も、必ずしも他の態様または設計よりも好ましいまたは有利なものであると解釈すべきではなく、当業者に公知の同等の例示的な構造および技術を排除することを意図するものでもない。

本明細書で使用される「プロセッサ」という用語は、例えばシングルコアプロセッサ、ソフトウェアマルチスレッド実行機能を有するシングルプロセッサ、マルチコアプロセッサ、ソフトウェアマルチスレッド実行機能を有するマルチコアプロセッサ、ハードウェアマルチスレッド技術を有するマルチコアプロセッサ、並列プラットフォーム、および分散共有メモリを有する並列プラットフォームを含む、実質的にいかなる種類のコンピュータ処理ユニットまたは装置をも意味することができる。さらに、プロセッサは、本明細書に記載の機能を実行するように設計された集積回路、特定用途向け集積回路（ＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブルロジックコントローラ（ＰＬＣ）、複合プログラマブルロジックデバイス（ＣＰＬＤ）、ディスクリートゲートもしくはトランジスタロジック、ディスクリートハードウェアコンポーネント、またはこれらの任意の組み合わせを意味することができる。さらに、プロセッサは、空間使用量を最適化するかまたはユーザ機器性能を向上させるために、例えば分子および量子ドットに基づくトランジスタや、スイッチ、ゲートなどのナノスケールアーキテクチャを利用することができる。プロセッサは、コンピュータ処理ユニットの組み合わせとして実装することもできる。本開示において、「ストア（store）」、「ストレージ」、「データストア（data store）」、「データストレージ」、「データベース」などの用語、ならびにコンポーネントの動作および機能に関係するほぼすべての他の情報記憶コンポーネントに関する用語は、「メモリコンポーネント」、「メモリ」内に具体化されるエンティティ、またはメモリを構成するコンポーネントを意味するために使用される。なお、本明細書に記載のメモリもしくはメモリコンポーネントまたはその両方は、揮発性メモリまたは不揮発性メモリのいずれでもよく、または、揮発性および不揮発性メモリの両方を含むことができる。一例として、不揮発性メモリは、ＲＯＭ、プログラマブルＲＯＭ（ＰＲＯＭ）、電気的プログラマブルＲＯＭ（ＥＰＲＯＭ）、電気的消去可能ＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリ、または不揮発性ＲＡＭ（たとえば、強誘電体ＲＡＭ（ＦｅＲＡＭ））を含むことができる。揮発性メモリは、例えば外部キャッシュメモリとして機能することができるＲＡＭを含むことができる。一例として、ＲＡＭは、シンクロナスＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、ダブルデータレートＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ）、エンハンストＳＤＲＡＭ（ＥＳＤＲＡＭ）、シンクリンクＤＲＡＭ（ＳＬＤＲＡＭ）、ダイレクトラムバスＲＡＭ（ＤＲＲＡＭ）、ダイレクトラムバスダイナミックＲＡＭ（ＤＲＤＲＡＭ）、およびラムバスダイナミックＲＡＭ（ＲＤＲＡＭ）などの多くの形態で利用可能である。さらに、本開示のシステムまたはコンピュータ実装方法におけるメモリコンポーネントは、これらおよび任意の他の適切な種類のメモリを含むものとするが、それに限定されるものではない。

上記の説明には、システムおよびコンピュータ実装方法の単なる例が含まれている。当然ながら、本開示を説明するにあたり、コンポーネントまたはコンピュータ実装方法について考え得る全ての組み合わせを説明することは不可能であるが、当業者にとっては自明なように、本開示に対してさらなる組み合わせや置換が多数可能である。さらに、「含む（include）」、「有する／備える（have）」、「所有する（possess）」などの用語が発明の詳細な説明、特許請求の範囲、付録、および図面において使用される場合、かかる用語は、「含む（comprising）」が請求項において移行句として使用される場合の解釈と同様に、包含的な意味を持つものとする。

本発明の種々の実施形態を例示として説明してきたが、網羅的であることや、これらの実施形態に限定することを意図したものではない。当業者には明らかなように、記載した各実施形態の範囲および要旨から逸脱することなく、多くの変更および変形が可能である。本明細書で用いられる用語は、各実施形態の原理、実際の用途、もしくは市場で確認される技術に対する技術的な改善を最もよく説明するために、または、当業者が本明細書に開示する各実施形態を理解できるように選択されたものである。

Claims (24)

1. プロセッサを含むシステムであって、
   前記プロセッサは、非一時的なコンピュータ可読媒体に記憶されたコンピュータ実行可能コンポーネントを実行し、
   前記コンピュータ実行可能コンポーネントは、
   オブジェクトがメモリに割り当てられた際に、境界情報を格納するためのテーブルにエントリを割り当てるエントリコンポーネントと、
   オブジェクトアドレスの未使用ビットを転用して、前記テーブルのエントリへのインデックスを格納する転用コンポーネントと、
   を含む、システム。
2. アドレス内のインデックスビットを用いて前記境界情報にアクセスすることによって、ロード命令およびストア命令に対してハードウェアで境界チェックを実行するチェックコンポーネントをさらに含む、
   請求項１に記載のシステム。
3. 後続のオブジェクトアドレスが割り当てステートメントまたはポインタ演算を介して導出される際に、前記インデックスを自動的に伝達する伝達コンポーネントをさらに含む、
   請求項１に記載のシステム。
4. 前記チェックコンポーネントは、配列の境界をチェックする、
   請求項２に記載のシステム。
5. 前記チェックコンポーネントは、配列参照が境界内であるか境界外であるかを判定し、境界外の配列参照の発生を軽減する、
   請求項２に記載のシステム。
6. 前記転用コンポーネントは、前記オブジェクトアドレス内の未使用ビットを用いて、アクセス可能なメモリアドレスの範囲を追跡する、
   請求項１に記載のシステム。
7. 前記伝達コンポーネントは、前記オブジェクトアドレスが割り当てステートメントにコピーされる際に、未使用ビットで追加の情報を伝達する、
   請求項３に記載のシステム。
8. 前記伝達コンポーネントは、前記オブジェクトアドレスが関数呼び出しの引数として渡される際に、未使用ビットで追加の情報を伝達する、
   請求項３に記載のシステム。
9. 前記伝達コンポーネントは、前記オブジェクトアドレスがアドレスの計算に使用される際に、未使用ビットで追加の情報を伝達する、
   請求項３に記載のシステム。
10. アドレスにおけるインデックスビットとアドレスビットとの間に、保護ビットが介在する、
    請求項１に記載のシステム。
11. 前記テーブルに格納される前記境界情報を管理することは、メモリ割り当て関数またはメモリ解放ライブラリ関数に対して変更を行うことを含む、
    請求項１に記載のシステム。
12. アプリケーションが前記テーブルのサイズを超えるアクティブオブジェクト数を含む場合、または当該アクティブオブジェクト数をサポートするために必要なインデックスビットの数が、割り当てられたインデックスビットの数を超える場合、前記境界情報のサブセットがオーバーフローテーブルに格納される、
    請求項１に記載のシステム。
13. 前記オーバーフローテーブルを示す値を含むインデックスビットがアドレスに含まれている場合、当該アドレスを用いて前記境界情報のサブセット内の前記境界情報にアクセスすることによって、ロード命令およびストア命令に対してハードウェアで境界チェックを実行するチェックコンポーネントをさらに含む、
    請求項１２に記載のシステム。
14. コンピュータ実装方法であって、
    オブジェクトがメモリに割り当てられた際に、プロセッサにより、境界情報を格納するためのテーブルにエントリを割り当てることと、
    プロセッサにより、オブジェクトアドレスの未使用ビットを転用して、前記テーブルのエントリへのインデックスを格納することと、
    を含む、方法。
15. プロセッサにより、アドレス内のインデックスビットを用いて前記境界情報にアクセスすることによって、ロード命令およびストア命令に対してハードウェアで境界チェックを実行することをさらに含む、
    請求項１４に記載の方法。
16. 後続のオブジェクトアドレスが割り当てステートメントまたはポインタ演算を介して導出される際に、プロセッサにより、前記インデックスを自動的に伝達することをさらに含む、
    請求項１４に記載の方法。
17. プロセッサにより、配列の境界をチェックすることをさらに含む、
    請求項１５に記載の方法。
18. プロセッサにより、配列参照が境界内であるか境界外であるかを判定することをさらに含む、
    請求項１５に記載の方法。
19. プロセッサにより、境界外の配列参照の発生を軽減することをさらに含む、
    請求項１８に記載の方法。
20. プロセッサにより、前記オブジェクトアドレス内の未使用ビットを用いて、アクセス可能なメモリアドレスの範囲を追跡することをさらに含む、
    請求項１５に記載の方法。
21. 前記オブジェクトアドレスが割り当てステートメントにコピーされる際に、プロセッサにより、未使用ビットで追加の情報を伝達することをさらに含む、
    請求項１５に記載の方法。
22. 前記オブジェクトアドレスが関数呼び出しの引数として渡される際に、プロセッサにより、未使用ビットで追加の情報を伝達することをさらに含む、
    請求項１５に記載の方法。
23. 前記オブジェクトアドレスがアドレスの計算に使用される際に、プロセッサにより、未使用ビットで追加の情報を伝達することをさらに含む、
    請求項１５に記載の方法。
24. プログラム命令が実装されたコンピュータ可読記憶媒体を含むコンピュータプログラム製品であって、当該プログラム命令はプロセッサによって実行可能であり、当該プロセッサに、
    オブジェクトが割り当てられた際に、境界情報を格納するためのテーブルにエントリを割り当てる機能と、
    オブジェクトアドレスの未使用ビットを転用して、前記テーブルのエントリへのインデックスを格納する機能と、
    を実行させる、コンピュータプログラム製品。

Images