特許 6899614 ハードウェア管理スタック・アーキテクチャにおける呼び出し元により保護されるスタック・リターンアドレス

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6899614

(24)【登録日】2021年6月17日

(45)【発行日】2021年7月7日

(54)【発明の名称】ハードウェア管理スタック・アーキテクチャにおける呼び出し元により保護されるスタック・リターンアドレス

(51)【国際特許分類】

   G06F 9/32 20060101AFI20210628BHJP

   G06F 9/30 20180101ALI20210628BHJP

   G06F 9/34 20060101ALI20210628BHJP

   G06F 21/60 20130101ALI20210628BHJP

   G06F 21/52 20130101ALI20210628BHJP

【ＦＩ】

   G06F9/32 384C

   G06F9/30 387

   G06F9/30 350A

   G06F9/34 340C

   G06F21/60

   G06F21/52

【請求項の数】20

【全頁数】37

(21)【出願番号】特願2018-534638(P2018-534638)

(86)(22)【出願日】2016年12月23日

(65)【公表番号】特表2019-506666(P2019-506666A)

(43)【公表日】2019年3月7日

(86)【国際出願番号】IB2016057979

(87)【国際公開番号】WO2017118893

(87)【国際公開日】20170713

【審査請求日】2019年5月13日

(31)【優先権主張番号】14/989,397

(32)【優先日】2016年1月6日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】390009531

【氏名又は名称】インターナショナル・ビジネス・マシーンズ・コーポレーション

【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ

(74)【代理人】

【識別番号】100108501

【弁理士】

【氏名又は名称】上野 剛史

(74)【代理人】

【識別番号】100112690

【弁理士】

【氏名又は名称】太佐 種一

(72)【発明者】

【氏名】グシュビント、マイケル、カール

(72)【発明者】

【氏名】デュヴァルサント、カール

(72)【発明者】

【氏名】サラプラ、ヴァレンティーナ

【審査官】 三坂 敏夫

(56)【参考文献】

【文献】 米国特許出願公開第２０１４／００９６２４７（ＵＳ，Ａ１）

【文献】 特開２００１−２１６１６１（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１４／０２８３０８８（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１３／００１３９６５（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／３０−９／３５５

Ｇ０６Ｆ ２１／１０−２１／１６

Ｇ０６Ｆ ２１／５０−２１／８８

Ｇ０６Ｆ １２／１４

(57)【特許請求の範囲】

【請求項1】

コンピューティング環境のスタックの破損を検出するためのコンピュータ・プログラムであって、前記コンピュータ・プログラムは、処理回路に対し、
呼び出し側ルーチンに随伴し、リターンアドレスを保護するためのガードワード保護の使用をサポートすることを示すインジケータを提供することと、
ガードワード保護の使用をサポートしていると前記インジケータが示すことに基づいて、前記呼び出し側ルーチンによる呼び出されたルーチンの呼び出しに際して、ハードウェア命令により、ガードワードを前記呼び出し側ルーチンのスタックに格納することであって、前記ガードワードは、前記スタックに格納されるリターンアドレスを保護するためのものである、前記格納することと、
前記呼び出し側ルーチンがガードワード保護の使用をサポートしていると前記インジケータが示すことに基づいて、前記コンピューティング環境のプロセッサ上で実行される前記呼び出されたルーチンにおいて、前記呼び出し側ルーチンのスタックに格納されたガードワードをチェックすることと、
前記チェックに基づいて、前記ガードワードが予想される値を有するかどうかを判断することと、
前記ガードワードが予想しない値を有すると判断することに基づいて、前記スタックの
破損の表示を提供することと、
を実行させる、コンピュータ・プログラム。

【請求項2】

前記チェック及び判断は、前記呼び出されたルーチンにより発行される命令を介して実行される、請求項１に記載のコンピュータ・プログラム。

【請求項3】

前記コンピュータ・プログラムを実行することにより前記処理回路が実現する方法は、
前記スタックから前記ガードワードを取得することと、
前記ガードワードがもはや前記スタック上において見えないように、前記スタックのスタック・ポインタを移動させることと、
前記判断、前記チェック、及び前記表示を提供することの１つ又は複数を実行することと、
を含む、請求項２に記載のコンピュータ・プログラム。

【請求項4】

前記方法は、
前記リターンアドレスを保護するために、前記呼び出し側ルーチンが前記ガードワードの使用をサポートするかどうかを判断することと、
前記呼び出し側ルーチンが前記ガードワードの使用をサポートすることに基づいて、前記取得すること、前記移動させること、及び前記実行することを実行することと、
をさらに含む、請求項３に記載のコンピュータ・プログラム。

【請求項5】

前記コンピュータ・プログラムは、前記ガードワードについてのアドレスを指定するｓｔｏｒｅ ｇｕａｒｄ ｗｏｒｄ命令を用いて、前記ガードワードを提供することを実行させる、請求項１に記載のコンピュータ・プログラム。

【請求項6】

前記コンピュータ・プログラムを実行することにより前記処理回路が実現する方法は、
ガードワード命令を用いて前記ガードワードを提供することと、
前記リターンアドレスを保護するために、前記呼び出し側ルーチンが前記ガードワードの使用をサポートすることを示すようにインジケータを設定することと、
をさらに含む、請求項１に記載のコンピュータ・プログラム。

【請求項7】

前記コンピュータ・プログラムを実行することにより前記処理回路が実現する方法は、
前記リターンアドレスを保護するために、前記呼び出し側ルーチン及び前記呼び出されたルーチンが前記ガードワードの使用をサポートするかどうかを判断することと、
前記リターンアドレスを保護するために、前記呼び出し側ルーチン及び前記呼び出されたルーチンが前記ガードワードの使用をサポートすると判断することに基づいて、前記チェック、前記判断、及び前記表示を提供することの１つ又は複数を実行することと、
をさらに含む、請求項１に記載のコンピュータ・プログラム。

【請求項8】

前記コンピュータ・プログラムを実行することにより前記処理回路が実現する方法は、
前記呼び出し側ルーチン及び前記呼び出されたルーチンの少なくとも１つのルーチンが、前記リターンアドレスを保護するための前記ガードワードの使用をサポートしないと判断することに基づいて、前記チェックすることと、前記判断をすることと、前記表示を提供することのいずれも行わないことをさらに含む、請求項７に記載のコンピュータ・プログラム。

【請求項9】

前記リターンアドレスを保護するために、前記呼び出し側ルーチン及び前記呼び出されたルーチンが前記ガードワードの使用をサポートするかどうかを判断することは、少なくとも１つのインジケータをチェックすることを含む、請求項７に記載のコンピュータ・プログラム。

【請求項10】

前記少なくとも１つのインジケータは、前記インジケータのベクトル内に格納される、請求項９に記載のコンピュータ・プログラム。

【請求項11】

コンピューティング環境のスタックの破損を検出するためのコンピュータ・システムであって、前記コンピュータ・システムは、
メモリと、
前記メモリと通信するプロセッサと、
を含み、前記コンピュータ・システムは、
呼び出し側ルーチンに随伴し、リターンアドレスを保護するためのガードワード保護の使用をサポートすることを示すインジケータを提供することと、
ガードワード保護の使用をサポートしていると前記インジケータが示すことに基づいて、前記呼び出し側ルーチンによる呼び出されたルーチンの呼び出しに際して、ハードウェア命令により、ガードワードを前記呼び出し側ルーチンのスタックに格納することであって、前記ガードワードは、前記スタックに格納されるリターンアドレスを保護するためのものである、前記格納することと、
前記呼び出し側ルーチンがガードワード保護の使用をサポートしていると前記インジケータが示すことに基づいて、前記コンピューティング環境のプロセッサ上で実行される前記呼び出されたルーチンにおいて、前記呼び出し側ルーチンのスタックに格納されたガードワードをチェックすることと、
前記チェックに基づいて、前記ガードワードが予想される値を有するかどうかを判断することと、
前記ガードワードが予想しない値を有すると判断することに基づいて、前記スタックの
破損の表示を提供することと、
を実行する、コンピュータ・システム。

【請求項12】

前記チェック及び判断は、前記呼び出されたルーチンにより発行される命令を介して実行され、
前記スタックから前記ガードワードを取得することと、
前記ガードワードがもはや前記スタック上において見えないように、前記スタックのスタック・ポインタを移動させることと、
前記判断、前記チェック、及び前記表示を提供することの１つ又は複数を実行することと、
を実行する、請求項１１に記載のコンピュータ・システム。

【請求項13】

前記ガードワードについてのアドレスを指定するガードワード命令を用いて、前記ガードワードを提供する、請求項１１に記載のコンピュータ・システム。

【請求項14】

前記コンピュータ・システムが実現する方法は、
ガードワード命令を用いて前記ガードワードを提供することと、
前記リターンアドレスを保護するために、前記呼び出し側ルーチンが前記ガードワードの使用をサポートすることを示すようにインジケータを設定することと、
を含む、請求項１１に記載のコンピュータ・システム。

【請求項15】

前記コンピュータ・システムが実現する方法は、
前記リターンアドレスを保護するために、前記呼び出し側ルーチン及び前記呼び出されたルーチンが前記ガードワードの使用をサポートするかどうかを判断することと、
前記リターンアドレスを保護するために、前記呼び出し側ルーチン及び前記呼び出されたルーチンが前記ガードワードの使用をサポートすると判断することに基づいて、前記チェック、前記判断、及び前記表示を提供することの１つ又は複数を実行することと、
を含む、請求項１１に記載のコンピュータ・システム。

【請求項16】

コンピューティング環境のスタックの破損を検出するコンピュータ実施方法であって、前記コンピュータ実施方法は、コンピュータに対し、
呼び出し側ルーチンに随伴し、リターンアドレスを保護するためのガードワード保護の使用をサポートすることを示すインジケータを提供することと、
ガードワード保護の使用をサポートしていると前記インジケータが示すことに基づいて、前記呼び出し側ルーチンによる呼び出されたルーチンの呼び出しに際して、ハードウェア命令により、ガードワードを前記呼び出し側ルーチンのスタックに格納することであって、前記ガードワードは、前記スタックに格納されるリターンアドレスを保護するためのものである、前記格納することと、
前記呼び出し側ルーチンがガードワード保護の使用をサポートしていると前記インジケータが示すことに基づいて、前記コンピューティング環境のプロセッサ上で実行される前記呼び出されたルーチンにおいて、前記呼び出し側ルーチンのスタックに格納されたガードワードをチェックすることと、
前記チェックに基づいて、前記ガードワードが予想される値を有するかどうかを判断することと、
前記ガードワードが予想しない値を有すると判断することに基づいて、前記スタックの
破損の表示を提供することと、
を実行させる、コンピュータ実施方法。

【請求項17】

前記チェック及び判断は、前記呼び出されたルーチンにより発行される命令を介して実行され、
前記スタックから前記ガードワードを取得することと、
前記ガードワードがもはや前記スタック上において見えないように、前記スタックのスタック・ポインタを移動させることと、
前記判断、前記チェック、及び前記表示を提供することの１つ又は複数を実行することと、
を含む、請求項１６に記載のコンピュータ実施方法。

【請求項18】

前記ガードワードについてのアドレスを指定するｓｔｏｒｅ ｇｕａｒｄ ｗｏｒｄ命令を用いて、前記ガードワードを提供する、請求項１６に記載のコンピュータ実施方法。

【請求項19】

ガードワード命令を用いて前記ガードワードを提供することと、
前記リターンアドレスを保護するために、前記呼び出し側ルーチンが前記ガードワードの使用をサポートすることを示すようにインジケータを設定することと、
をさらに含む、請求項１６に記載のコンピュータ実施方法。

【請求項20】

前記リターンアドレスを保護するために、前記呼び出し側ルーチン及び前記呼び出されたルーチンが前記ガードワードの使用をサポートするかどうかを判断することと、
前記リターンアドレスを保護するために、前記呼び出し側ルーチン及び前記呼び出されたルーチンが前記ガードワードの使用をサポートすると判断することに基づいて、前記チェック、前記判断、及び前記表示を提供することの１つ又は複数を実行することと、
をさらに含む、請求項１６に記載のコンピュータ実施方法。

