知財求人 - 知財ポータルサイト「IP Force」
▶ テキサス インスツルメンツ インコーポレイテッドの特許一覧
特許7679569ハードウェアサポートされたメモリバッファオーバーフロー検出を備えるプロセッサ
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2025-05-12
(45)【発行日】2025-05-20
(54)【発明の名称】ハードウェアサポートされたメモリバッファオーバーフロー検出を備えるプロセッサ
(51)【国際特許分類】
G06F 9/34 20180101AFI20250513BHJP
G06F 9/355 20180101ALI20250513BHJP
【ＦＩ】
G06F9/34 340C
G06F9/355 390
【請求項の数】
15
(21)【出願番号】P 2020573096
(86)(22)【出願日】2019-03-18
(65)【公表番号】
(43)【公表日】2021-08-02
(86)【国際出願番号】 US2019022673
(87)【国際公開番号】W WO2019178584
(87)【国際公開日】2019-09-19
【審査請求日】2022-03-17
【審判番号】
【審判請求日】2024-02-20
(31)【優先権主張番号】15/923,121
(32)【優先日】2018-03-16
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】507107291
【氏名又は名称】テキサス インスツルメンツ インコーポレイテッド
(74)【代理人】
【識別番号】100098497
【弁理士】
【氏名又は名称】片寄 恭三
(72)【発明者】
【氏名】エリック ニュートン シェレブ
(72)【発明者】
【氏名】エリック ティエリ ペーテルス
(72)【発明者】
【氏名】ペル トーステイン ロイン
【合議体】
【審判長】吉田 美彦
【審判官】須田 勝巳
【審判官】脇岡 剛
(56)【参考文献】
【文献】特表２００１－５１１２７１号公報（ＪＰ，Ａ）
【文献】米国特許出願公開第２００６／０２２５１３５（ＵＳ，Ａ１）
【文献】特開平０６－１６８１４５号公報（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
G06F 9/34
G06F 9/355
(57)【特許請求の範囲】
【請求項1】
プロセッサであって、プログラム命令を実行する回路要素であって、各プログラム命令がそれぞれのプログラムアドレスを有する位置にストアされている、前記プログラム命令を実行する回路要素と、
実行されるべきプログラム命令のプログラムアドレスの表示をストアする回路要素と、
複数のスタックストレージスペースを含むメモリスタックであって、各スタックストレージスペースがリターンアドレスとしてプログラムアドレスを受け取るように動作可能である、前記メモリスタックと、
それぞれのスタックストレージスペースに対応する複数の書き込み保護インジケータと、
障害を生成する回路要素と、
を含み、
前記障害を生成する回路要素は、
前記複数の書き込み保護インジケータからの値がフェッチされ得るキャッシュメモリと、
命令バス、トレースインターフェース信号または他のハードウェアからの信号に基づき前記メモリスタックへのプロセッサ読出しまたはプロセッサ書き込みを検出する検出部と、
を含み、
前記障害を生成する回路要素は、リターンアドレスの書込みに対応する前記プロセッサ書き込みに応答して前記スタックストレージスペースにリターンアドレスを書き込むとともに対応する書込み保護インジケータを設定し、
前記障害を生成する回路要素は、選択されたスタックストレージスペースへのプロセッサ書き込み要求を受信し、当該スタックストレージスペースに対応する書き込み保護インジケータがキャッシュメモリ内で利用可能である場合、キャッシュヒットが発生し、書き込み保護インジケータが選択されたスタックストレージスペースが書き込み保護されていないことを示す場合、書き込み要求は実行され、書き込み保護インジケータが選択されたスタックストレージスペースが書き込み保護されていることを示す場合、プロセッサ書き込みに対して障害を生成する、
プロセッサ。
【請求項2】
請求項１に記載のプロセッサであって、前記選択されたスタックストレージスペースがリターンアドレスをストアしている場合に、前記それぞれの書き込み保護インジケータが、前記選択されたスタックストレージスペースが書き込み保護されていることを示す、プロセッサ。
【請求項3】
請求項１に記載のプロセッサであって、前記メモリスタックが前記複数の書き込み保護インジケータを更に含む、プロセッサ。
【請求項4】
請求項１に記載のプロセッサであって、前記複数のスタックストレージスペースにおける各スタックストレージスペースが、
前記リターンアドレスを含み得るデータをストアする第１の部分と、
前記複数の書き込み保護インジケータにおけるそれぞれの書き込み保護インジケータとして動作可能である第２の部分と、
を含む、プロセッサ。
【請求項5】
請求項４に記載のプロセッサであって、前記第２の部分が単一のビットで構成される、プロセッサ。
【請求項6】
請求項４に記載のプロセッサであって、前記第２の部分が単一の最下位ビットで構成される、プロセッサ。
【請求項7】
請求項４に記載のプロセッサであって、前記第１の部分が２Ｎビットで構成されるセットから選択され、Ｎが４又はそれ以上の整数である、プロセッサ。
【請求項8】
請求項４に記載のプロセッサであって、前記第２の部分が単一のビットで構成され、
前記第１の部分が２Ｎビットで構成されるセットから選択され、Ｎが４又はそれ以上の整数である、プロセッサ。
【請求項9】
請求項１に記載のプロセッサであって、前記メモリスタックが、前記複数の書き込み保護インジケータをストアする少なくとも１つのストレージスペースを更に含む、プロセッサ。
【請求項10】
請求項９に記載のプロセッサであって、前記複数のスタックストレージスペースにおける各スタックストレージスペースが２Ｎビットで構成され、Ｎが４又はそれ以上の整数である、プロセッサ。
【請求項11】
請求項１に記載のプロセッサであって、前記実行されるべきプログラムアドレスの表示をストアする回路要素がプログラムカウンタを含む、プロセッサ。
【請求項12】
請求項１に記載のプロセッサであって、前記障害を生成する回路要素が、更に、前記選択されたスタックストレージスペースにリターンアドレスを上書きすることを禁止する、プロセッサ。
【請求項13】
請求項１に記載のプロセッサであって、前記複数の書き込み保護インジケータの各々が単一のビットで構成される、プロセッサ。
【請求項14】
請求項１に記載のプロセッサであって、前記障害を生成する回路要素は、前記検出部によって検出されたプロセッサ読出しが、リターンアドレスを読み出すためのポップ動作か否かを判定し、ポップ動作の場合、リターンアドレスのスタックストレージに対応する書込み保護インジケータにより書込み保護をクリアする、プロセッサ。
【請求項15】
請求項１に記載のプロセッサであって、前記メモリスタックが複数のメモリスタックにおける第１のメモリスタックを含み、前記複数のメモリスタックにおける各メモリスタックがそれぞれの複数のスタックストレージスペースを含み、
前記プロセッサが、前記複数のメモリスタックの各それぞれのメモリスタックに対する複数の書き込み保護インジケータを更に含み、
前記生成する回路要素が、選択されたスタックストレージスペースへのプロセッサ書き込みに応答して障害を生成し、前記選択されたスタックストレージスペースに対して、前記複数の書き込み保護インジケータのそれぞれ１つにおけるそれぞれの書き込み保護インジケータが前記選択されたスタックストレージスペースが書き込み保護されていることを示す、プロセッサ。
【発明の詳細な説明】
【技術分野】
【0001】
本願は、全般的に、プロセッサ（マイクロプロセッサ、デジタル信号プロセッサ、及びマイクロコントローラ等）に関し、特に、望ましくないメモリバッファオーバーフローから保護するためのハードウェアサポートを備えるプロセッサに関する。
【背景技術】
【0002】
プロセッサは、通常はスタックと呼ばれるメモリの一部を含むか又はメモリの一部に対するアクセスを有する。スタックには、コールスタック、実行スタック、プログラムスタック、及びその他の付加的な表記が用いられることもある。用語「スタック」の根拠の一部はメモリ部分が後入れ先出しであるためであり、情報がメモリに追加されると、既にそこに存在する既存の情報にその情報を集計（aggregate）して付加情報をスタックし、その後、その情報がメモリから除去されると、集計された情報のスタックを減少させる。また、この文脈において、スタックに付加された情報は通常、例示の目的で、スタックの「頂部」に位置するものを示すが、実際には、幾つかのアーキテクチャでは、スタックを含むメモリエリアは、増加するメモリアドレスを用いてアドレスされ得、他のアーキテクチャでは、減少するメモリアドレスが用いられる。後者の場合でも、最小アドレスはスタックの「頂部」とみなされる。
【0003】
スタックにストアされる情報の主要なタイプは、実行可能なプログラミングコードのシーケンスにおけるポイントを表すアドレスである。より詳細には、通常、コードがプロセッサによって実行されているとき、しばしばプログラムカウンタと呼ばれるレジスタなどのメモリストアが、現在実行されている命令のそれぞれのメモリアドレスをストアする。プログラムカウンタは、概してコードが順次に実行されるため、そのように名付けられている。プログラムカウンタは、カウント、即ち増分することができ、それによって、前回実行された命令のアドレスの直後のアドレスにおいて次の命令の実行に進み、コードの特定のブロックに対しても同様である。しかしながら、実行可能命令のこのタイプの連続アドレス指定における種々の点において、シーケンスにおける変更が所望され得、それは、「呼び出す（call）」、「分岐する（branch）」、「ジャンプする（jump）」又は、その他の命令を含み得るシーケンス変更命令によって達成される。これにより、現在実行されている命令に続く次の順次アドレスではないアドレスを持つターゲット命令に実行シーケンスを向ける。ターゲット命令は、ルーチン又はサブルーチンと呼ばれることもある他の命令のグループの一部であり得る。アドレス指定を順次様式を継続する以外のものに変更することになるシーケンス変更（例えば、呼び出し）命令に関連して、１つの一般的なアプローチでは、スタックに対してプログラムカウンタの現在又は次の増分値がストアされ（しばしば、「プッシュされる」と呼ばれる）、そのため、ターゲットルーチンが完了した後、アドレスフローは、その呼び出しの前に生じていたシーケンスに戻される。即ち、命令シーケンスは、そのルーチンに対する呼び出しに続く次の命令に「リターン」する。或いは、幾つかのアーキテクチャ（アドバンストＲＩＳＣマシン（ＡＲＭ）等）は、スタックに対してプログラムカウンタを直ちにプッシュせず、その代わり、呼び出された関数が別の関数を呼び出す（又は呼び出し得る）場合にのみ、リターンアドレスがレジスタにストアされ、リターンレジスタの値は、その後、スタックにプッシュされる。いずれにしても、アドレスがスタックにプッシュされると、呼び出しが発生したときにスタックにプッシュされたアドレスを取得することによって、呼び出しに続くリターンが達成され得、その値はスタックからポップされたと言われ、これにより、それを除去し、その結果、スタックの頂部は、スタック上の次の最下位ワードに移動される。上記の説明は、最終的にルーチンが、単一の呼び出しに続くシーケンスに続くアドレスに直接戻る、ルーチンに対する単一の呼び出しのみを想定している。しかしながら、第１のルーチンが、アクティブであるとき及びその完了以前に、第２のルーチンを呼び出すことがあり、その場合、この後者の呼び出しは、付加的なリターンアドレスをスタックに対して再びプッシュする。付加的なプログラムカウンタアドレスは、呼び出された第２のルーチンの完了時にプログラムフローが戻るべき実行可能命令アドレスを識別する。このように、（リターンの前の）２つの連続呼び出しの例において、スタック上には、第１のルーチンが呼び出されたときのプログラムリターンアドレスが存在し得、その上に、第２のルーチンが呼び出されたときのプログラムリターンアドレスが存在し得る。このようなプロセスが、複数のルーチンの間で繰り返され得、そのため、スタックは、付加的な呼び出し毎に付加的な新規のアドレスを受け取り、そのため、連続して呼び出される各ルーチンからリターンが実行されると、付加された各アドレスが連続してポップされる。従って、スタックは、各それぞれのルーチンが呼び出されると、各呼び出されたルーチンを最終的に完了するための、及び実行アドレスをリターンするための表示を提供する。
【0004】
上記で説明してきたように、スタック技術は長い間、実行可能命令フローを制御する健全な手法を提供してきたが、不幸な副産物は、スタック内のプログラムカウンタアドレスが、適正な実行可能なコードフローを再確立するために必要とされる前に上書きされる場合の、スタックの意図しない欠陥、又はスタックに対する故意の攻撃であった。例えば、スタックは通常、ストレージ位置の有限数によって提供される最大容量を有する。従って、アドレスが最大容量を超えて書き込まれると、スタックオーバーフローが発生したと言われ、例えば、システム上で実行されているソフトウェア（例えば、オペレーティングシステム）等を介して、又は「スタックレジスタの頂部」を介して、その事象が認識されると、不安定な挙動又は報告される欠陥が発生する。「スタックレジスタの頂部」は、幾つかのハードウェアアプローチにおいて、最上部のスタック位置を示すために用いられ、従って、その位置を超えたことを検出するためにも使用可能である。別の例として、プログラムカウンタアドレスに加えて、或るアーキテクチャでは、通常は一時的に、データをストアするためにスタックが用いられる。そのようなストレージ位置は通常「スタックフレーム」又は「呼び出しフレーム」と呼ばれる。このようなフレームは通常、アーキテクチャ及び／又はアプリケーションバイナリインタフェース（ＡＢＩ）固有であるが、それは、しばしば、呼び出された関数に対する任意の一時的なデータスペースと共に、呼び出された関数に対するパラメータ及びリターンアドレスを含む。従って、この場合、スタック内の付加的なメモリ位置がそのスタックフレームのために一時的に予約される。それは、ストアされたリターンアドレスの近くであるか又はストアされたリターンアドレスを含み、スタックメモリスペース内である。バッファがその意図されたサイズを超えて充填された場合、そのような充填は、現在又は前のスタックフレームにストアされた有効なリターンアドレス及び／又はデータを上書きし得る。
【0005】
上記の説明に加えて、「ハッキング」或いはコンピューティングシステムに対するその他の妨害の目的で、プロセッサの制御を取得しその意図された動作を損なわせるような種々の邪悪な攻撃技法が進化してきた。その結果、比較的良好な動作から重要な機能性の損傷やセキュリティ違反までを含み得る種々の結果をもたらしてきた。この点において、スタックオーバーフローは、そのような攻撃の一般的なツールであり、「スタック破壊（smashing the stack）」と呼ばれることもある。この場合、「ハッカー」は、プログラム制御を、適正な動作スタックリターンアドレスではない位置に移動させるように試みる。これは、例えば、有効なリターンアドレスを異なる不正なアドレスで上書きすることによって達成され得る。それによって、プログラムフローは、スタックに戻る際、不正なアドレスをポップし、実行可能フローを他の命令に向ける。そのような他の命令はまた、システムに悪意的にロードされ得、それによって、スマッシュに続いて実行され得る。或いは、ハッカーはまた、ガジェットと呼ばれることもある有効な既存のコードのサブセット又は抜粋を用いることを学習している。そこでは、異なるガジェットを順次縫い合わせることによって、更なる不快な結果に到達し得る。それにより、各ガジェットのそれぞれの機能性を組み合わせて、ハッカーが実装した、システムにおいてもともと設計された意図されない機能又は結果の達成が目指される。この後者のアプローチは、各ガジェットがそれぞれのリターンで終了するので、リターン志向プログラミング（ＲＯＰ）と呼ばれることもある。各ガジェットの終了時のリターンは、スタックからリターンアドレス（即ち、バッファオーバーフローを介してハッカーが書き込んだ代替アドレス）をポップさせる。これによって、プロセッサに実行を継続させ、その代替アドレスの次からスタートさせる。それは、従って、別のガジェットのスタートを開始させる。それは、その後、複数のそのようなガジェットで繰り返され得る。実際、この問題においてガジェットの使用は、ハッカーを、所謂チューリング（数学者アラン・チューリングにちなんで名づけられた）完全性に近づかせるか或いはそれに到達させる。これは、概して、任意の単一テーピングされたチューリングマシンをシミュレートするため、即ち、そのようなアルゴリズムのセット内の全てのアルゴリズムを達成するために、充分なデータ操作動作を提供することを意味する。それは、緩い解釈において、幅広い機能を達成する能力を意味する。
【0006】
上述のように、従来のソフトウェア及びハードウェア（例えば、データ実行防止（ＤＥＰ））技術は、バッファ／スタックにおける上書きされたリターンアドレスを介するプログラム制御フローの意図しない及び／又は悪意ある指示変更を防止及び／又は検出するように試みる。しかしながら、そのようなアプローチは１つ又は複数の欠点を有し、そういった欠点には、（ａ）オーバーヘッドコストが高い、（ｂ）開発者が新規ツールを実装又は習得する必要がある、（ｃ）膨大なテストが必要である、（ｄ）再コンパイル及び／又はソースコード変更が必要であり、それらは、第三者ライブラリーの場合必ずしも可能ではない、及び（ｅ）ハッカーが、ＤＥＰの回避策としてＲＯＰを含む従来のアプローチの周囲の手法を発見している、等がある。このように、スタックオーバーフローに対する従来のソフトウェア緩和技法は種々のニーズに貢献しているが、改善は可能である。
【発明の概要】
【0007】
例示の実施形態において、プロセッサが、（ａ）プログラム命令を実行するための回路要素であって、各プログラム命令がそれぞれのプログラムアドレスを持つ位置にストアされている回路要素と、（ｂ）実行されるべきプログラム命令のプログラムアドレスの表示をストアするための回路要素と、（ｃ）複数のスタックストレージスペースを含むメモリスタックであって、各スタックストレージスペースがリターンアドレスとしてのプログラムアドレスを受け取るように動作可能であるメモリスタックと、（ｄ）それぞれのスタックストレージスペースに対応する複数の書き込み保護インジケータと、（ｅ）選択されたスタックストレージスペースに対してプロセッサ書き込みが向けられたことを検出することに応答して障害（fault）を生成するための回路要素であって、選択されたスタックストレージスペースに対して、複数の書き込み保護インジケータにおけるそれぞれの書き込み保護インジケータが、選択されたスタックストレージスペースが書き込み保護されていることを示す回路要素とを含む。
【図面の簡単な説明】
【0008】
【図1】例示の実施形態のプロセッサの電気的及び機能的ブロック図を示す。
【0009】
【0010】
【0011】
【0012】
【0013】
【発明を実施するための形態】
【0014】
図１は例示の実施形態のプロセッサ１０の電気的及び機能的ブロック図を示す。プロセッサは、本明細書に説明される機能を含む種々の計算回路の１つであり、そのため、それはマイクロプロセッサ、デジタル信号プロセッサ、マイクロコントローラなどのいずれかを含み得る。プロセッサ１０は、種々の従来のブロック及び例示の実施形態の改善を含み、それらの各々をこれ以降に説明する。
【0015】
プロセッサ１０は、通常、図１において適切なブロックによって示されるように、単一の集積回路デバイス１２として実装される。そのブロック内において（又は区切られ得るように個別に）、プロセッサ１０は、概して、制御ユニット１４、アルゴリズム論理ユニット（ＡＬＵ）１６、及びメモリユニット１８を含む、３個の主ブロックを含み、各ブロックは、図１に示すように、バスＢへの双方向結合によって互いに通信し得る。バスＢはまた、外部入力デバイス２０からデータを受け取り、データを外部出力デバイス２２に提供するように接続される。また、メモリユニット１８は、バスＢＭ１を介して内部メモリ２４と、バスＢＭ０を介して外部メモリ２６と通信し得る。より詳細には、制御ユニット１４は、他のブロックの起動及び動作を制御し、一般に、通常は、あり得るソースコード及び／又はオペレーティングシステムソフトウェアを含む何らの上位レベルのプログラミングに応答して、実行可能コードの命令のシーケンスを起こす。従って、この点において、制御ユニット１４はまた、プロセッサ１０のどこかに実現され得るプログラムカウンタ１４ＰＣの汎用表示を含むように図示されている。従って、制御ユニット１４は、特定のプログラムによって定義されたシーケンスに従って、また潜在的に他の効率対策（例えば、予測技術等）を用いて、内部メモリ２４（例えば、ＲＡＭ、ＲＯＭ）又は外部メモリ２６（例えば、フラッシュ）のいずれかから、メモリユニット１８にプログラム命令をフェッチさせ得る。メモリユニット１８によってフェッチされた命令は、ＡＬＵ １６に関連する１つ又は複数の実行パイプラインに提供される。そこでは、再び制御ユニット１４の制御下で命令が実行されて、データ移動、並びに論理及び数学的演算が達成され、それらの結果は、内部メモリ２４又は外部メモリ２６のいずれかにおけるストレージのために、再びメモリユニット１８に戻される。広義では、上述の命令及びデータの入力／出力はまた、入力デバイス２０からのそのような情報の受け取りと、出力デバイス２２に対するそのような情報の提供との組み合わせで成され得る。最後に、プロセッサ１０のこの説明は、プロセッサアーキテクチャの広義の概観である。しかしながら、プロセッサは、処理アーキテクチャ、接続性、及び機能性に関連して、種々の他の態様を含み得るか又は含むように特徴付けられ得る。
【0016】
図１の他の態様において、下記の説明は、プロセッサ１０の例示の実施形態の改善への導入を提供する。具体的には、内部メモリ２４は、内部メモリ２４におけるメモリスペースの専用部分であるメモリスタック２４ＳＴＫを含むように図示され、そこでは、スタックにストアされるワード数は、アーキテクチャ、アプリケーションバイナリインタフェース（ＡＢＩ）、及び特定のアプリケーションコードに従って幅広く変化し得る。また、ワード幅は、ＣＰＵアーキテクチャ（例えば、Ｎ≧４の場合、１６ビット、３２ビット、６４ビット等の２Ｎビット）によって定義される。また、スタック２４ＳＴＫは、概して、プログラムカウンタｌ４ＰＣから又はプログラムカウンタｌ４ＰＣに関連して（直接的に又は中間レジスタを介して）プッシュされたアドレスを受け取るため、及び、そのようなアドレスの、直接的に又はリターンレジスタ（例えば、ＡＲＭプロセッサにおけるリンクレジスタ）を介して、スタックからプログラムカウンタｌ４ＰＣに戻るポッピングを促進するために、存在し、機能する。それにより、プログラム実行フローを、プッシュされたアドレスを発生させた命令に続く次の命令を戻し、一方で、他の情報が、一時的にストアされ得、スタックメモリスペースから容易にアクセスされ得る、或る程度のバッファスペースを提供する。また、図１は、例えば、単一のスタック２４ＳＴＫのみを示す。これは、システムは１つ以上のそのようなスタックを含み、そこでは、各スタックはメモリの領域であり、多くのシステムにおいて、任意の箇所で開始又は終了し得るためである。例えば、通常、各スレッドがそれ自体のスタックを持つリアルタイムオペレーティングシステム（ＲＴＯＳ）を用いている場合、複数スタックが一般的である。
【0017】
図１の最後に、例示の実施形態について、スタック２４ＳＴＫ（他のスタックも同様）は、メモリユニット１８の一部として示されるバッファオーバーフロー保護（ＢＯＶＰ）回路１８ＢＯＶＰと関連して構成され及び／又は動作する。特に、以下に説明するように、ＢＯＶＰ回路ｌ８ＢＯＶＰとスタック２４ＳＴＫとの組み合わせは、特にスタック２４ＳＴＫ上でのリターンアドレスの直接的又は偶然的な上書き値に対して、強化されたハードウェア保護を提供する。そのような上書きは、ミス（例えば、Ｃ又はＣ＋＋におけるもの等の或るコードの間違った使用）、又は、スタックを計画的に破壊（smash）することを目指す意図的なハッキング攻撃によって生じ得る。
【0018】
図２は、図１のＢＯＶＰ回路ｌ８ＢＯＶＰ及びスタック２４ＳＴＫの更に詳細なブロック図を示す。例示の実施形態において、ＢＯＶＰ回路ｌ８ＢＯＶＰは、読み出し／書き込み（Ｒ／Ｗ）検出ブロック３０及び書き込み保護（ＷＰ）管理ブロック３２を含む。これらの付加的なブロックの各々は下記に説明され、本明細書に説明が提供されているように構成され得る。また、ＢＯＶＰ回路ｌ８ＢＯＶＰは、ハードウェア実装であることが好ましい。その理由は、たとえその一部であっても、それをソフトウェアで具現化することは、禁止量ではないとしても大量のランタイムオーバーヘッドを課し得るためである。
【0019】
ＢＯＶＰ回路ｌ８ＢＯＶＰは、プロセッサ１０（例えば、ＡＲＭ、ｘ８６、及びテキサス・インスツルメンツ社製の種々のプロセッサの１つ）が実装される特定のプラットフォームに基づき得る、適切な回路要素に接続され、そのため、スタック２４ＳＴＫと関連して読み出し又は書き込みが要求される各インスタンスが検出される。例えば、スタック上にリターンアドレスをプッシュしようと試みるプッシュ命令に関連して書き込みが生じ得る。同様に、データが一つの位置からスタックにコピーされるときに書き込みが生じ得、スタック２４ＳＴＫの一部が、一時的にバッファとして割り当てられる。別の例として、ポップ命令に関連して読み出しが起こり得、例えば、スタック２４ＳＴＫに事前にプッシュされたリターンアドレスを読み出そうと試みる。最後の例として、バッファとして一時的に割り当てられたスタック２４ＳＴＫの一部からデータが読み出されるときにも読み出しが起こり得る。
【0020】
ＷＰ管理ブロック３２は、スタック２４ＳＴＫにおける各メモリ位置（即ち、ワード）に関連する書き込み保護インジケータデータを管理する。図２に示されるような例示の実施形態において、書き込み保護データが、スタック２４ＳＴＫにおける各ワード位置に添付された単一のビットとして実装されている。このように、図２においても、スタック２４ＳＴＫは、それぞれ３２ビットのメモリワードを持つように図示され、各ワードに（例えば、最下位ビットの次に）添付されるのは、付加的な書き込み保護ＷＰインジケータビットである。従って、１つの例示の実施形態において、スタック２４ＳＴＫを含むためのメモリ（例えば、ＳＲＡＭ）は、公称サイズのメモリワード（例えば、３２ビット）を超えて、１つの付加的ビットを含むように構成される。そのようなアプローチにおいて、プロセッサメモリは細分化され得、そのため、メモリの一部がワード幅のみとなり、別の部分がメモリワード毎の付加的ビットを含む。以下に説明するように、代替の例示の実施形態は、また、公称ワードサイズを超えてメモリワードの幅を拡大することなく、ＷＰインジケータビットを各メモリワードに関連させることを意図している。いずれにしても、以下に更に説明されるように、ＷＰ管理ブロック３２は、スタック２４ＳＴＫにおいて任意のＷＰインジケータビットの読み出し又は書き込みをするように、条件付きで動作可能であり、そのような読み出し及び書き込みに対する条件を下記に説明する。また、この点に関して、各ワード（及びその関連ＷＰインジケータビット）が別々にアドレス可能であり、それは図２における取り決めによって示され、本記載において、スタックアドレスＳＴＫ＜ｘｘ＞によって参照され、ｘｘはアドレス又は位置表示である。例えば、図２において、３２個のそのようなアドレスが、ＳＴＫＡ＜００＞からＳＴＫＡ＜３ｌ＞として示されている。この点に関して最後に、図２はスタックポインタＳＰＴＲを図示し、スタックポインタＳＰＴＲは、現在のスタックアドレスを識別する値（例えば、レジスタにストアされている値）であり、場合によってはその対応するＷＰインジケータビットであり得る。このように、図２において、スタックポインタＳＰＴＲは、空のスタック２４ＳＴＫの頂部（即ち、ＳＴＫＡ＜００＞）、つまり、リターンアドレスがプッシュされ得る次の位置を指し示している（ここでは、情報がまだ書き込まれていないので、頂部は書き込まれ得る第１番目のワードである）。また、図２の例においても、スタックポインタＳＰＴＲは、スタックアドレスの各それぞれの増分を用いて、垂直に上方に移動することによって、スタックの各新規の頂部に向かって移動するように示されている。しかしながら、幾つかのスタック方位が、スタックアドレスの減分に関連して「頂部に向かう」スタックポインタの動きを有すると考えられる。ここで、本記載においけるいずれの事象においても、スタックにリターンアドレスを付加することが、スタックの頂部を効果的に変化させることであると考えられる。スタックポインタによって示されるように、リターンアドレスの付加が行われると、スタックに情報が追加さされ得る次の位置（これ以降、スタックの「頂部」と呼ばれる）に進む。そのような移動は、それぞれ異なる例示の実施形態において、スタックアドレスの増分又は減分を介して達成され得る。
【0021】
図３は、プロセッサ１０の動作の例示の実施形態の方法３００のフローチャートを示す。このフローチャートは、図２のブロックを特に参照し、また図２のブロックによって実装され、全てスタック２４ＳＴＫの読み出し及び書き込みに関連する。従って、方法３００は、スタック２４ＳＴＫに関して読み出し又は書き込みのいずれかが要求されたときにＲ／Ｗ検出３０によって検出される、スタックアクセスステップ３０２で開始する。この点に関して、Ｒ／Ｗ検出３０は、適切な信号に結合された充分な回路要素（例えば、ロジック）を含む。適切な信号とは、命令バス、トレースインタフェース信号、又は他のハードウェアからの信号等であり、それらはスタック読み出し／書き込み動作が試みられたときに監視及び検出され得、一方、他のスタック書き込みからのスタックプッシュを更に区別し、また、他のスタック読み出しからのスタックポップを区別する。そのような信号を識別、監視、及び検出することは、プロセッサ１０の特定のアーキテクチャが与えられると達成され得る。いずれにしても、要求された動作が書き込みである場合、方法３００はステップ３０４に続き、要求された動作が読み出しである場合、方法３００はステップ３０６に続く。これらの選択肢の各々を以下に説明する。
【0022】
ここで、ＷＰインジケータの例示の実施形態の使用に従った書き込み保護を紹介し、以下に説明する。スタック２４ＳＴＫに対してプッシュされるそれぞれのリターンアドレスを後の上書きから保護するために、ＷＰインジケータビットが設定される。これにより、それぞれのＷＰインジケータビットによって保護されているスタックにストアされたリターンアドレスに上書きが試みられると、障害が生成されて、既にストアされている既存の保護されたリターンアドレスの上書きが防止される。そのため、既存の保護されたリターンアドレスがあらかじめストアされていないスタック位置に対して、新規のリターンアドレス又はバッファ情報のいずれかを書き込むためにスタックアクセスが引き起こされると、その書き込みアクセスは許可される。また、引き起こされたスタックアクセスが新規のリターンアドレスを保護されていない（即ち、ＷＰインジケータが設定されていない）スタックワードに対して書き込みを行うためである場合、その書き込みを用いて、ＷＰインジケータが設定されて、その後、その新規のリターンアドレスを、上書きされることから保護する。しかしながら、新規のリターンアドレスを、既存の保護されたリターンアドレスを既にストアしているスタック位置に対してプッシュするようにスタックアクセスが引き起こされると、障害が生成されて、既にストアされた、既存の保護されたリターンアドレスの上書きを防止する。これら及びその他の偶発事象を更に下記に説明する。
【0023】
スタック２４ＳＴＫに対する検出された書き込みアクセスが検出されたため到達したステップ３０４において、ステップ３０４は、データをストアするために書き込みが試みられているアドレスに対するＷＰインジケータビットを評価する。また特に、ＷＰインジケータビットが既に設定されているか否かを評価する。ＷＰインジケータビットが設定されている場合、方法３００はステップ３０４からステップ３０８に進み、一方、ＷＰインジケータビットが設定されていない場合、方法３００はステップ３０４からステップ３１０に進む。
【0024】
対応する設定されたＷＰインジケータビットを持つスタックアドレスに対して書き込みが試みられたために到達したステップ３０８は、障害を生成し、それによって障害を報告する。従って、図２において、この事象は、バスＢに結合されるアサートされたＦＡＵＬＴ信号によって示され、バスＢに結合される任意の回路によって受信及び応答され得る。障害報告は、実際の又は推測による任意の更なるプログラム実行に対する割り込み等を介する等の種々の手法で達成され得、その後、何らかの事象ハンドラが、それに従って障害を処理する。また、ステップ３０８の障害設定は、それにより、対応するＷＰデータが（例えば、ＳＲＡＭワードにおける３３番目のビットとして）設定されているスタック位置に対して、プッシュ又は非プッシュ書き込みが試みられると、障害をアサートする。また、上記で紹介したように、リターンアドレスがスタック２４ＳＴＫに対してプッシュされるとＷＰインジケータビットが設定されるため、ステップ３０４及び３０８は、そのようなプッシュされたリターンアドレスの上書きが試みられた場合、障害を生成する。このように、そのような試みがミス（例えば、誤ったＣコード）によるものであるか、或いは、スタックを破壊するための意図的な試み（例えば、ＲＯＰ攻撃）であるかに関わらず、リターンアドレスが上書きされることを許可することによって生じ得る結果、制御、及び／又はセキュリティにおける欠陥又は望まざる変化が回避され、代わりに、障害が生成される。従って、図３に示されていないが、方法３００は、例えば、障害に対する応答に基づいて利用可能な適切な障害ハンドラに分岐し得、その後、方法３００に戻る。
【0025】
要求されたスタックアクセスが書き込み動作であり、書き込まれるべきアドレスに対してＷＰインジケータが設定されていないため到達したステップ３１０は、位置ＳＰＴＲ＜ＳＴＫＡ＞に対して、プッシュ読み出しとして、又は例えば、非プッシュ書き込みの場合等のバッファ書き込みとして、要求された書き込みを実行する。プッシュとして、その書き込みが、別のレジスタから又はプログラムカウンタｌ４ＰＣからのリターンアドレス（又はそのオフセット又は増分）であり、そのため、リターンの際に、次のプロセッサ実行命令がリターンアドレスにある。次に、方法３００はステップ３１２に続く。
【0026】
ステップ３１２は、ステップ３１０書き込みが、スタック２４ＳＴＫに対してリターンアドレスの書き込みを試みることを含むプッシュ動作であるか否かを判定する。しばしば、プッシュ動作は、定義上必ず、スタック（例えば、スタック２４ＳＴＫ）に対して、そのように書き込むことを試みるが、本明細書では、リターンアドレスをプッシュしないプッシュ動作があり得るともみなされる。このように、ステップ３１２に含まれるものには、プッシュがリターンアドレスであるか否かの判定もある。この判定は、例示の実施形態において、例えば、リターンアドレスを保持するために特に用いられるＰＣ又はレジスタ（例えば、ＡＲＭアーキテクチャにおけるＬＲレジスタ）からいつ値が来るかを検出することによって達成され得る。従って、幾つかの例示の実施形態は、これがそのケースであるか否かを判定するために、プロセッサ信号を監視する。一方、例示の実施形態のＡＲＭ実装において、例示の実施形態は、関数において実行される第１の命令が、ＬＲレジスタ値を含む値のプッシュである、コンパイラ規約に依存する。ステップ３１２が、要求された書き込みがプッシュ動作であることを検出した場合、方法３００はステップ３１４で継続し、一方、ステップ３１０が、要求された書き込みがプッシュ動作でないことを検出した場合、方法３００は、ステップ３０２の次のインスタンスに戻る。
【0027】
スタック動作に対する検出された書き込みが、更にプッシュ動作（これは、スタックに対してアドレスを書き込むように試みる）であると検出されたため到達したステップ３１４において、その後、ＷＰ管理ブロック３２は、スタックメモリ位置に対してＷＰインジケータビットを設定する。そのスタックメモリ位置の中に、リターンアドレスが書き込まれる、即ち、現在のスタックアドレスポインタの位置である。図３に、アドレスＳＰＴＲ＜ＳＴＫＡ＞として示され、また、その位置のＷＰインジケータはＷＰ［ＳＰＴＲ＜ＳＴＫＡ＞］として示される。このように、本明細書において、このインジケータビットの設定は、それを１のバイナリ値にアサートすることによるのであり得、それによって、同じそれぞれのアドレスに書き込まれるリターンアドレスＳＴＫＡを示す。ＷＰインジケータが設定されたままである限り、ＳＴＫＡは書き込み保護される。また、ステップ３１４のこのインスタンスが、図２に示されるポイントに関して生じると、設定されたＷＰインジケータは、ＳＰＴＲ＜００＞において最下位ビットをバイナリ１に設定することによって達成され得る。また、他の例示の実施形態において、任意選択的に、命令が、任意のＷＰビットを設定するように許可され得る。それによって、スタック上の任意の対応するアドレスに対する保護を可能にする。いずれにしても、ステップ３１４がＷＰインジケータを設定した後、方法３００は、ステップ３０２の次のインスタンスに戻る。
【0028】
上記の説明から、プッシュ又は何等かの他のタイプの書き込み（例えば、バッファコピー）として、書き込みアクセスが引き起こされた後、ステップ３１０に到達する。また、そのため、ステップ３１２及び３１４の完了時点で、所与のスタックアドレスに対して、有効なリターンアドレスが書き込まれ、そのそれぞれのＷＰインジケータビットが設定されている。もちろん、非プッシュ書き込みの場合も、データは位置ＳＰＴＲ＜ＳＴＫＡ＞に書き込まれるが、そのような書き込まれたデータの場合、ＷＰビットは設定されない。また、異なる例示の実施形態において、ステップ３１４とステップ３１２の順序は逆転される。或いは、それらは、アトミックステップ（atomic step）として同時に起こることもあり得る。その際、スタックに対する書き込みがリターンアドレスである場合、両方が確実に生じることが条件である。実装の観点からみると、実装詳細に依存して、一方が他方より容易であり得る。いずれにしても、両方のステップ（又はリターンアドレスを含まないスタック書き込みの場合は、ステップ３１２のみ）が完了すると、方法３００はステップ３１２からステップ３０２に戻り、それにより次のスタックアクセスを待つ。
【0029】
方法３００の書き込み関連ステップ（図３の右側に示される）を説明したので、ここでは、ステップ３０６で開始する、スタックアクセスが読み出しであるとステップ３０２が判定したときの方法ステップに注目する。ステップ３０６は、読み出しがポップ動作か否かを判定する。ポップ動作とは、即ち、スタック２４ＳＴＫからリターンアドレスを読み出し、ＣＰＵプログラムカウンタｌ４ＰＣに入れることを試みることである。それによって、先のプログラムフローをそのプログラムシーケンスから離れた命令（例えば、分岐）のアドレスに続く次のアドレスに、プログラムフローを復元する。ステップ３０６の判定はまた、プロセッサアーキテクチャに基づいて、或る信号を検出することに応答して行われ得る。ステップ３０６が、要求された読み出しがポップ動作であることを検出した場合、方法３００はステップ３２２で継続する。一方、ステップ３０６が、要求された読み出しがポップ動作ではないことを検出した場合、ステップ３２２がスキップされ、方法３００はステップ３２４で継続する。ポップ動作の検出は、スタックポインタにおける値を監視することによって行われ得る。スタックポインタ値が、スタックの底部に向かって移動されると、前のスタックポインタ値と新規のスタックポインタ値との間の全ての値が、ポップされたものとみなされる。スタック動作からの検出された読み出しがポップ動作として更に検出されたために到達したステップ３２２において、ＷＰ管理ブロック３２は、リターンアドレスが読み出されるスタックメモリ位置、即ち、現在のスタックアドレスポインタ（即ち、ＷＰ［ＳＰＴＲ＜ＳＴＫＡ＞］）の位置、に対するＷＰインジケータビットをクリアする。従って、この明細書において、このビットのクリアは、ビットを０のバイナリ値にデアサートすることによって行われる。ＷＰインジケータをこのように０の値にデアサートすることで、そのアドレスＳＴＫＡが、後に書き込まれると考えられる場合、スタック書き込みと関連する上述のステップ３０４が、クリアされたＷＰインジケータを検出し得、それにより、ステップ３１２に遷移することによって書き込みを許可する。いずれにしても、ステップ３２２の後、方法３００はステップ３２２からステップ３２４まで継続する。
【0030】
ステップ３２４において、要求された読み出しが、ステップ３２２の後のポップ読み出しとして、又はステップ３０６における非ポップ読み出しを見つけたことから直接のバッファ読み出しとして実行される。従って、ポップとして、読み出しは、スタックからのリターンアドレス（又は他の情報）の読み出しであり、現在のスタックアドレスポインタ（即ち、ＳＰＴＲ＜ＳＴＫＡ＞）の位置におけるメモリワードの読み出しである。図示されていないが、読み出しは、別のレジスタに又は直接的にプログラムカウンタｌ４Ｐｃに成され得る。そのため、次のプロセッサ実行命令はリターンアドレスにおける命令となる。従って、ステップ３２２及び３２４の完了時点で、所与のスタックアドレスに対して、有効なリターンアドレスが読み出されており、そのそれぞれのＷＰインジケータビットがクリアされている。もちろん、非ポップ読み出しの場合も、データが位置ＳＰＴＲ＜ＳＴＫＡ＞から読み出され、非ポップ読み出し命令によって示され得るように宛先に提供される。また、ステップ３１４及び３１２の上記の説明と同様に、ステップ３２２とステップ３２４の順序も逆転され得る。その際、スタックからの読み出しがポップを含む場合、両方が確実に起こり、実装が他の実装詳細に依存し得ることが条件である。いずれにしても、ステップ３２２及び３２４が完了すると、次に、方法３００はステップ３２４からステップ３０２に戻り、それにより、次のスタックアクセスを待つ。
【0031】
図４ａから図４ｆは、スタック２４ＳＴＫを示しており、種々のメモリワードにおける表示を用い、またスタックポインタＳＰＴＲの移動を用いて、方法３００の例示のシーケンスを図示している。この第１の例において、プログラミング言語（例えば、Ｃ）が、下記の表１に示されるコードに従って実施することを想定している。
任意の命令の実行の前は、スタック２４ＳＴＫは、図２のケースと同様に表され、スタックポインタＳＰＴＲが、スタック（即ち、ＳＴＫＡ＜００＞）の底部を指し示している。
【表1】
【0032】
次に、表１に従って、第１の命令が「ｈｅｌｌｏ」ルーチンを呼び出す。その場合、対応するアセンブリ言語は、ＬＲレジスタにストアされたプログラムカウンタアドレスをスタック２４ＳＴＫ上にプッシュしようと試みる。このように、試行されたプッシュは、方法３００のステップ３０２において検出されたような、スタックアクセス書き込み試行である。また、試みられた書き込みは、ステップ３０４において確認されたように、クリアされたＷＰインジケータを持つ空のスタック位置に対するものであり、それにより、フローはステップ３１０に進む。ステップ３１０は、更に、書き込みをリターンアドレスのプッシュ（例えば、ＬＲのプッシュ）として確認する。これは、ステップ３１４にＳＴＫ＜００＞でＷＰインジケータを設定するように指示する。その後、ステップ３１２が続き、リターンアドレスがその同じアドレスに対してプッシュされる。この点に関し、図４ｂは、これらのステップ後のスタック２４ＳＴＫを図示する。この場合、ステップ３１４はＳＴＫＡ＜００＞に対するＷＰインジケータビットを１の値に設定しており、ステップ３１２はＬＲデータをＳＴＫＡ＜００＞に書き込んでいる。
【0033】
次に、Ｃ命令「ｕｉｎｔ３２ｔ ｂｕｆ［４］」の結果、スタック２４ＳＴＫにおけるプッシュされたＬＲ値の頂部上に、バッファスペースを予約する。この点に関して、「ｕｉｎｔ３２ｔ ｂｕｆ［４］」の命令は、スタックポインタＳＰＴＲに４の値を付加させる。従って、それは、図４ｂにおけるＳＴＫＡ＜００＞から図４ｃにおけるＳＴＫＡ＜０４＞に進んだものとして、図４ｃに示される。
【0034】
次に、Ｃ命令「ｍｅｍｃｐｙ（ｂｕｆ，ｒｘ＿ｂｕｆ，ｌｅｎ）；」は、変数ｒｘ ｂｕｆ；によって設定された長さを持つワードのバッファを、別のメモリから、スタック２４ＳＴＫに対してコピーする。従って、現在の例において、そのｒｘ＿ｂｕｆは、４ワードを持つように定義されており、そのため、それらの４ワードの各々が、スタック２４ＳＴＫに書き込まれる。このように、各書き込みは、再び、方法３００のステップ３０２によって検出される、スタックに対するアクセスの試みを表す。例えば、第１の書き込みに対して、ステップ３１０は、第１に、問題となっているＳＴＫＡアドレス（即ち、ＳＴＫＡ＜０４＞）のＷＰインジケータビットが設定されているか否かをチェックする。現在の例では、ＷＰデータは設定されていないため、次のステップ３０４は、書き込みがプッシュではないと判定し、その後、ステップ３１２は、図４ｄに示されるように、書き込みを実施する。メモリからスタック２４ＳＴＫにコピーされるべき残りの３ワードの各々に対しても同じプロセスが繰り返され、従って、ステップ３０４、３１０、及び３１２の３回以上の繰り返しの完了時点で、スタック２４ＳＴＫは、図４ｅに示されるようになる。また、この文脈において、ｒｘ＿ｂｕｆｆアクセスに対して用いられるアドレスは、スタックポインタとは別個に追跡されるため、バッファへの書き込みごとにスタックポインタは移動せず、従って、ＳＰＴＲは、ＳＴＫＡ＜０４＞を指し示しているように示される。
【0035】
上述のように、バッファデータは、スタック２４ＳＴＫに成功裏にストアされており、そのルーチンの間、所望に応じて迅速かつ容易にアクセスされ得る。表１に示されるように、Ｃ言語「ｒｅｔｕｒｎ；」命令によって示されるように、最終的に、ルーチンが完了する。その命令に応答して、－４の値がスタックポインタＳＰＴＲに付加され、それによってそれをアドレスＳＴＫＡ＜００＞に配置し、従って、図４ｆに示されるように、ＬＲリターンアドレスを指し示す。次に、アセンブリ言語ＰＯＰ命令によって、そのアドレスから読み出しが求められ。方法３００のステップ３０６、３２２、及び３２４を再び呼び出す。従って、ステップ３２２において、以前に設定されたＷＰインジケータビットがクリアされ、ステップ３２４において、図４ｆに示すように、アドレスＳＴＫＡ＜００＞におけるＬＲ値が読み出され、そこから、その値がプロセッサのプログラムカウンタｌ４ＰＣに戻され、その結果、次に実行された命令が、リターンアドレスにあり、それによって、ルーチンコールに続く命令に実行を適切に戻す。
【0036】
図４ａ～図４ｆの上述の例は、リターンアドレスのスタック２４ＳＴＫへの成功裏のプッシュ及びポップを図示しているが、ここで、例示の実施形態によって提供されるように、保護的態様が評価される付加的な例を説明する。具体的には、図４ｄ及び図４ｅに示されるように、上記の例は、変数ｒｘ＿ｂｕｆｆ；によってパスされるように、バッファ長が４ワードであることを想定している。しかしながら、ここでは、ミスによって又は意図的なハッキング操作によって変数ｒｘ＿ｂｕｆｆが５又はそれ以上（例えば、８ワード、その場合ｒｘ＿ｂｕｆｆ［８］）であることを想定する。図４ｅを参照すると、第１の４ワードの各々がスタック２４ＳＴＫにコピーされた後、次に試みられた書き込み、即ち、ｒｘ＿ｂｕｆｆ［５］が、ＳＴＫＡ＜００＞にある。この試みられた書き込みは、方法３００のステップ３０２によって、まず検出され、その後、ステップ３０４がＳＴＫＡ＜００＞におけるＷＰインジケータビットが設定されていることを判定する。図４ｅに示される例において、ステップ３０４の条件は肯定的であり、即ち、その位置に対してＷＰインジケータビットが設定されている。その結果、方法３００はステップ３０８に続き、障害が生成される。また、障害生成の一部として又は障害生成に加えて、設定されたＷＰインジケータビットに応答して、書き込みがブロックされる。従って、例示の実施形態において、障害生成の一部（又は、障害生成に加えて、又は障害生成の代わり）が、ＳＴＫＡ＜００＞におけるストアされたリターンアドレスを上書きするためのＣ言語の取り組みを妨害する。それによって、スタックの「スマッシング（smashing）」を回避する。従って、スタック２４ＳＴＫへのその後のリターンがある場合、適切なリターンアドレスが維持され、正規のスタック位置のリターンアドレス以外のアドレスにジャンプ又はトランジションする能力はない。確かに、バッファをコピーする上記の例は、１つの可能なアプローチにすぎないが、全ての事象において、スタックに対するリターンアドレスのプッシュの、より早期の検出は、それぞれの設定されたＷＰインジケータビットによって、その後の上書きから保護される。それは、そのアドレスのその後のポップがないこと、及びその後のポップがあるまでを条件とする。その場合、それぞれの設定されたＷＰインジケータビットはクリアされる。
【0037】
図５は、図２のブロックを再び示すが、参照をスタック２４’ＳＴＫとして区別して示されるスタックの代替の例示の実施形態を備える。スタック２４ＳＴＫと同様に、２４’ＳＴＫは、アドレスデータが書き込まれ得る各アドレス位置に対するＷＰインジケータビットを含むが、各ワードに付加的なビットを添付するのではなく、ＷＰインジケータビットの集合が単一のメモリ位置にストアされる。それは、スタックの近くのどこかのメモリ位置であり得、従って、例として、スタックアドレス＜００＞の２つ下の位置のアドレスで示され、そのため、アドレス＜００－２＞として示される。或いは、別の例において、単一のＷＰストアワードがスタックワードの１つであり得、そこでは、付加的なワードそれ自体が、保護される場合と保護されない場合がある。また、スタック２４’ＳＴＫにおける各メモリワードは、スタック２４ＳＴＫの場合と同じように、付加的なビットを含まないため、図５における各ワードは、２４ＳＴＫの３３ビットではなく、３２ビット幅である。更に、単一のメモリワードが、従って、合計３２のＷＰインジケータビットをサポートし得るため、各異なるＷＰインジケータビットは、スタック２４’ＳＴＫのそれぞれの異なるメモリ位置に対応することが好ましい。従って、その場合、例えば、ＳＴＫＡ＜００－２＞における最下位ビットは、ＳＴＫＡ＜００＞における最下位スタックワードに対するＷＰインジケータビットを表す。同様に、ＳＴＫＡ＜００＞におけるより上位の各ビットは、ＳＴＫＡ＜００＞の上の次の最上位スタックワードに対するＷＰインジケータビットを表す。下記の表２に示されるように、ＳＴＫＡ＜００－２＞における各ＷＰインジケータビットを、それぞれのワードに対してマッピングする。
最後に、図５において、ＢＯＶＰ回路１８ＢＯＶＰのＷＰ管理ブロック３２が、アドレス＜００－２＞におけるワードのみにアクセスするように結合されて示されている。それは、そのワードが、ＷＰインジケータビットに関して読み出し／書き込みを行うワードであるからである。このように、方法３００における種々のステップに一致して、ＷＰ管理ブロック３２は、アドレス＜００－２＞におけるワードの各ビットを、例えば、全体のワードを読み出し、次に、その中のビットを読み出すか又はその中にビットを書き込む（後者の場合、その後、変更されたビットを含む、全体のワードをアドレス＜００－２＞に戻して書き込む。）ことなどによって、読み出し又は書き込み得る。
【表2】
【0038】
図６は、内部メモリ２４及びＷＰ管理ブロック３２の別の例示の実施形態の実装の電気的及び機能的ブロック図を示す。これらのブロックの各々を下記に説明する。
【0039】
最初に内部メモリ２４を見ると、デバイス（例えば、プロセッサ）が自身のメモリスペースに１つ以上のスタックを含み得ることを表すように、スタック２４”ＳＴＫＳが示されている。このように、図５は、３２のアドレス／バッファワード及び１つのＷＰインジケータワードを含むＲ／Ｗメモリスペースの単一のブロックを図示するが、図６は、それぞれのＷＰインジケータスペースを持つ各ブロックを備える、複数（例えば、３個）のスタックブロックを提供する。図示されたアプローチにおいて、特定のサイズは提供されていないが、代替の例示の実施形態において、スタックサイズは変化し得、従って、各スタックに対応するＷＰビットも変化し得る。このように、一例において、各スタックは３２ワードであり得、各ＷＰビットスペースは３２ビットであり得るが、他の変形において、スタックサイズが全て同じで、３２ワード以外であり得る。或いは、１つ又は複数が他とは異なり得、従って、それぞれのＷＰビットを収容するために必要なスペースも異なり得る。従って、この点に関して、図６の一般性は、代替の例示の実施形態の広さを示すことが意図され、所与のスタックに対するＷＰビット（又は他のインジケータ）は、スタック内以外の任意の場所にストアされ得るので、全てのスタックの下にストアされる必要がない。従って、ＷＰビットは、スタック間（例えば、図６のスタック１とスタック２の間、又は、スタック２とスタック３の間）、全てのスタックの前、全てのスタックの後、又は、完全に他の何らかのメモリエリア内に、配置され得る。
【0040】
また、図６において、ＷＰ管理ブロック３２は、ＷＰキャッシュ３２Ｃを含むように示される。ＷＰキャッシュ３２Ｃは、キャッシュメモリ３２ＣＭ及びキャッシュコントロール３２ＣＣを更に含む。キャッシュメモリ３２ＣＭは、スタックアドレスＳＴＫＡを受け取るように結合される。方法３００の上述の説明に一致して、スタックアドレスＳＴＫＡに対して書き込みが所望されるか或いはスタックアドレスＳＴＫＡから読み出しが所望される。キャッシュメモリ３２ＣＭはまた、スタック２４”ＳＴＫＳに対応するＷＰデータに結合される。従って、ＷＰインジケータビットのメモリワードは、既知の原則に従って、スタックスペース２４”ＳＴＫＳからキャッシュメモリ３２ＣＭにフェッチされ得る。このように、スタックアドレスＳＴＫＡが受け取られたときに、ＳＴＫＡに対応する特定のＷＰインジケータビットを含む求められる（sought）ＷＰデータワード（例えば、ＷＰインジケータの３２ビット）が既にキャッシュメモリ３２ＣＭにある場合、キャッシュヒットが生じ、そのデータは、方法３００に従った処理（即ち、読み出しか又は書き込み）に直ちに利用可能である。これとは反対に、スタックアドレスＳＴＫＡが受け取られたときに、ＳＴＫＡに対応する特定のＷＰインジケータビットを含む求められるＷＰインジケータワードがキャッシュメモリ３２ＣＭ内にない場合、キャッシュミスが生じ、そのデータは、スタックスペース２４”ＳＴＫＳからキャッシュメモリ３２ＣＭにリトリーブされ、その後、処理に利用可能である。従って、このようにして、３２ビットアドレス指定の例の場合、アドレスの最下位５ビットがキャッシュアクセスに対するオフセットを提供し、最上位２７ビットがキャッシュタグを提供する。
【0041】
幾つかのプロセッサが、複数のスタックを同時にサポートする。例えば、プロセッサは、２つのスタックポインタを提供し得、一方はオペレーティングシステムによる使用が意図され、他方はアプリケーション（１つの例は、幾つかのＡＲＭプロセッサにおけるＭＳＰ及びＰＳＰスタックポインタである）による使用が意図される。別の例示の実施形態は、プロセッサがサポートする全ての同時スタックに対するカバレッジを提供する。この実施形態において、ＷＰビットは、ＳＰＩＤ：ＷＰによって表される複数のビットに拡張される。ここで、ＳＰＩＤは、プロセッサにおける各スタックポインタに対する値を一意にエンコードするために充分大きいビットのセットであり、ＷＰは書き込み保護ビットである。プロセッサにおける実行の間、プロセッサは、どのスタックポインタがアクティブかを追跡する。ＷＰ管理ブロック３２は、どのスタックポインタが使用中であるかを判定するために、プロセッサからの信号を監視する。アドレスに対してＷＰビットを書き込むと、ＳＰＩＤもまた、ＷＰ管理ブロック３２によって書き込まれる。ＷＰ管理ブロック３２が、アドレスがポップされたとのプロセッサからの指示を有するとき、現在アクティブなスタックポインタが、そのアドレスに対してストアされたＳＰＩＤビットに一致する場合にのみ、ＷＰ管理ブロック３２は、そのアドレスに対するＳＰＩＤ及びＷＰビットをクリアする。また、ＷＰ管理ブロック３２は、監視されている各スタックポインタに対するイネーブル／ディセーブル信号を提供する。また、ＷＰ管理ブロック３２は、メモリ内のどこにそのスタックに対するＷＰビットをストアするかを設定するために、監視されている各スタックポインタに対して構成レジスタを提供する。プロセッサが或るモード（特権モード等）でない限り、イネーブル／ディセーブル信号メモリの変更はブロックされ得る。オペレーションシステムがスレッド切り替えを行っている間、イネーブル／ディセーブル信号は、構成レジスタとともに、オペレーティングシステムに、スレッド／アプリケーションによって用いられているスタックの監視を停止させる。オペレーティングシステムは、スタックポインタＡに対する監視をディセーブルし得、メモリにおけるＷＰビットの位置をスタックポインタＡに対する構成レジスタに書き込み得、スタックポインタＡの値を、オペレーティングシステムが実行しようとしているスレッドに対する適切な値に変更し得、その後、スタックポインタＡに対する監視を再びイネーブルし得る。動作のこのシーケンスは、ＷＰ管理ブロックのポップ検出ロジックをトリガするリスクなしに、スレッド切り替え（スタックポインタにおける値の変更）を生じさせる。
【0042】
上記から、例示の実施形態は、スタックバッファオーバーフローから保護するためのハードウェアサポートを備える改善されたプロセッサを提供する。結果として、例示の実施形態プロセッサは、望ましくない又は悪意あるスタック動作を起こし得る、コーディングエラー又は意図的な攻撃の影響を受けにくい。また、これらのハードウェア態様は、ソースコードの再コンパイルを回避することやテスト及び実行時間オーバーヘッドの双方を低減すること等、ソフトウェアベースの技法に比べて時間オーバーヘッドを低減する。例示の実施形態はまた、保護的ソフトウェアの必要性を軽減すること、及び、例示の実施形態によって低減される懸念に対処するために必要となるであろうアーキテクチャのより深い理解の必要性を低減することの両方において、ソフトウェア開発者の負担をなくす。このように、例示の実施形態は多くの利点を有することが示されており、種々の実施形態が提供されてきた。更にその他の利点として、例示の実施形態は、種々の代替が考えられ、それらの幾つかは、他のものと共に上記で説明してきた。例えば、例示の実施形態は、３２ビットワードアーキテクチャの文脈において説明されてきたが、例示の実施形態は、他のワード長アーキテクチャにも適用され得る。別の例として、スタックＷＰインジケータビットがスタックにストアされている及び／又はキャッシュされている例が示されているが、ビット、フラグ、又は、複数ビットを含む保護的インジケータ間のその他の関連、及びそれらのビットの（例えば、ロジックＡＮＤ、ＯＲ等を介する）互いとのあり得る関係、又は他の条件がなされ得、そのため、プログラムカウンタアドレスがストアされる（例えば、プッシュされる）それぞれのスタック位置をハードウェア保護する。それによって、そのようなアドレスの、タイミングが適切でない又は悪意的な上書きの可能性を低減する。更に別の例として、或る例示の実施形態において、ＷＰビットは、書き込み保護されたスペースへの書き込みを防止するが、代替の例示の実施形態では、書き込みが起こり得、その後検出され得る。そのため、上書きされたデータは回復可能ではないが、障害が生成されて、上書きされたデータはエラーのあるターゲットアドレスとして使用が許可されない。さらに別の例において、例示の実施形態が、スタックの一部として書き込み保護のため監視されているメモリアドレスを調整するために、ＣＰＵで（例えば、ＣＰＵが特権状態にある間に）命令を実行させる能力を含み得る。例えば、リアルタイムオペレーションシステム（ＲＴＯＳ）を実行する場合、複数のスタックが用いられ、また、例示の実施形態がＣＰＵのスタックポインタレジスタに対する変更を監視する間、ＲＴＯＳがスタックをスワップすると、その変更はプッシュ又はポップとして解釈されないことが好ましく、従って、図３に示されるもの等の、例示の実施形態の方法における、引き起こす条件である
【0043】
特許請求の範囲内で、説明した実施形態における変更が可能であり、他の実施形態が可能である。
【図1】
【図2】
【図3】
【図4a】
【図4b】
【図4c】
【図4d】
【図4e】
【図4f】
【図5】
【図6】