【発明の詳細な説明】

【技術分野】

【0001】

１つ又は複数の態様は、一般に、コンピューティング環境内の処理に関し、特定的には、コンピューティング環境のデータの保護に関する。

【背景技術】

【0002】

コンピュータ・プログラムの破損は、様々な形で起こり得る。１つのそうした形は、プログラムに、予想しないタスク又はアドレスへのリターンを実行させるデータの上書きである。この破損は、悪意のないことも又は悪意のあることもある。特定の例として、コンピュータ・プログラムのアクティブ・サブルーチンについての情報を格納するために、コンピュータ・プログラムにより使用されるコールスタック（スタックとも呼ばれる）において、破損が起こり得る。例えば、スタックは、ルーチンが実行を終えたとき、アクティブ・サブルーチンが制御を戻すべきポイント（すなわち、リターンアドレス）を常時監視するために使用される。アクティブ・サブルーチンは、呼び出されたが、実行を完了していないサブルーチンである。こうしたサブルーチンのアクティブ化を任意のレベルにネスト化すること（特例として再帰的）、従って、スタック構造とすることができる。リターンアドレスの上書きによりスタックが破損し、それにより呼び出されたサブルーチンが予想しない位置に戻されることがある。

【0003】

また、リターンアドレスの上書きは、悪意のないことも又は悪意のあることもあるが、それに関係なく、プログラム又は他のデータが破損しないように、リターンアドレスの上書きを検出し、これに備えるべきである。

【先行技術文献】

【非特許文献】

【0004】

【非特許文献1】「ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅ Ｐｒｉｎｃｉｐｌｅｓ ｏｆ Ｏｐｅｒａｔｉｏｎ」、ＩＢＭ刊行物、Ｎｏ．ＳＡ２２−７８３２−１０、２０１５年３月

【発明の概要】

【発明が解決しようとする課題】

【0005】

コンピューティング環境のスタックの破損を検出するためのコンピュータ・プログラム、コンピュータ・システム、及びコンピュータ実施方法を提供する。

【課題を解決するための手段】

【0006】

コンピューティング環境のスタック破損（stack corruption）を検出するためのコンピュータ・プログラム製品を提供することにより、従来技術の欠点が克服され、付加的な利点が与えられる。コンピュータ・プログラム製品は、処理回路により読み取り可能であり、かつ、方法を実施するための処理回路により実行される命令を格納するコンピュータ可読ストレージ媒体を含む。方法は、例えば、コンピューティング環境のプロセッサ上で実行される呼び出されたルーチンにより、呼び出し側（calling）ルーチンにより提供されるガードワード（guard word）をチェックすることであって、呼び出し側ルーチンは、呼び出された（called）ルーチンを呼び出しており、ガードワードは、呼び出し側ルーチンのスタック内に格納され、ハードウェア命令によりスタック内に直接格納されるリターンアドレスを保護する、チェックすることと、チェックすることに基づいて、ガードワードが予想される値を有するかどうかを判断することと、ガードワードが予想しない値を有すると判断することに基づいて、スタックの破損の表示を提供することと、を含む。このことは、呼び出し元（caller）が、１又は複数の呼び出し先（callee）によりチェックされる１つのガードワードを提供することを可能にする。

【0007】

一実施形態において、少なくともチェックすること及び判断することは、呼び出されたルーチンにより発行される命令を介して実行される。一例として、命令を実行し、実行することは、スタックからガードワードを取得することと、ガードワードがもはやスタック上に見えないように、スタックのスタック・ポインタを移動させることと、判断すること、チェックすること及び表示を提供することの１つ又は複数を実行することと、を含む。

【0008】

更に別の例において、実行することは、リターンアドレスを保護するために、呼び出し側ルーチンがガードワードの使用をサポートするかどうかを判断することと、呼び出し側ルーチンがガードワードの使用をサポートすることに基づいて、取得すること、移動させること、及び実行することを実行することと、を含む。

【0009】

一例として、ガードワードについてのアドレスを指定するｓｔｏｒｅ ｇｕａｒｄ ｗｏｒｄ（ガードワード・ストア）命令を用いて、ガードワードが提供される。一態様において、リターンアドレスを保護するために、呼び出し側ルーチンがガードワードの使用をサポートすることを示すように、インジケータが設定される。

【0010】

更に別の態様において、リターンアドレスを保護するために、呼び出し側ルーチン及び呼び出されたルーチンがガードワードの使用をサポートするかどうかを判断する。リターンアドレスを保護するために、呼び出し側ルーチン及び呼び出されたルーチンがガードワードの使用をサポートすると判断することに基づいて、チェックすること、判断すること、及び表示を提供することの１つ又は複数を実行する。

【0011】

一例において、リターンアドレスを保護するために、呼び出し側ルーチン及び呼び出されたルーチンの少なくとも一方のルーチンがガードワードの使用をサポートしないと判断することに基づいて、チェックすることの前に処理を終了する。このことは、システム性能を向上させ得る。

【0012】

一態様において、リターンアドレスを保護するために、呼び出し側ルーチン及び呼び出されたルーチンがガードワードの使用をサポートするかどうかを判断することは、少なくとも１つのインジケータをチェックすることを含む。一例として、少なくとも１つのインジケータが、インジケータのベクトル内に格納される。
１つ又は複数の態様に関連するコンピュータ実装方法及びシステムも、本明細書で説明され、特許請求される。さらに、１つ又は複数の態様に関連するサービスも、本明細書で説明され、特許請求され得る。

【0013】

本明細書で説明される技術を通じて、付加的な特徴及び利点が実現される。他の実施形態及び態様は、本明細書で詳細に説明され、特許請求の範囲の態様の一部と見なされる。
１つ又は複数の態様が、本明細書の最後にある特許請求の範囲において、例として具体的に示され、明確に特許請求されている。上記及び他の目的、特徴、並びに利点は、添付図面と関連して用いられる以下の詳細な説明から明らかである。

【図面の簡単な説明】

【0014】

【図1】本発明の１つ又は複数の態様を組み込み及び／又は用いるためのコンピューティング環境のコンピュータ・システム／サーバの一例を示す。

【図2】本発明の１つ又は複数の態様を組み込み及び／又は用いるためのコンピューティング環境の別の例を示す。

【図3】図２のメモリのさらなる詳細を示す。

【図4】本発明の態様に従って用いられるスタックの一例を示す。

【図5】バッファ・オーバーフローの一例を示す。

【図6】本発明の態様に従って用いられるスタックフレーム及びガードワードの例を示す。

【図7】本発明の態様に従って用いられるスタックフレーム及びガードワードの例を示す。

【図8】本発明の態様に従って用いられるスタックフレーム及びガードワードの例を示す。

【図9】本発明の態様に従って用いられるスタックフレーム及びガードワードの例を示す。

【図10】本発明の態様に従って用いられるスタックフレーム及びガードワードの例を示す。

【図11】本発明の態様による、スタックの破損を検出するための論理の一実施形態を示す。

【図12】本発明の態様による、スタックの破損を検出するための論理の一実施形態を示す。

【図13】本発明の態様による、Ｓｔｏｒｅ Ｇｕａｒｄ Ｗｏｒｄ命令の一例を示す。

【図14】本発明の態様による、ガードワード・レジスタの一例を示す。

【図15】本発明の態様による、ＰＯＰＣＨＥＣＫ命令の一例を示す。

【図16】本発明の態様による、静的リンカの論理の一例を示す。

【図17】本発明の態様による、動的リンカの論理の一例を示す。

【図18】本発明の態様による、Ｓｔｏｒｅ Ｇｕａｒｄ Ｗｏｒｄ Ｃｏｎｄｉｔｉｏｎａｌ（条件付きガードワード・ストア）命令の論理の一例を示す。

【図19】本発明の態様による、ＰＯＰＣＨＥＣＫ Ｃｏｎｄｉｔｉｏｎａｌ（条件付きＰＯＰＣＨＥＣＫ）命令の論理の一例を示す。

【図20】本発明の態様に従って用いられるインジケータのイネーブル・ベクトルの一例を示す。

【図21】本発明の態様による、Ｓｔｏｒｅ Ｇｕａｒｄ Ｗｏｒｄ Ｃｏｎｄｉｔｉｏｎａｌ命令の論理の別の例を示す。

【図22】本発明の態様による、ＰＯＰＣＨＥＣＫ Ｃｏｎｄｉｔｉｏｎａｌ（条件付きＰＯＰＣＨＥＣＫ）命令の論理の別の例を示す。

【図23】本発明の態様による、スタックの破損の検出に関連する論理の一例を示す。

【図24】本発明の態様による、スタックの破損の検出に関連する論理の一例を示す。

【図25】クラウド・コンピューティング環境の一実施形態を示す。

【図26】抽象化モデル層の一例を示す。

【発明を実施するための形態】

【0015】

１つ又は複数の態様は、ガードワードを用いてコールスタックを保護することに関する。ガードワードは、コールスタック内に含まれ、１つ又は複数の呼び出されたルーチンによりチェックされる。チェックすることが、ガードワードが予想されるものとは異なる（すなわち、変更された）ことを示す場合、スタック破損の表示が提供される。

【0016】

一例において、悪意のあるシステム・ユーザからのコード・インジェクション／実行攻撃を防止するために、スタック・ガードワードを初期化及び検証するためのアーキテクチャ化した（architected）ガードワード命令（例えば、ハードウェア命令）が提供される。ガードワード命令の使用は、ガードワードの使用を容易にし、及び／又はシステム・セキュリティを強化し得る。

【0017】

更に別の態様において、例えばルーチン又はその他から呼び出されることにより、互いにリンクできる全てのルーチン又はモジュール（例えば、１つ又は複数のルーチン）が、ガードワード保護ファシリティ（guard word protection facility）をサポートできるとは限らず、従って、致命的エラーを引き起こすことなく、異なる保護能力を備えたこうしたルーチン又はモジュールを連結することを可能にする１つ又は複数のフィーチャが提供される。

【0018】

本発明の１つ又は複数の態様を組み込み及び／又は用いるためのコンピューティング環境の一実施形態が、図１を参照して説明される。一例において、コンピューティング環境１００は、多数の他の汎用又は専用コンピューティング・システム環境又は構成で動作可能な、少なくとも１つのコンピュータ・システム／サーバ１０２を含む。コンピュータ・システム／サーバ１０２と共に用いるのに好適であり得る周知のコンピューティング・システム、環境、及び／又は構成の例としては、これらに限定されるものではないが、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、手持ち式又はラップトップ型デバイス、マルチプロセッサ・システム、マイクロプロセッサ・ベースのシステム、セット・トップ・ボックス、プログラム可能民生電子機器、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、及び、上述のシステム若しくはデバイス等のいずれかを含む分散型クラウド・コンピューティング環境が含まれる。

【0019】

コンピュータ・システム／サーバ１０２は、コンピュータ・システムによって実行される、プログラム・モジュールなどのコンピュータ・システム実行可能命令の一般的な文脈で説明することができる。一般に、プログラム・モジュールは、特定のタスクを実行する又は特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、論理、データ構造などを含むことができる。

【0020】

図１に示されるように、コンピュータ・システム／サーバ１０２は、汎用コンピューティング・デバイスの形で示される。コンピュータ・システム／サーバ１０２のコンポーネントは、これらに限定されるものではないが、１つ又は複数のプロセッサ又は処理ユニット１０６、システム・メモリ１０８、及びシステム・メモリ１０８を含む種々のシステム・コンポーネントをプロセッサ１０６に結合するバス１１０を含むことができる。

【0021】

一実施形態において、プロセッサ１０６は、インターナショナル・ビジネス・マシーンズ・コーポレーションにより提供されるｚ／Ａｒｃｈｉｔｅｃｔｕｒｅ又はインターナショナル・ビジネス・マシーンズ・コーポレーションにより提供される他のアーキテクチャに基づいている。ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅは、米国ニューヨーク州アーモンク所在のインターナショナル・ビジネス・マシーンズ・コーポレーションの登録商標である。本明細書で用いられる他の名称は、インターナショナル・ビジネス・マシーンズ・コーポレーション又は他の会社の登録商標、商標、又は製品名であり得る。ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅの一実施形態は、その全体が引用により本明細書に組み入れられる非特許文献１に記載される。

【0022】

他の例において、プロセッサ１０６は、カリフォルニア州サンタクララ所在のＩｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎにより提供されるｘ８６アーキテクチャなどの他のアーキテクチャ、及び／又はＩｎｔｅｌ又は他の会社により提供される他のアーキテクチャに基づくことができる。一例において、プロセッサ１０６が基づいているアーキテクチャは、複雑命令セット・コンピューティング（Complex Instruction Set Computing、ＣＩＳＣ）アーキテクチャである。本明細書で与えられる例は、いずれかの方法で制限することを意図するものではない。

【0023】

プロセッサ１０６は、一実施形態において、スタック内のガードワードが予想しない値を有し、従って、スタック内のリターンアドレスが上書きされたことを示すかどうかを判断するために使用されるスタック破損検出論理１６０を含む。スタック破損検出論理１６０は、一実施形態において、ガードワード及び／又は本明細書で説明される連結フィーチャを初期化及び検証するための命令を使用することができる。

【0024】

バス１１０は、メモリ・バス又はメモリ・コントローラ、周辺バス、アクセラレーテッド・グラフィックス・ポート、及び種々のバス・アーキテクチャのいずれかを用いるプロセッサ又はローカル・バスを含む、幾つかのタイプのバス構造のうちのいずれかの１つ又は複数を表す。限定ではなく例としては、このようなアーキテクチャは、業界標準アーキテクチャ（Industry Standard Architecture、ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（Micro Channel Architecture、ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカル・バス、及びＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスを含む。

【0025】

コンピュータ・システム／サーバ１０２は、典型的には、種々のコンピュータ・システム可読媒体を含む。このような媒体は、コンピュータ・システム／サーバ１０２によりアクセス可能ないずれかの利用可能媒体とすることができ、揮発性媒体及び不揮発性媒体の両方と、取り外し可能媒体及び取り外し不能媒体の両方とを含む。

【0026】

システム・メモリ１０８は、ランダム・アクセス・メモリ（ＲＡＭ）１１２及び／又はキャッシュ・メモリ１１４など、揮発性メモリの形のコンピュータ・システム可読媒体を含むことができる。コンピュータ・システム／サーバ１０２は、他の取り外し可能／取り外し不能、揮発性／不揮発性のコンピュータ・システム・ストレージ媒体をさらに含むことができる。単なる例として、取り外し不能の不揮発性磁気媒体（図示されておらず、典型的には「ハード・ドライブ」と呼ばれる）との間の読み出し及び書き込みのために、ストレージ・システム１１６を設けることができる。図示されていないが、取り外し可能な不揮発性磁気ディスク（例えば、「フロッピー・ディスク」）との間の読み出し及び書き込みのための磁気ディスク・ドライブと、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ又は他の光媒体などの取り外し可能な不揮発性光ディスクとの間の読み出し及び書き込みのための光ディスク・ドライブとを設けることができる。このような例においては、それぞれを、１つ又は複数のデータ媒体インターフェースによってバス１１０に接続することができる。以下でさらに示され説明されるように、メモリ１０８は、本発明の実施形態の機能を実行するように構成されたプログラム・モジュールのセット（例えば、少なくとも１つ）を有する少なくとも１つのプログラム製品を含むことができる。

【0027】

限定ではなく例として、メモリ１０８内に、プログラム・モジュール１２２のセット（少なくとも１つ）を有するプログラム／ユーティリティ１２０、並びにオペレーティング・システム、１つ又は複数のアプリケーション・プログラム、他のプログラム・モジュール、及びプログラム・データを格納することができる。オペレーティング・システム、１つ又は複数のアプリケーション・プログラム、他のプログラム・モジュール、及びプログラム・データ、又はそれらの何らかの組み合わせの各々は、ネットワーキング環境の実装形態を含むことができる。プログラム・モジュール１２２は、一般に、本明細書で説明される本発明の実施形態の機能及び／又は方法を実行する。

【0028】

コンピュータ・システム／サーバ１０２は、キーボード、ポインティング・デバイス、ディスプレイ１３２等のような１つ又は複数の外部デバイス１３０；ユーザがコンピュータ・システム／サーバ１０２と対話することを可能にする１つ又は複数のデバイス；及び／又はコンピュータ・システム／サーバ１０２が１つ又は複数の他のコンピューティング・デバイスと通信することを可能にするいずれかのデバイス（例えば、ネットワーク・カード、モデムなど）と通信することもできる。このような通信は、入力／出力（Ｉ／Ｏ）インターフェース１４０を経由して行うことができる。さらにまた、コンピュータ・システム／サーバ１０２は、ネットワーク・アダプタ１５０を介して、ローカル・エリア・ネットワーク（ＬＡＮ）、汎用広域ネットワーク（ＷＡＮ）、及び／又はパブリック・ネットワーク（例えば、インターネット）などの１つ又は複数のネットワークと通信することもできる。示されるように、ネットワーク・アダプタ１５０は、バス１１０を介して、コンピュータ・システム／サーバ１０２の他のコンポーネントと通信する。図示されないが、コンピュータ・システム／サーバ１０２と共に他のハードウェア及び／又はソフトウェア・コンポーネントを使用できることを理解されたい。例としては、これらに限定されるものではないが、マイクロコード、デバイス・ドライバ、冗長処理ユニット、外部のディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、及びデータ・アーカイブ・ストレージ・システムなどが含まれる。

【0029】

１つ又は複数の態様を組み込み、使用するためのコンピューティング環境の別の実施形態が、図２を参照して説明される。この例において、コンピューティング環境２００は、例えば１つ又は複数のバス２０８及び／又は他の接続を介して互いに結合された、例えば、ネイティブ中央演算処理ユニット２０２、メモリ２０４、並びに１つ又は複数の入力／出力デバイス及び／又はインターフェース２０６を含む。例として、コンピューティング環境２００は、ニューヨーク州アーモンク所在のインターナショナル・ビジネス・マシーンズ・コーポレーションにより提供されるｚＳｅｒｉｅｓサーバ；カリフォルニア州サンタクララ所在のＩｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎにより提供されるｘ８６プロセッサ；カリフォルニア州Ｐａｌｏ Ａｌｔｏ所在のＨｅｗｌｅｔｔ Ｐａｃｋａｒｄ Ｃｏ．により提供されるＩｎｔｅｌ Ｉｔａｎｉｕｍ ＩＩプロセッサを伴うＨＰ Ｓｕｐｅｒｄｏｍｅ；及び／又はインターナショナル・ビジネス・マシーンズ・コーポレーション、Ｈｅｗｌｅｔｔ Ｐａｃｋａｒｄ、Ｉｎｔｅｌ、Ｏｒａｃｌｅ又はその他により提供されるアーキテクチャに基づいた他のマシンを含むことができる。

【0030】

ネイティブ中央演算処理ユニット２０２は、環境内での処理の際に用いられる、１つ又は複数の汎用レジスタ及び／又は１つ又は複数の専用レジスタなどの１つ又は複数のネイティブ・レジスタ２１０を含む。これらのレジスタは、任意の特定の時点における環境の状態を表す情報を含む。

【0031】

さらに、ネイティブ中央演算処理ユニット２０２は、メモリ２０４内に格納される命令及びコードを実行する。１つの特定の例において、中央演算処理ユニットは、メモリ２０４内に格納されるエミュレータ・コード２１２を実行する。このコードにより、１つのアーキテクチャにおいて構成された処理環境が、別のアーキテクチャをエミュレートすることが可能になる。例えば、エミュレータ・コード２１２により、ｘ８６サーバ、ＨＰ Ｓｕｐｅｒｄｏｍｅサーバ又は他のものなどの、ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅ以外のアーキテクチャに基づいたマシンが、ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅをエミュレートし、ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅに基づいて開発されたソフトウェア及び命令を実行することが可能になる。他のアーキテクチャをエミュレートすることもできる。

【0032】

エミュレータ・コード２１２に関する更なる詳細が、図３を参照して説明される。ゲスト命令２５０が、ネイティブＣＰＵ２０２のもの以外のアーキテクチャにおいて実行されるように開発されたソフトウェア命令（例えば、マシン命令）を含む。例えば、ゲスト命令２５０は、ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅプロセッサ上で実行されるように設計されるが、代わりに、例えばＩｎｔｅｌ Ｉｔａｎｉｕｍ ＩＩプロセッサとすることができるネイティブＣＰＵ２０２上でエミュレートされることもある。一例において、エミュレータ・コード２１２は、メモリ２０４から１つ又は複数のゲスト命令２５０を取得し、取得された命令に対してローカル・バッファリングを随意的に提供するための命令フェッチ・ルーチン２５２を含む。エミュレータ・コード２１２また、取得されたゲスト命令のタイプを判断し、ゲスト命令を１つ又は複数の対応するネイティブ命令２５６に変換するための命令変換ルーチン２５４も含む。この変換は、例えば、ゲスト命令により実施される機能を識別することと、その機能を実施するためのネイティブ命令を選択することとを含む。

【0033】

さらに、エミュレータ・コード２１２は、ネイティブ命令を実行させるためのエミュレーション制御ルーチン２６０を含む。エミュレーション制御ルーチン２６０は、ネイティブＣＰＵ２０２に、１つ又は複数の以前に取得されたゲスト命令をエミュレートするネイティブ命令のルーチンを実行させ、こうした実行の最後に、制御を命令フェッチ・ルーチンに戻して、次のゲスト命令又はゲスト命令のグループの取得をエミュレートすることができる。ネイティブ命令２５６の実行は、メモリ２０４からレジスタ内にデータをロードすること、データをレジスタから再びメモリに格納すること、又は変換ルーチンによって求められるような何らかのタイプの算術演算又は論理演算を実施することを含むことができる。

【0034】

各ルーチンは、例えば、ソフトウェアで実装され、このソフトウェアは、メモリ内に格納され、ネイティブ中央演算処理ユニット２０２によって実行される。他の例において、１つ又は複数のルーチン又は演算は、ファームウェア、ハードウェア、ソフトウェア、又はそれらの幾つかの組み合わせで実装される。エミュレートされるプロセッサのレジスタは、ネイティブＣＰＵのレジスタ２１０又はメモリ２０４内の記憶位置を使用して、エミュレートすることができる。実施形態において、ゲスト命令２５０、ネイティブ命令２５６、及びエミュレータ・コード２１２は、同一のメモリ内に存在してもよく、又は異なるメモリ・デバイスの間に分散されてもよい。

【0035】

本明細書で用いられるファームウェアとは、例えば、プロセッサのマイクロコード、ミリコード、及び／又はマクロコードを含む。ファームウェアは、例えば、上位レベルのマシン・コードの実装に用いられるハードウェア・レベルの命令及び／又はデータ構造体を含む。一実施形態において、ファームウェアは、例えば、典型的には、信頼できるソフトウェアを含むマイクロコードとして供給される専用コード、又は基礎をなすハードウェアに特有のマイクロコードを含み、システム・ハードウェアへのオペレーティング・システムのアクセスを制御する。

【0036】

処理環境内で、ルーチンが実行を完了する時に制御を戻すべきポイントを追跡するために、ルーチンによりスタックが使用される。本明細書で用いられる場合、ルーチンはプログラム・コードであり、サブルーチン、関数、メソッド等を含むことができる。１つのルーチンを、別のルーチンにより呼び出すことができる。呼び出しを実行している１つのルーチンは、呼び出し側ルーチン（calling routine）又は呼び出し元ルーチン（caller routine）と呼ばれ、呼び出されているルーチンは、呼び出されたルーチン（called routine）又は呼び出し先ルーチン（callee routine）と呼ばれる。スタックの一例は、図４を参照して説明される。一例として、このスタックは、メモリ１０８内にあり得る。

【0037】

図４に示されるように、スタック３００は、スタックフレーム３０２ａ、３０２ｂのような複数のスタックフレームを含む。スタックフレームは、スタックにプッシュされるデータのフレームである。スタックフレームのデータは変わり得るが、一例においては、スタックフレーム３０２ａは、スタック・ポインタ３０４と、呼び出されたルーチンに渡されるパラメータ領域３０６と、呼び出し側ルーチンのローカル及びスピル変数領域３０８と、バッファ３１０と、呼び出されたルーチンにより使用され、リターンする前に復元される、１つ又は複数のレジスタのレジスタ保存領域３１２とを含む。さらに、リターンアドレス３１４が、現在のスタックフレームと前のスタックフレーム３０２ｂとの間に配置される。スタックフレームは、本明細書で説明されるものと比べて、付加的な、より少ない、及び／又は異なるデータを含むことができる。

【0038】

コンピュータ処理に関連する破損の１つの形は、バッファ３１０のオーバーフローであり、そこでは、図５の３５０に示されるように、バッファが受け入れ可能なよりも多くのデータがバッファに書き込まれ、バッファがオーバーフローし、リターンアドレスが上書きされる。リターンアドレスを上書きする際、異なるアドレスがそこに配置され、リターン・ルーチンを、実行すべきではなく、悪意のものでさえあり得るタスクを実行し得る他のコードに指向させる。

【0039】

従って、本発明の態様によると、こうしたオーバーフローを検出するために、ガードワードが提供される。ガードワードは、いずれの値（例えば、数字、文字数字、アルファベット、記号等）であってもよく、任意の所望のサイズとすることができる。ガードワードの位置は、一例においてはルーチンにより承認され、又は、少なくとも１つの位置の表示は、スタックフレームを使用するルーチンに提供される。一実施形態において、ガードワードの存在及び位置は、アプリケーション・バイナリ・インターフェース（ＡＢＩ）によって指定される。

【0040】

ガードワードをスタックに付加する１つの例が、図６〜図１０を参照して説明される。最初に図６を参照すると、コールスタックの呼び出し元のスタックフレーム４００の初期状態が、スタック・ポインタ４０２を有した状態で示される。その後、図７に示されるように、ガードワード４０４が、呼び出し元のスタックフレームの前に挿入される。つまり、ガードワードは、呼び出し先ルーチンが呼び出し元によって呼び出されるときのようなスタック成長の方向にあるメモリ内の位置に格納され、呼び出し先はそのスタックフレームを作成するが、この位置をスキップする。従って、ガードワードは、呼び出し元のスタックフレームと呼び出し先のスタックフレームとの間に配置される。呼び出し先のスタックフレームの作成は、呼び出し元のスタックフレームと呼び出し先のスタックフレームとを有するガードワードをもたらす。さらに、ガードワードは、２つのフレームの間にあるので、呼び出し元により書き込まれるガードワードは、今やコールスタックの一部となる。

【0041】

一例において、呼び出し元は、第１のサブルーチン呼び出しを実行する前に、（ＥＳＰが拡張されたスタック・ポインタである場合に、（ＥＳＰ−（リターンアドレス）のサイズ−（ガードワード）のサイズ）においてガードワードを格納する。（別の実施形態において、上向きに成長するスタックの場合、ガードワードを格納するためのアドレスは、ＳＰはスタック・ポインタである場合に、（ＳＰ）＋（リターンアドレス）のサイズとして計算される。）別の実施形態において、この配置は、関数（又は他のルーチン）呼び出しの前にスタック上に配置することができる関数パラメータの数をさらに考慮に入れる。従って、一実施形態において、下向きに成長する、すなわちより高いアドレスからより低いアドレスへ成長するスタックの場合、ガードワードは、アドレス（ＥＳＰ−（リターンアドレス）のサイズ−（ガードワード）のサイズ−（パラメータ領域）のサイズ）に配置することができる。

【0042】

さらに、図８に示されるように、ハードウェア管理関数コールスタックを実装するマイクロプロセッサによるサブルーチン呼び出し（例えば、関数呼び出し）に基づき、ハードウェア定義に従って、リターンアドレス４０６がスタック上にプッシュされる。一実施形態によると、この結果、リターンアドレスは、ガードワードと呼び出し元のスタックフレームとの間のスタック上に挿入され、スタック・ポインタが移動される。示されるように、一例において、リターンアドレスは、ハードウェア・プッシュ・リターン・スタックを介してスタック上に挿入される。例えば、ＣＩＳＣアーキテクチャにおいて、ジャンプ・サブルーチン関数は、リターンアドレスをハードウェア実装プロセッサ・スタックの真上に置く。

【0043】

さらに、図９を参照すると、呼び出し元ルーチンにより呼び出され、呼び出し先と呼ばれる呼び出されたルーチンが、そのスタックフレーム４２０を割り当てる。そのスタックフレームを割り当てる際、呼び出し先は、ガードワードを上書きしないように注意する。一実施形態において、本発明の態様によりイネーブルにされる呼び出し先の場合、呼び出し先スタックフレームのサイズを決定するプログラマ又はコンパイラは、ガードワードに対応するワード位置（word location）を予約されたものとして扱い、データは、スタックフレーム内のその位置に割り当てられない。しかしながら、ガードワードが適切に保持されることを保証するために、別個の命令におけるガードワードをスキップするように、呼び出し先によりスタック・ポインタを更新するか、又はガードワードが上書きされるのを防止するために、スタック上への割り当ての際、ガードワードのサイズだけ割り当てられるスタックフレームのサイズを増加させる。

【0044】

対照的に、本発明の態様によりイネーブルにされず、保護ガードワード機構によりイネーブルにされる呼び出し元により呼び出される呼び出し先において、呼び出し先スタックフレームが、ガードワードを呼び出し先のスタックフレームのデータの一部で上書きするように割り当てられる。

【0045】

一実施形態において、呼び出し先が処理を完了した後、呼び出し先は、ガードワードをチェックし、ガードワードが予想される値を有する場合、呼び出し先は、リターンアドレスにリターンし、その際、図１０の４３０に示されるように、リターンアドレスを除去する。

【0046】

１つ又は複数の態様によると、後述のように、ガードワードが、呼び出し元ルーチンにより提供され、呼び出されたルーチンにより検証される。呼び出し元は、例えばこれが最初にスタックフレームを割り当てるときに、ガードワードを一度書き込み、その一度書き込まれたガードワードが、１又は複数の呼び出し先により使用される。つまり、ガードワードは、１又は複数の呼び出し先からのリターンを保護する。各々の呼び出し先は、リターンする前にガードワードをチェックし、それが予想される値を有するかどうかを判断する。ガードワードが予想される値を有する場合、呼び出し先は、予想通り、リターンアドレスにリターンする。他の場合には、ガードワード破損（corrupt guard word）の表示が提供される。さらに、プログラムが終了されることがあり、及び／又は、侵入に対して付加的なアクションをとるよう、オペレーティング・システムに通知される。１つの態様において、このことは、ガードワードのストアが各関数（又は他のルーチン）呼び出しに対応する実施形態と比べて、ガードワードを書き込むために実行されるストア命令の数が低減し、ガードワードのチェックは、各関数（又は他のルーチン）のリターンに対応する。従って、保護機構のコストが低減される。さらに、別の態様において、ガードワードは、チェックされるよりもずっと早くに書き込まれているので、ストア・キューではなく、キャッシュから使用可能であることが保証される。その結果、付加的な不利益をもたらすことが多い、ストア・キューからの高価な転送動作を回避することができ、それにより性能がさらに改善される。

【0047】

スタック保護のためにガードワードを使用することに関連するさらなる詳細が、図１１〜図１２を参照して説明される。図１１を参照して、呼び出し元によりとられるアクションの一実施形態が説明され、図１２を参照して、呼び出し先によりとられるアクションの一実施形態が説明される。

【0048】

図１１を参照すると、一実施形態において、呼び出し元ルーチンは、ガードワードを、例えば呼び出し元のスタックフレームの前に格納する（ステップ５００）。次に、呼び出し元ルーチンは、関数呼び出しパラメータを呼び出し元のスタックフレーム上に配置する（ステップ５０２）。一例において、ガードワードを再利用するために、全ての呼び出しについてのパラメータ・サイズをマッチさせる（すなわち、一定サイズのパラメータ領域を本ルーチンにより呼び出された全てのルーチンに割り振り及び割り当てし、こうした呼び出しで指定されたパラメータの数及びタイプに基づき、より小さいパラメータ領域に対応する、ルーチン呼び出しにより未使用の幾らかのパラメータ空間を残す）。次に、呼び出し元は、呼び出し先ルーチンを呼び出し、この例では、ハードウェアにより、リターンアドレスをスタック上にプッシュする（ステップ５０４）。呼び出し先ルーチンと関連した処理は、図１２を参照して説明される。

【0049】

図１２を参照すると、呼び出されることに基づいて、呼び出し先は、そのスタックフレームを割り当て、確実にガードワードをスキップする（ステップ５５０）。次に、呼び出し先は、１つ又は複数の関数を随意的に実行する（ステップ５５２）。次に、呼び出し先は、ガードワードを含むフレームをアンスタックする（ステップ５５４）。つまり、呼び出し先は、スタックフレームを割り当て解除し、スタック・ポインタをガードワードの上に移動させる。呼び出し先は、ガードワードをチェックし（ステップ５５６）、ガードワードが予想通りであったかどうかを判断する（問い合わせ５５８）。ガードワードが予想される値でなかった場合、破損の表示が与えられる（ステップ５６０）。他の場合には、呼び出し先は、リターンアドレスにリターンする（ステップ５６２）。

【0050】

ガードワードを書き込み、ガードワードを検証し、破損したリターンアドレスへのリターンを防止するためのコードの一例が以下に与えられる（一実施形態においては、ＣＩＳＣ命令セット・アーキテクチャに基づく）：

【表1】

【0051】

上記のコードにおいて、ガードワードが保存されるメモリ位置を提供するために、Ｓｔｏｒｅ Ｇｕａｒｄ Ｗｏｒｄ命令が使用され、ガードワードの正しさを検証するために、ＰＯＰＣＨＥＣＫ命令が使用され、その各々が以下に説明される。

【0052】

図１３に示されるように、Ｓｔｏｒｅ Ｇｕａｒｄ Ｗｏｒｄ命令６００は、一実施形態においては、次の形式を有する：ＳＴＯＲＥ ＧＵＡＲＤ ＷＯＲＤアドレス。動作において、ガードワード値が、専用レジスタ、制御レジスタ、セキュア・メモリ位置等といった指定された位置から読み取られ、一時的な位置（ｒｔｍｐ）に格納される。次に、一時的な位置に格納された値は、命令により与えられるアドレス６０２（例えば、ＳＴ ｒｔｍｐ、アドレス）に格納される。

【0053】

一例において、指定された位置は、ガードワード・レジスタとすることができる。例えば、図１４に示されるように、ガードワード・レジスタ７００は、読み取られ、スタック内に格納されるガードワード値７０２を含む。

【0054】

さらに、図１５に示されるように、一例において、ＰＯＰＣＨＥＣＫと呼ばれる命令８００が、スタック（例えば、呼び出し元のスタック）からスタックの先頭（top of stack：ＴＯＳ）ワードを取得し、取得したワードをガードワードとして扱い、ワードがストレージ内で修正されないままであるが、もはやスタック上にあると見なされないように、スタック・ポインタを移動させ、取り出されたワードが正しいガードワードであるかどうか、又は破損が発生したかどうかをテストする。破損の場合、破損の表示が提供される。これは、例えば、固定アドレスへの転送、イベント・ベースの分岐への転送、例外の発生、及び／又はスーパーバイザ・ソフトウェアへの転送等を含むことができる。

【0055】

ＰＯＰＣＨＥＣＫ命令についての疑似コードの一例は、次の通りである。：

【表2】

【0056】

さらに別の実施形態において、ＰＯＰＣＨＥＣＫをリターンと結合し、ＰＯＰＣＨＥＣＫＲＥＴ命令を提供することができる。ＰＯＰＣＨＥＣＫＲＥＴ命令についての疑似コードの一例は、次の通りである。：

【表3】

【0057】

１つの態様において、ＰＯＰＣＨＥＣＫＲＥＴ命令は、チェックされるガードワードにアクセスする前に、メモリからのリターンアドレスにアクセスし、保護ガードワードによってリターンアドレスを保護できないあらゆる期間を排除することができる。一実施形態において、ＰＯＰＣＨＥＣＫＲＥＴは、ｘ８６命令セット・アーキテクチャのようなアーキテクチャにおける単一の命令として実施される。別の実施形態において、２つの命令（例えば、ＰＯＰＣＨＥＣＫ及びＲＥＴ）のシーケンス又はより多くの命令（例えば、ＬＯＡＤ ＧＵＡＲＤ ＷＯＲＤ（ガードワード・ロード）、ＣＯＭＰＡＲＥ ｌｏａｄｅｄ ｇｕａｒｄ ｗｏｒｄ ｔｏ ｒｅｆｅｒｅｎｃｅ ｇｕａｒｄ ｗｏｒｄ（ロードされたガードワードと基準ガードワードを比較）、ＢＲＡＮＣＨ ｔｏ ｎｏｔｉｆｉｃａｔｉｏｎ ａｄｄｒｅｓｓ（通知アドレスへ分岐）、ＲＥＴ、又は他のシーケンス）が、命令デコード論理により認識され、例えば、周知の命令デコード時間最適化を用いて、単一の内部命令に変形される。こうした実施形態は、ハードウェアにおいて単一のＰＯＰＣＨＥＣＫＲＥＴシーケンスを実施していない、セキュリティが十分でないプロセッサ、及び、より高いセキュリティを達成できるＰＯＰＣＨＥＣＫＲＥＴ操作を実施するプロセッサ上で実行することができ、従って、本発明の１つ又は複数のハードウェア機能の態様によりイネーブルにされないプロセッサへのプログラム移植性（program portability）、及び、こうした態様を実装するプロセッサ上のより高いセキュリティの両方を結合する。

【0058】

上述のように、ガードワードは、スタック内に配置され、リターンアドレスが上書きされたかどうかを検出するために、１又は複数の呼び出し先により使用される。このガードワードは、スタックの破損を検出し、データ及び／又はプログラムのさらなる破損を防止する。さらに、望ましくない又は未知の位置への制御の転送が防止される。

【0059】

１つ又は複数のさらに別の態様によると、例えばルーチン又はその他により呼び出されることにより互いにリンクすることができるモジュール（例えば、モジュールは１つ又は複数のルーチンを含む）又はルーチンは、異なる保護能力を有し得る。例えば、呼び出し元ルーチンは、ガードワード保護ファシリティをサポートすることができるが、呼び出し元により呼び出されたルーチンの１つ又は複数がガードワード保護ファシリティをサポートしないことがあり、又は逆もまた同様である。このことは、例えば呼び出し元プログラムが呼び出し先ルーチンにより実行されないアクションを予想するときに問題を引き起こすことがあり、又はその逆も同様である。従って、本発明の態様によれば、異なる保護能力のルーチン又はモジュールが、失敗することなくリンクすることを可能にする１つ又は複数のフィーチャが提供される。

【0060】

一例として、１つの態様は、ガード・ワード・ファシリティが使用されるかどうかを示すために、保護ガード・イネーブル化インジケータを使用することを含む。一例として、各ソフトウェア・スレッド（又は、プロセッサ若しくはアプリケーション）について、又はシングル・スレッド・コア、コアにおいて、保護ガード・イネーブル化インジケータが提供される。保護ガード・イネーブル化インジケータは、オペレーティング・システム、又はハイパーバイザ、又は論理パーティション及び／又は仮想マシンを含むコンピューティング環境内の他の仮想マシン・マネージャによりアクセスされるコンテキスト・スイッチ情報内に提供される。

【0061】

モジュール・ローダが、保護されない少なくとも１つのルーチンがロードされたことを認識すること（ルーチン又はルーチンを含むモジュールについての保護インジケータにより示されるように）に基づいて、保護ガード・イネーブル化インジケータは、ガード保護の使用をディスエーブルにするように設定される。更に別の実施形態において、動的リンカが、この状況を認識することができ、これがディスエーブルにされる場合、ガード保護の使用をディスエーブルにする。保護ガード・イネーブル化インジケータの使用に関連するさらなる詳細は、図１６〜図１７を参照して説明される。

【0062】

図１６を参照すると、静的リンカと関連した処理が説明される。この処理は、静的リンカにより実行される他の処理と併せて実行することができる。一例において、第１のモジュールは、例えば、メイン・プログラムである。別の実施形態において、各ルーチンはモジュールであり、スタック・ガード・サポートは、ルーチン毎（per-routine）ベースで示される。

【0063】

図１６を参照すると、プロセッサ内で実行される静的リンカは、モジュール（一実施形態において、モジュールは１つ又は複数のルーチンを含む）をリンクするための命令を受け取る（ステップ９００）。これに基づいて、スタック＿ガード（stack_guard）と呼ばれる変数が、真に等しくなるように設定される（ステップ９０２）。第１のモジュールのようなモジュールにアクセスし（ステップ９０４）、このモジュールがスタック・ガード保護（本明細書では条件付きガードとも呼ばれる）をサポートするかどうかを判断する（問い合わせ９０６）。このことは、例えば、モジュールと関連した保護インジケータに基づいて判断される。例として、この保護インジケータは、メモリ位置、又はモジュールと関連したファイル位置内に格納することができる。

【0064】

保護インジケータが、例えば１に設定された場合、モジュールは、スタック・ガード保護をサポートする。しかしながら、例えば０に等しいなど、保護インジケータが設定されない場合、モジュールは、スタック・ガード保護をサポートしない。モジュールがスタック・ガード保護をサポートしない場合、スタック＿ガードは、偽に設定される（ステップ９０８）。

【0065】

その後、又はモジュールがスタック・ガード保護をサポートしない場合、別のモジュールがリンクされるかどうかを判断する（問い合わせ９１０）。リンクされる場合、処理はステップ９０４に続く。他の場合には、スタック＿ガードの値をチェックする（問い合わせ９１２）。スタック＿ガードが真に設定される場合、リンクしたモジュールは、リンクしたモジュールとして、リンクしたモジュール・ファイルに書き込まれ、リンクしたモジュールがスタック・ガードをサポートすることを示す（ステップ９１４）。しかしながら、スタック＿ガードが偽に設定される場合、リンクしたモジュールは、リンクしたモジュールとして、リンクしたモジュール・ファイルに書き込まれ、リンクしたモジュールがスタック・ガードをサポートしないことを示す（ステップ９１６）。このことにより、モジュールが異なる保護能力を有したとしても、モジュールを処理することが可能になる。モジュールがこうした保護をサポートする又は保護なしに実行される場合、モジュールの１つ又は複数がスタック・ガード保護をサポートしない場合のいずれも、モジュールは、スタック・ガード保護に従って実行される。

【0066】

図１７を参照すると、動的リンカと関連した処理が説明される。この処理は、動的リンカにより実行される他の処理と併せて実行することができる。上述のように、動的リンカにより処理されるモジュールは、静的にリンクされたモジュールに対応し得る。

【0067】

図１７を参照すると、保護ガード・イネーブル化インジケータと呼ばれるインジケータが（例えば１に）設定され、スタック・ガードがイネーブルにされることを指定する（ステップ１０００）。要求されるモジュールをロードし（ステップ１００２）、ロードしたモジュールがスタック・ガード保護をサポートするかどうかを判断する（問い合わせ１００４）。例えば、モジュールの保護インジケータをチェックし、これがイネーブルに設定されたかどうかを判断する。ロードしたモジュールがスタック・ガード保護をサポートしない場合、保護ガード・イネーブル化インジケータを再設定し（例えば、ゼロに設定し）、スタック・ガードがディスエーブルにされることを示す（ステップ１００６）。その後、又はモジュールがスタック・ガード保護をサポートする場合、ロードしたモジュール内のコードを実行する（ステップ１００８）。再び、モジュールは、モジュールがこの保護をサポートすることに基づいてスタック・ガード保護を有した状態で実行されるか、又はモジュールがスタック・ガード保護をサポートしないことに基づいてスタック・ガード保護を有さない状態で実行されるかのいずれかである。

【0068】

さらに、別のモジュールをロードするかどうかを判断する（問い合わせ１０１０）。ロードされない場合、プログラムは終了する（ステップ１０１２）。他の場合には、処理はステップ１００２に続く。

【0069】

上記の論理を用いて、リンクされる複数のモジュールのうちの少なくとも１つのモジュールがスタック・ガード保護をサポートしない場合、スタック・ガード保護は使用されない。従って、一例において、ガードワードの検証が抑止されることがあり、更に別の態様において、ガードワードの格納も抑止され得る。

【0070】

ルーチン又はモジュールの１つ又は複数がスタック・ガード保護をサポートしないといった、選択された状況におけるガードワードの格納及び／又はガードワードの検証を容易にするために、スタック・ガード保護が使用されるかどうかをチェックするための条件付き論理を含むＳｔｏｒｅ Ｇｕａｒｄ Ｗｏｒｄ及びＰＯＰＣＨＥＣＫ又はＰＯＰＣＨＥＣＫＲＥＴ命令の変形が提供される。これらの命令は、それぞれ、Ｓｔｏｒｅ Ｇｕａｒｄ Ｗｏｒｄ Ｃｏｎｄｉｔｉｏｎａｌ（ＳＴＰＧＣ）命令及びＰＯＰＣＨＥＣＫ Ｃｏｎｄｉｔｉｏｎａｌ（ＰＯＰＣＨＥＣＫＣ）又はＰＯＰＣＨＥＣＫＲＥＴ Ｃｏｎｄｉｔｉｏｎａｌ命令と呼ばれる。これらの命令の各々は、条件付き論理が含まれるかどうかを示すオペコードが異なる点を除いて、それぞれ、Ｓｔｏｒｅ Ｇｕａｒｄ Ｗｏｒｄ又はＰＯＰＣＨＥＣＫ／ＰＯＰＣＨＥＣＫＲＥＴ命令に類似した形式を有する。

【0071】

一実施形態において、Ｓｔｏｒｅ Ｇｕａｒｄ Ｗｏｒｄ Ｃｏｎｄｉｔｉｏｎａｌ命令において、保護ガード・イネーブル化インジケータがイネーブルにされる場合、ガードワードは、コールスタック内の指定されたメモリ位置に格納され、ＰＯＰＣＨＥＣＫ／ＰＯＰＣＨＥＣＫＲＥＴ命令において、保護ガード・イネーブル化インジケータがイネーブルにされる場合、検証が実行される。一例において、保護ガード・イネーブル化インジケータのチェックは、プロセッサの命令デコード・ユニットにおいて実施される。こうした実施形態において、保護ガード・イネーブル化インジケータが、保護ガード・ファシリティが使用されないことを示す場合、命令デコード論理は、命令をノーオペレーション（ＮＯＰ）命令に変換することができ、又はこれをデコードされた命令のストリームから完全に除外することができる。

【0072】

Ｓｔｏｒｅ Ｇｕａｒｄ Ｗｏｒｄ Ｃｏｎｄｉｔｉｏｎａｌ命令に関連するさらなる詳細が、図１８を参照して説明される。一実施形態において、Ｓｔｏｒｅ Ｇｕａｒｄ Ｗｏｒｄ Ｃｏｎｄｉｔｉｏｎａｌ命令の実行の開始（ステップ１１００）に基づいて、保護ガード・イネーブル化インジケータがイネーブルにされるかどうかを判断する（問い合わせ１１０２）。これがイネーブルにされる場合、ガードワード値をガードワード・レジスタ又は他の選択された位置から取得し（ステップ１１０４）、ＳＴＰＧＣのアドレスにより指定されたメモリ位置に格納する（ステップ１１０６）。次に、命令は完了する（ステップ１１０８）。他の場合には、保護ガード・イネーブル化インジケータがイネーブルにされない場合、ガードワード値を取得することなく、又はこれをスタック内に格納することなく、命令は完了する（ステップ１１０８）。

【0073】

同様に、ＰＯＰＣＨＥＣＫ Ｃｏｎｄｉｔｉｏｎａｌ命令に関するさらなる詳細が、図１９を参照して説明される。一実施形態において、ＰＯＰＣＨＥＣＫ Ｃｏｎｄｉｔｉｏｎａｌ命令の実行の開始（ステップ１２００）に基づいて、保護ガード・イネーブル化インジケータがイネーブルにされるかどうかを判断する（問い合わせ１２０２）。これがイネーブルにされる場合、スタックの先頭からガードワードをロードし（ステップ１２０４）、スタック・ポインタがガードワードの上方に移動されるので、ガードワードは除去されたように見えるが、メモリ内にあるままである（ステップ１２０５）。ガードワード・レジスタ又は他の選択された位置からガードワード値を取得し（ステップ１２０６）、スタックの先頭からのガードワードとガードワード・レジスタを比較する。不一致がある場合（問い合わせ１２０８）、破損の表示が提供される（ステップ１２１０）。他の場合には、命令が完了する（ステップ１２１２）。

【0074】

問い合わせ１２０２に戻ると、保護ガード・イネーブル化インジケータがディスエーブルにされた場合、上述のように、スタック・ポインタを移動させ（ステップ１２１１）、処理はステップ１２１２に続く。命令は、ガードワードをロード又は取得することなく、又は比較を実行することなく完了する。

【0075】

Ｃｏｎｄｉｔｉｏｎａｌ ｓｔｏｒｅ ａｎｄ ｖｅｒｉｆｙ（条件付きストア及び検証）命令を用いるコードの一例が、以下に説明される（ＣＩＳＣ命令セット・アーキテクチャの一例において）。：

【表4】

【0076】

上記の例示的なコードの別の実施形態において、ＰＯＰＣＨＥＣＫ ＣＯＮＤ及びＲＥＴ命令が、単一のＰＯＰＣＨＥＣＫＲＥＴ ＣＯＮＤ命令又は併合された命令シーケンスにより置換される。こうした実施形態によると、ＰＯＰＣＨＥＣＫＲＥＴ ＣＯＮＤ命令は、スタックからリターンアドレスを無条件に取り出し、（ガード・ワード・ファシリティがイネーブルにされることに基づいて）スタックからガードワードを条件付きで取り出し、スタック・ポインタをガードワード及びリターンアドレスにわたって無条件に移動させ、（ガード・ワード・ファシリティがイネーブルにされることに基づいて）条件付きでロードされたガードワードを基準ガードワードと条件付きで比較し、条件付きで取り出したガードワードと基準ガードワードとの間の不一致の判断に基づいて、破損の表示を行い、破損の通知が実行されない限り（すなわち、破損が検出されなかった場合、ガード・ワード・ファシリティがディスエーブルにされることに無条件に基づいて、又はガード・ワード・ファシリティがイネーブルされることに条件付きで基づいて）、前にリターンしたアドレスへのリターンを実行する。

【0077】

潜在的に異なる保護能力を有するモジュールを連結する１つの例が上述される。別の例において、保護ガード・イネーブル化インジケータを使用する代わりに、例えば、インジケータのイネーブル・ベクトルとして実装されるルーチン毎の表示が使用される。一例において、図２０に示されるように、イネーブル・ベクトル１３００（イネーブル・ベクトル・スタックとも呼ばれる）は、ゼロに初期化されたシングル・ビット・シフト・レジスタ１３０２とすることができる。ルーチンがスタック上にガードワードを格納するとき、ルーチンは、イネーブル・ベクトル・スタック１３０４の先頭においてインジケータを（例えば１に）設定し、ルーチンがそのスタック内に保護ガードワードを提供したことを示す。ルーチンが呼び出されると、スタックの先頭に、新しいインジケータが提供される。このことは、シフト・レジスタを、新しいルーチンの存在を示す１ビットだけシフトすることによって達成することができる。ルーチンがリターンすると、シフト・レジスタは反対方向にシフトされる。

【0078】

従って、サブルーチン呼び出し及び呼び出し先における上の例において、サブルーチン呼び出し（すなわち、呼び出し元）がスタック上にガードワードを格納することに基づいて、サブルーチン呼び出し元は、ベクトル内のインジケータ１３０６（インジケータの設定時にベクトル・スタックの先頭にある）を設定する。同様に、呼び出し先がそのスタック上にガードワードを格納する場合、呼び出し先もインジケータ１３０８を設定する。

【0079】

スタックは所定のサイズのものであるので、必要に応じて、バックアップ・ストレージ内に、いずれかのシフトアウト・インジケータを格納することができる。少なくとも１つの実施形態によると、バックアップ・ストレージが使用されない場合、インジケータをチェックする必要はないとの表示に対応する「０」にシフトインすることにより、ガードワード保護なしに、インジケータがシフトアウトしたそれらのルーチンを実行することができる。

【0080】

さらに別の実施形態において、ルーチンの全てがスタック・ガード保護を有する（例えば、本明細書で説明される技術を実行することによって）ことが知られる場合、ファシリティは、「１」をロードするように構成される、又はシングル・ビット・インジケータを使用し、スタック・インジケータに関係なく、ガードワード保護を行わせる。

【0081】

イネーブル・ベクトル・インジケータの例においては、Ｓｔｏｒｅ Ｇｕａｒｄ Ｗｏｒｄ Ｃｏｎｄｉｔｉｏｎａｌ及びＰＯＰＣＨＥＣＫ Ｃｏｎｄｉｔｉｏｎａｌ命令を使用できるが、論理は少し異なる。この例において、条件は、ガードワード保護イネーブル化インジケータに基づく代わりに、イネーブル・ベクトルから取り出したスタック・インジケータの値に基づく。

【0082】

例えば、この例において、Ｓｔｏｒｅ Ｇｕａｒｄ Ｗｏｒｄ Ｃｏｎｄｉｔｉｏｎａｌ命令は、ガードワードをスタック内に格納し、イネーブル・ベクトル内のスタック・インジケータを例えば１に設定する（インジケータ（ｅＴＯＳ）は真に設定され、ここでｅＴＯＳは、イネーブル・ベクトルのスタックの先頭である）。ＳＴＰＧＣ−２と呼ばれるＳｔｏｒｅ Ｇｕａｒｄ Ｗｏｒｄ Ｃｏｎｄｉｔｉｏｎａｌ命令のこの例と関連した論理の一実施形態が、図２１を参照して説明される。

【0083】

図２１を参照すると、一実施形態において、ＳＴＰＧＣ−２命令の実行に基づいて、ガードワード・レジスタ又は他の選択された位置から、ガードワード値を取得する（ステップ１４００）。次に、取得した値を、提供される命令のアドレスに格納する（ステップ１４０２）。次に、この実施形態において、イネーブル・ベクトル内のスタック・インジケータを設定する（例えば、ｅＴＯＳにおけるインジケータを１に設定する）（ステップ１４０４）。

【0084】

さらに、一例において、ＰＯＰＣＨＥＣＫ Ｃｏｎｄｉｔｉｏｎａｌ命令は、選択されたインジケータがガードワード保護を示す場合、ガードワードを検証する（インジケータ（ｅＴＯＳ＋１）、すなわち、本ルーチンの呼び出し元に対応し、スタック・ガードワードを提供した呼び出し元が真であるかどうかを示すインジケータ）を検証する）。ＰＯＰＣＨＥＣＫＣ−２と呼ばれるＰＯＰＣＨＥＣＫ Ｃｏｎｄｉｔｉｏｎａｌ命令のこの例と関連した論理の一実施形態が、図２２を参照して説明される。

【0085】

図２２を参照すると、一実施形態において、命令の実行を開始し（ステップ１５００）、イネーブル・ベクトルの位置におけるインジケータ（ｅＴＯＰ＋１）が１に等しいかどうかを判断する（問い合わせ１５０２）。１に等しい場合、上述のように、スタックの先頭からガードワード値をロードし（ステップ１５０４）、スタック・ポインタを移動させる（ステップ１５０５）。ガードワード・レジスタ又は他の選択された位置から、ガードワード値を取得し（ステップ１５０６）。スタックからのガードワード値を、ガードワード・レジスタ又は他の選択された位置からのガードワード値と比較する。合致がない場合（問い合わせ１５０８）、破損が示される（ステップ１５１０）。他の場合には、合致がある場合、命令が完了する（ステップ１５１２）。

【0086】

問い合わせ１５０２に戻ると、イネーブル・ベクトル内のインジケータが設定されない場合、スタック・ポインタを移動させ（ステップ１５１１）、処理はステップ１５１２に続く。

【0087】

上記に加えて、ＰＯＰＣＨＥＣＫＲＥＴは、条件付きとすることもできる。

【0088】

少なくとも１つの実施形態において、呼び出し先がＰＯＰＣＨＥＣＫ命令を実行しないとき、例えばサブルーチン命令からのリターンの実行中、呼び出し元によりガードワードが提供されないことを示すように、呼び出し元のインジケータ（ｅＴＯＰ＋１）を再設定する。このことは、本ルーチンが、保護ガード・ワード・ファシリティに関してイネーブルにされないように見え、その結果、本呼び出し先によるガードワードの上書きがもたらされ、そのため、本ルーチンの呼び出し元の他の呼び出し先によるガードワードの破損及び将来の使用を防止するために、スタック・ガードワードをスキップしなかった可能性が高いことを示す。

【0089】

上記は、異なる保護能力の有無に関係なく、モジュール又はルーチンの連結を可能にする。一実施形態において、インジケータは、ルーチン毎ベースである。各ルーチン・レベルについて、そのスタックがガードワードに保護されているかどうかを追跡するプッシュダウン・スタック（例えば、イネーブル・ベクトル）が提供される。呼び出しサブルーチンは、スタック上に新しいエントリを割り当て、保護されていないエントリを初期化する。Ｓｔｏｒｅ Ｇｕａｒｄ Ｗｏｒｄ命令又は他のｓｔｏｒｅ ｐｒｏｔｅｃｔｉｏｎ ｗｏｒｄ（保護ワード・ストア）命令は、スタック保護がルーチンの呼び出し先に関してイネーブルにされたことを示すようにプッシュダウン・スタックを同時に更新する呼び出しサブルーチンにより実行される。スタックが呼び出し元により保護されているとき、呼び出し先は、ＰＯＰＣＨＥＣＫ命令、又はガードワードを検証するための他のｖｅｒｉｆｙ ｐｒｏｔｅｃｔｉｏｎ ｗｏｒｄ（保護ワード検証）命令を実行する。他の場合には、一例において、検証が抑止される。他の実施形態も可能である。

【0090】

本明細書で説明されるように、スタックの破損の検出が容易にされる。スタックの破損の検出に関連する論理の１つの実施形態が、図２３〜図２４を参照して説明される。

【0091】

図２３を参照すると、一実施形態において、コンピューティング環境のプロセッサ上で実行される呼び出されたルーチンが、呼び出し側ルーチンにより提供されたガードワードをチェックする（ステップ１６００）。呼び出し側ルーチンは、呼び出されたルーチンを呼び出しており、ガードワードは呼び出し側ルーチンのスタック内に格納され、ハードウェア命令によりスタック内に直接格納されるリターンアドレスを保護する（ステップ１６０２）。

【0092】

チェックすることに基づいて、ガードワードが予想される値を有するかどうかを判断する（ステップ１６０４）。ガードワードが予想しない値を有すると判断することに基づいて、スタックの破損の表示を提供する（ステップ１６０６）。

【0093】

一例において、少なくともチェックすること及び判断することは、呼び出されたルーチンにより発行された命令を介して実行される（ステップ１６０８）。命令を実行し（ステップ１６１０）、実行することは、スタックからガードワードを取得すること（ステップ１６１２）と、ガードワードがもはやスタック上に見えないように、スタックのスタック・ポインタを移動させること（ステップ１６１４）と、判断すること、チェックすること及び表示を提供することの１つ又は複数を実行すること（ステップ１６１６）とを含むことができる。

【0094】

実行することは、リターンアドレスを保護するために、呼び出し側ルーチンがガードワードの使用をサポートするかどうかを判断することをさらに含む（ステップ１６１８）。呼び出し側ルーチンがガードワードの使用をサポートすると判断することに基づいて、取得すること、移動させること、及び実行することを実行する（ステップ１６２０）。

【0095】

一例において、ガードワードについてのアドレスを指定するｓｔｏｒｅ ｇｕａｒｄ ｗｏｒｄ命令を用いて、ガードワードを提供する（ステップ１６２２）。

【0096】

図２４を参照すると、リターンアドレスを保護するために、呼び出し側ルーチンがガードワードの使用をサポートすることを示すように、インジケータを設定することができる（ステップ１６３０）。

【0097】

更に別の態様において、リターンアドレスを保護するために、呼び出し側ルーチン及び呼び出されたルーチンがガードワードの使用をサポートするかどうかを判断する（ステップ１６３２）。リターンアドレスを保護するために、呼び出し側ルーチン及び呼び出されたルーチンがガードワードの使用をサポートすると判断することに基づいて、チェックすること、判断すること、及び表示を提供することのうちの１つ又は複数を実行する（ステップ１６３４）。リターンアドレスを保護するために、呼び出し側ルーチン及び呼び出されたルーチンの少なくとも１つのルーチンがガードワードの使用をサポートしないと判断することに基づいて、チェックすることの前に処理を終了する（ステップ１６３６）。

【0098】

一実施形態において、リターンアドレスを保護するために、呼び出し側ルーチン及び呼び出されたルーチンがガードワードの使用をサポートするかどうかを判断することは、少なくとも１つのインジケータをチェックすることを含む（ステップ１６３８）。インジケータのベクトル内に少なくとも１つのインジケータを格納することができる（ステップ１６４０）。

【0099】

例が本明細書に説明されるが、他の実施形態も可能である。例えば、一実施形態において、ガードワードがリーフ関数内に割り当てられないことがあり、リーフ関数は、書き込みを実行するオーバーヘッドをさらに低減させ、リターンアドレスがスタック内に格納されなかった場合、ガードワードをチェックすることはできず、そのため、チェックのオーバーヘッドがさらに低減される。

【0100】

少なくとも１つの実施形態において、ガードワードは、「＼０」文字（又は他の適切なターミネータ）を含み、終端文字のために大部分のオーバーフローが終了することをさらに保証する。このことは、ガード文字を「正しく」上書きすることは、そのポイントにおける上書き攻撃を暗黙的に終了させるので、ガード文字が再構成される場合、最も脆弱な（文字列）関数によるオーバーフロー攻撃を回避する。

【0101】

一実施形態において、ガードワードは、あらゆる実行の際にランダム化され、新しいプログラムが実行されるとき、オペレーティング・システムにより初期化される。

【0102】

更に別の態様において、プログラマ、オペレータ、スーパーバイザ・ユーザ、及び他のエージェントにより、スタック保護がディスエーブルにされることがある。さらに別の実施形態において、システム・ロードに基づいて又は他の選択された基準に基づいて、保護がディスエーブルにされることがある。

【0103】

例えば、ＣＩＳＣアーキテクチャにおいて使用されるｊｕｍｐ ｓｕｂｒｏｕｔｉｎｅ（サブルーチン・ジャンプ）命令のような、ハードウェア命令によりスタック内に直接格納されたリターンアドレスを保護するための低オーバーヘッド機構が、本明細書で説明される。

【0104】

一例において、ハードウェアにより管理されるスタック及びサブルーチン呼び出しにおいて、サブルーチン命令は、リターンアドレスをスタックの先頭に置き、呼び出し元は、ガードワードをスタックの下方に置き、各自のフレームを割り当てるときに、呼び出された関数はガードワードを「スキップ」する。この状況に対処するために、処理がもたらされる。

【0105】

一態様において、リターンアドレスの取り出しは、そこへの転送と直接リンクされ、その時点でチェックを行うのは遅すぎるので、ガードワードのチェックは、リターンアドレスの取り出し及び使用の前に行われる。従って、ＰＯＰＣＨＥＣＫＲＥＴ、すなわち、リターンアドレスを取り出し、ガードワードをチェックし、単一の命令において呼び出し元に戻す命令は、以前には与えられなかったセキュリティを可能にする。別の実施形態において、マイクロアーキテクチャの実施形態は、ガードワードをチェックし、リターンを実行するための命令のシーケンスを融合する。ＰＯＰＣＨＥＣＫＲＥＴ（単一の命令として又は融合したシーケンスとしてのいずれか）は、安全に、かつ、リターンアドレスが保護されていないいずれの期間もなく、チェック及びリターンを実行する。

【0106】

１つ又は複数の態様は、クラウド・コンピューティングに関連し得る。

【0107】

本開示はクラウド・コンピューティングについての詳細な説明を含むが、本明細書に記載される教示の実装は、クラウド・コンピューティング環境に限定されないことが、あらかじめ理解される。むしろ、本発明の実施形態は、現在周知の又は後で開発される他のいずれかのタイプのコンピューティング環境と共に実施することができる。

【0108】

クラウド・コンピューティングは、最小限の管理労力又はサービス・プロバイダとの対話で迅速にプロビジョニング及び解放することができる構成可能なコンピューティング・リソース（例えば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、及びサービス）の共有プールへの、便利なオンデマンドのネットワーク・アクセスを可能にするためのサービス配信のモデルである。このクラウド・モデルは、少なくとも５つの特徴、少なくとも３つのサービス・モデル、及び少なくとも４つの配備モデルを含むことができる。

【0109】

特徴は、以下の通りである。
オンデマンド・セルフサービス：クラウド・コンシューマは、必要に応じて、サーバ時間及びネットワーク・ストレージ等のコンピューティング機能を、人間がサービスのプロバイダと対話する必要なく自動的に、一方的にプロビジョニングすることができる。
広範なネットワーク・アクセス：機能は、ネットワーク上で利用可能であり、異種のシン又はシック・クライアント・プラットフォーム（例えば、携帯電話、ラップトップ、及びＰＤＡ）による使用を促進する標準的な機構を通じてアクセスされる。
リソースのプール化：プロバイダのコンピューティング・リソースは、マルチ・テナント・モデルを用いて、異なる物理及び仮想リソースを要求に応じて動的に割り当て及び再割り当てすることにより、複数のコンシューマにサービスを提供するためにプールされる。コンシューマは、一般に、提供されるリソースの正確な位置についての制御又は知識を持たないが、より高レベルの抽象化では位置（例えば、国、州、又はデータセンタ）を特定できる場合があるという点で、位置とは独立しているといえる。
迅速な弾力性：機能は、迅速かつ弾力的に、幾つかの場合自動的に、プロビジョニングして素早くスケール・アウトし、迅速にリリースして素早くスケール・インさせることができる。コンシューマにとって、プロビジョニングに利用可能なこれらの機能は、多くの場合、無制限であり、いつでもどんな量でも購入できるように見える。
サービスの測定：クラウド・システムは、サービスのタイプ（例えば、ストレージ、処理、帯域幅、及びアクティブなユーザ・アカウント）に適した何らかの抽象化レベルでの計量機能を用いることによって、リソースの使用を自動的に制御及び最適化する。リソース使用を監視し、制御し、報告し、利用されるサービスのプロバイダとコンシューマの両方に対して透明性をもたらすことができる。

【0110】

サービス・モデルは以下の通りである。
Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ（ＳａａＳ）：クラウド・インフラストラクチャ上で動作しているプロバイダのアプリケーションを使用するために、コンシューマに提供される機能である。これらのアプリケーションは、ウェブ・ブラウザ（例えば、ウェブ・ベースの電子メール）などのシン・クライアント・インターフェースを通じて、種々のクライアント・デバイスからアクセス可能である。コンシューマは、限定されたユーザ固有のアプリケーション構成設定の考え得る例外として、ネットワーク、サーバ、オペレーティング・システム、ストレージ、又は個々のアプリケーション機能をも含めて、基礎をなすクラウド・インフラストラクチャを管理又は制御しない。
Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ（ＰａａＳ）：プロバイダによってサポートされるプログラミング言語及びツールを用いて生成された、コンシューマが生成した又は取得したアプリケーションを、クラウド・インフラストラクチャ上に配備するために、コンシューマに提供される機能である。コンシューマは、ネットワーク、サーバ、オペレーティング・システム、又はストレージなどの基礎をなすクラウド・インフラストラクチャを管理又は制御しないが、配備されたアプリケーション、及び場合によってはアプリケーション・ホスティング環境構成に対して制御を有する。
Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ（ＩａａＳ）：コンシューマが、オペレーティング・システム及びアプリケーションを含み得る任意のソフトウェアを配備及び動作させることができる、処理、ストレージ、ネットワーク、及び他の基本的なコンピューティング・リソースをプロビジョニンングするために、コンシューマに提供される機能である。コンシューマは、基礎をなすクラウド・インフラストラクチャを管理又は制御しないが、オペレーティング・システム、ストレージ、配備されたアプリケーションに対する制御、及び場合によってはネットワーク・コンポーネント（例えば、ホストのファイアウォール）選択の限定された制御を有する。

【0111】

配備モデルは以下の通りである。
プライベート・クラウド：クラウド・インフラストラクチャは、ある組織のためだけに運営される。このクラウド・インフラストラクチャは、その組織又は第三者によって管理することができ、構内又は構外に存在することができる。
コミュニティ・クラウド：クラウド・インフラストラクチャは、幾つかの組織によって共有され、共通の関心事項（例えば、任務、セキュリティ要件、ポリシー、及びコンプライアンス上の考慮事項）を有する特定のコミュニティをサポートする。クラウド・インフラストラクチャは、その組織又は第三者によって管理することができ、オンプレミス又はオフプレミスに存在することができる。
パブリック・クラウド：クラウド・インフラストラクチャは、一般公衆又は大規模な業界グループに利用可能であり、クラウド・サービスを販売する組織によって所有される。
ハイブリッド・クラウド：クラウド・インフラストラクチャは、固有のエンティティのままであるが、データ及びアプリケーションの移行性を可能にする標準化された又は専用の技術（例えば、クラウド間の負荷分散のためのクラウド・バースティング）によって結び付けられる２つ又はそれより多いクラウド（プライベート、コミュニティ、又はパブリック）の混成物である。

【0112】

クラウド・コンピューティング環境は、無国籍性、低結合性、モジュール性、及びセマンティック相互運用性に焦点を置くことを指向するサービスである。クラウド・コンピューティングの中心は、相互接続されたノードのネットワークを含むインフラストラクチャである。

【0113】

クラウド・コンピューティング・ノードは、図１に示されるもののようなコンピュータ・システム／サーバを含むことができる。図１のコンピュータ・システム／サーバ１０２は、通信ネットワークを通じてリンクされた遠隔処理デバイスによってタスクが実行される分散型クラウド・コンピューティング環境で実施することができる。分散型クラウド・コンピューティング環境において、プログラム・モジュールは、メモリ・ストレージ・デバイスを含む、ローカル及び遠隔両方のコンピュータ・システム・ストレージ媒体に配置することができる。コンピュータ・システム／サーバ１２は、上述した機能のいずれも実装及び／又は実行することができる。

【0114】

ここで図２５を参照すると、例示的なクラウド・コンピューティング環境５０が示される。示されるように、クラウド・コンピューティング環境５０は、例えば携帯情報端末（ＰＤＡ）又は携帯電話５４Ａ、デスクトップ・コンピュータ５４Ｂ、ラップトップ・コンピュータ５４Ｃ、及び／又は自動車コンピュータ・システム５４Ｎなどといった、クラウド・コンシューマによって用いられるローカル・コンピューティング・デバイスと通信することができる、１つ又は複数のクラウド・コンピューティング・ノード１０を含む。ノード１０は、互いに通信することができる。これらのノードは、上述のようなプライベート・クラウド、コミュニティ・クラウド、パブリック・クラウド、若しくはハイブリッド・クラウド、又はこれらの組み合わせなど、１つ又は複数のネットワークにおいて物理的又は仮想的にグループ化することができる（図示せず）。これにより、クラウド・コンピューティング環境５０は、クラウド・コンシューマがローカル・コンピューティング・デバイス上にリソースを保持する必要のないサービスとして、インフラストラクチャ、プラットフォーム、及び／又はソフトウェアを提供することが可能になる。図２５に示されるコンピューティング・デバイス５４Ａ〜Ｎのタイプは単に例示であることを意図し、コンピューティング・ノード１０及びクラウド・コンピューティング環境５０は、いずれのタイプのネットワーク及び／又はネットワーク・アドレス指定可能な接続上でも（例えば、ウェブ・ブラウザを用いて）、いずれのタイプのコンピュータ化された装置とも通信できることを理解されたい。

【0115】

ここで図２６を参照すると、クラウド・コンピューティング環境５０（図２５）によって提供される機能抽象化層の組が示される。図２６に示されるコンポーネント、層、及び機能は単に例示であることを意図し、本発明の実施形態はそれらに限定されないことを予め理解されたい。図示されるように、以下の層及び対応する機能が提供される。

【0116】

ハードウェア及びソフトウェア層６０は、ハードウェア及びソフトウェア・コンポーネントを含む。ハードウェア・コンポーネントの例として、メインフレーム６１と、ＲＩＳＣ（Reduced Instruction Set Computer（縮小命令セット・コンピュータ））アーキテクチャ・ベースのサーバ６２と、サーバ６３と、ブレード・サーバ６４と、ストレージ・デバイス６５と、ネットワーク及びネットワーキング・コンポーネント６６とが含まれる。幾つかの実施形態において、ソフトウェア・コンポーネントは、ネットワーク・アプリケーション・サーバ・ソフトウェア６７及びデータベース・ソフトウェア６８を含む。

【0117】

仮想化層７０は、抽象化層を提供し、この層により、仮想エンティティの以下の例、すなわち、仮想サーバ７１、仮想ストレージ７２、仮想プライベート・ネットワークを含む仮想ネットワーク７３、仮想アプリケーション及びオペレーティング・システム７４、並びに仮想クライアント７５を提供することができる。

【0118】

一例においては、管理層８０は、以下で説明される機能を提供することができる。リソース・プロビジョニング８１は、クラウド・コンピューティング環境内でタスクを実行するために利用されるコンピューティング・リソース及び他のリソースの動的な調達を提供する。計量及び価格決定８２は、クラウド・コンピューティング環境内でリソースが利用される際のコスト追跡と、リソースの消費に対する課金又は請求とを提供する。一例においては、これらのリソースは、アプリケーション・ソフトウェア・ライセンスを含むことができる。セキュリティは、クラウド・コンシューマ及びタスクに対する識別情報の検証と、データ及び他のリソースに対する保護とを提供する。ユーザ・ポータル８３は、コンシューマ及びシステム管理者のために、クラウド・コンピューティング環境へのアクセスを提供する。サービス・レベル管理８４は、要求されるサービス・レベルが満たされるように、クラウド・コンピューティング・リソースの割り当て及び管理を提供する。サービス・レベル・アグリーメント（Service Level Agreement、ＳＬＡ）の計画及び履行８５は、ＳＬＡに従って将来の要件が予測されるクラウド・コンピューティング・リソースの事前配置及び調達を提供する。

【0119】

ワークロード層９０は、クラウド・コンピューティング環境を利用することができる機能の例を提供する。この層から提供することができるワークロード及び機能の例には、マッピング及びナビゲーション９１、ソフトウェア開発及びライフサイクル管理９２、仮想教室教育配信９３、データ分析処理９４、トランザクション処理９５、及びスタック保護処理９６が含まれる。

【0120】

本発明の実施形態は、方法、装置（システム）及びコンピュータ・プログラム製品のフローチャート図及び／又はブロック図を参照して説明される。フローチャート図及び／又はブロック図の各ブロック、並びにフローチャート図及び／又はブロック図内のブロックの組み合わせは、コンピュータ可読プログラム命令によって実装できることが理解されるであろう。

【0121】

これらのコンピュータ可読プログラム命令を、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能データ処理装置のプロセッサに与えてマシンを製造し、それにより、コンピュータ又は他のプログラム可能データ処理装置のプロセッサによって実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロック内で指定された機能／動作を実施するための手段を作り出すようにすることができる。これらのコンピュータ・プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、又は他のデバイスを特定の方式で機能させるように指示することができるコンピュータ可読媒体内に格納し、それにより、そのコンピュータ可読媒体内に格納された命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実施する命令を含む製品を製造するようにすることもできる。

【0122】

コンピュータ・プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、又は他のデバイス上にロードして、一連の動作ステップをコンピュータ、他のプログラム可能データ処理装置、又は他のデバイス上で行わせてコンピュータ実施のプロセスを生成し、それにより、コンピュータ又は他のプログラム可能装置上で実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実行するためのプロセスを提供するようにすることもできる。

【0123】

図面内のフローチャート及びブロック図は、本発明の種々の実施形態による、システム、方法、及びコンピュータ・プログラム製品の可能な実装の、アーキテクチャ、機能及び動作を示す。この点に関して、フローチャート内の各ブロックは、指定された論理機能を実装するための１つ又は複数の実行可能命令を含む、モジュール、セグメント、又はコードの一部を表すことができる。幾つかの代替的な実装において、ブロック内に示される機能は、図に示される順序とは異なる順序で生じることがある。例えば、連続して示される２つのブロックは、関与する機能に応じて、実際には実質的に同時に実行されることもあり、又はこれらのブロックはときとして逆順で実行されることもある。ブロック図及び／又はフローチャート図の各ブロック、及びブロック図及び／又はフローチャート図内のブロックの組み合わせは、指定された機能又は動作を実行する、又は専用のハードウェアとコンピュータ命令との組み合わせを実行する、専用ハードウェア・ベースのシステムによって実装できることにも留意されたい。

【0124】

上記に加えて、１つ又は複数の態様は、顧客環境の管理を提供するサービス・プロバイダによって供与、提供、配置、管理、サービス等を行うことができる。例えば、サービス・プロバイダは、１又は複数の顧客のために１つ又は複数の態様を実施するコンピュータ・コード及び／又はコンピュータ・インフラストラクチャの作成、保守、サポート等を行うことができる。見返りに、サービス・プロバイダは、例として、予約申し込み及び／又は報酬契約の下で顧客から支払いを受けることができる。付加的に又は代替的に、サービス・プロバイダは、１又は複数の第三者に対する広告内容の販売から支払いを受けることができる。

【0125】

一態様において、１つ又は複数の実施形態を実施するために、アプリケーションを配備することができる。一例として、アプリケーションの配備は、１つ又は複数の実施形態を実施するように動作可能なコンピュータ・インフラストラクチャを提供することを含む。

【0126】

更に別の態様として、コンピュータ可読コードをコンピュータ・システムに統合することを含む、コンピュータ・インフラストラクチャを配置することができ、そこでは、コードは、コンピューティング・システムと協働して、１つ又は複数の実施形態を実施することができる。

【0127】

更に別の態様として、コンピュータ可読コードをコンピュータ・システムに統合することを含む、プロセスを提供することができる。コンピュータ・システムは、コンピュータ可読媒体を含み、ここで、コンピュータ媒体は、１つ又は複数の実施形態を含む。コードは、コンピュータ・システムと協働して、１つ又は複数の実施形態を実施することができる。

【0128】

種々の実施形態が上述されたが、これらは例にすぎない。例えば、１つ又は複数の実施形態を組み込み、使用するために、他のアーキテクチャのコンピューティング環境を使用することもできる。さらに、異なる命令、命令形式、命令フィールド、及び／又は命令の値を使用することができる。多くの変形が可能である。

【0129】

さらに、他のタイプのコンピューティング環境の利益を得、これを使用することができる。一例として、プログラム・コードを格納及び／又は実行するのに適しており、システム・バスを介してメモリ要素に直接又は間接的に結合された少なくとも２つのプロセッサを含む、データ処理システムを使用することができる。メモリ要素は、例えば、プログラム・コードの実際の実行中に用いられるローカル・メモリ、大容量記憶装置、及び実行中に大容量記憶装置からコードを取り出さなければならない回数を減らすために少なくとも幾つかのプログラム・コードの一時的なストレージを提供するキャッシュ・メモリを含む。

【0130】

入力／出力即ちＩ／Ｏデバイス（これらに限定されるものではないが、キーボード、ディスプレイ、ポインティング・デバイス、ＤＡＳＤ、テープ、ＣＤ、ＤＶＤ、サムドライブ及び他のメモリ媒体等）は、直接システムに結合することもでき、又は介在するＩ／Ｏコントローラを介してシステムに結合することができる。ネットワーク・アダプタをシステムに結合させて、データ処理システムが、介在する私的ネットワーク又は公衆ネットワークを通じて他のデータ処理システム又は遠隔プリンタ若しくはストレージ・デバイスに結合できるようにすることもできる。モデム、ケーブル・モデム及びイーサネット・カードは、ネットワーク・アダプタの利用可能なタイプのうちのほんの数例である。

【0131】

本明細書で用いられる用語は、特定の実施形態を説明する目的のためのものにすぎず、本発明を限定することを意図したものではない。本明細書で用いられる場合、単数形「１つの（a）」、「１つの（an）」及び「その（the）」は、文脈が特に明示しない限り、複数形も同様に含むことを意図したものである。「含む（comprise）」及び／又は「含んでいる（comprising）」という用語は、本明細書で用いられる場合、記述された特徴、整数、ステップ、動作、要素、及び／又はコンポーネントの存在を指示するが、１つ又は複数の他の特徴、整数、ステップ、動作、要素、コンポーネント、及び／又はそれらの群の存在又は追加を排除するものではないこともさらに理解されるであろう。

【0132】

以下の特許請求の範囲に存在する場合、「手段又はステップと機能との組合せ（ミーンズ又はステップ・プラス・ファンクション）」要素の対応する構造、材料、動作及び均等物は、明確に特許請求された他の請求要素と共に機能を実行するための任意の構造、材料、又は行為を含むことを意図したものである。本発明の説明は、例証及び説明のためだけに提示されたものであり、網羅的であること又は本発明を開示した形態に限定することを意図したものではない。当業者には、本発明の範囲から逸脱しない多くの修正物及び変形物が明らかとなるであろう。実施形態は、本発明の原理及び実際の用途を最もよく説明するため、及び、当業者が、企図した特定の用途に適するように種々の修正を有する種々の実施形態に関して本発明を理解することができるように、選択され記述された。

【符号の説明】

【0133】

５０：クラウド・コンピューティング環境
６０：ハードウェア及びソフトウェア層
７０：仮想化層
８０：管理層
９０：ワークロード層
１００、２００：コンピューティング環境
１０２：コンピュータ・システム／サーバ
１０６：プロセッサ
１０８、２０４：メモリ
１１０、２０８：バス
１５０：ネットワーク・アダプタ
１６０：スタック破損検出論理
２０２：ネイティブ中央演算処理ユニット
２１２：エミュレータ・コード
３００：スタック
３０２ａ、３０２ｂ、４００、４２０：スタックフレーム
３０４、４０２：スタック・ポインタ
３０６：パラメータ領域
３０８：ローカル及びスピル変数領域
３１０：バッファ
３１２：レジスタ保存領域
３１４、４０６：リターンアドレス
４０４：ガードワード
６００：Ｓｔｏｒｅ Ｇｕａｒｄ Ｗｏｒｄ命令
６０２：アドレス
７００：ガードワード・レジスタ
８００：ＰＯＰＣＨＥＣＫ命令

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】