特許 6204479 安全なドメインとより安全性の低いドメインの間で切り替えるときに安全ではないアクセスから安全なデータ及びプログラム・コードを保護するためのデータ処理装置及び方法

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

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

(11)【特許番号】6204479

(24)【登録日】2017年9月8日

(45)【発行日】2017年9月27日

(54)【発明の名称】安全なドメインとより安全性の低いドメインの間で切り替えるときに安全ではないアクセスから安全なデータ及びプログラム・コードを保護するためのデータ処理装置及び方法

(51)【国際特許分類】

   G06F 12/14 20060101AFI20170914BHJP

   G06F 9/42 20060101ALI20170914BHJP

   G06F 21/52 20130101ALI20170914BHJP

【ＦＩ】

   G06F12/14 510D

   G06F9/42 320B

   G06F9/42 380

   G06F21/52

【請求項の数】18

【全頁数】31

(21)【出願番号】特願2015-533680(P2015-533680)

(86)(22)【出願日】2013年8月7日

(65)【公表番号】特表2015-534186(P2015-534186A)

(43)【公表日】2015年11月26日

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

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

(87)【国際公開日】20140410

【審査請求日】2016年7月29日

(31)【優先権主張番号】1217531.1

(32)【優先日】2012年10月1日

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

(31)【優先権主張番号】13/680,352

(32)【優先日】2012年11月19日

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

(73)【特許権者】

【識別番号】594154428

【氏名又は名称】エイアールエム リミテッド

(74)【代理人】

【識別番号】110000855

【氏名又は名称】特許業務法人浅村特許事務所

(72)【発明者】

【氏名】グロカット、トーマス クリストファー

(72)【発明者】

【氏名】グリセンスウェイト、リチャード ロイ

(72)【発明者】

【氏名】クラスク、サイモン ジョン

【審査官】 金沢 史明

(56)【参考文献】

【文献】 特開２００８−２５７７３４（ＪＰ，Ａ）

【文献】 特開２００８−２５７７３５（ＪＰ，Ａ）

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

【文献】 特表２００１−５１１２７１（ＪＰ，Ａ）

【文献】 特表２００８−５３５０７２（ＪＰ，Ａ）

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

【文献】 Cortex-M3 テクニカルリファレンスマニュアル，ARM Limited，２００７年 ６月１３日，リビジョン：r1p1，pp.5-1 - 5-36，［２０１７年７月３１日検索］，インターネット，ＵＲＬ，http://infocenter.arm.com/help/topic/com.arm.doc.ddi0337ej/DDI0337ej_cortex_m3_trm.pdf

【文献】 セクション23. CodeGuardセキュリティ，Michrochip Technology Inc.，２０１１年 ３月３１日，pp.23-1 - 23-40，ＵＲＬ，http://ww1.microchip.com/downloads/jp/devicedoc/70199c_jp.pdf

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

Ｇ０６Ｆ １２／１４

Ｇ０６Ｆ ９／３０

Ｇ０６Ｆ ９／４２

Ｇ０６Ｆ ９／４６

Ｇ０６Ｆ １１／００

Ｇ０６Ｆ ２１／００

Ｇ０６Ｆ ２１／５２

Ｇ０６Ｆ ２１／６０

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

【請求項1】

データ処理装置であって、
プログラム・コードに応答してデータ処理動作を実行するように構成された処理回路と、
データを記憶するように構成されたデータ・ストアであって、前記データ・ストアが安全な領域及びより安全性の低い領域を含む複数の領域を備え、前記安全な領域が、安全なドメインで動作するときに前記処理回路によってアクセス可能であり、より安全性の低いドメインで動作するときに前記処理回路によってアクセス可能でない極秘データを記憶するように構成された、データ・ストアと
を備え、前記データ・ストアが、前記安全な領域内の安全なスタックを含む複数のスタックを備え、
前記処理回路が、前記安全なドメインから前記より安全性の低いドメインへの遷移を必要とする事象に応答して前記安全なスタックに所定の処理状態を記憶するように構成されたスタック・アクセス回路を含み、
前記事象が第１の事象タイプである場合に、前記スタック・アクセス回路によって記憶される前記所定の処理状態が、前記安全なスタックで所定の相対的位置に記憶された少なくとも１つの戻りアドレスを含み、
前記事象が第２の事象タイプである場合に、前記スタック・アクセス回路によって記憶される前記所定の処理状態が、前記所定の相対的位置で記憶された少なくとも１つの第１の値を含み、前記第１の値はプログラム・コードの有効なアドレスではなく、そして、
前記処理回路がさらに、前記より安全性の低いドメインから前記安全なドメインへの第１の事象タイプの戻りの受信時に前記所定の相対的位置で記憶された前記データが前記第１の値である場合に第１の障害条件を識別するように構成された障害チェック回路を備える、データ処理装置。

【請求項2】

前記第１の事象タイプが関数呼出しであり、前記第２の事象タイプが例外である、請求項１に記載のデータ処理装置。

【請求項3】

前記事象が前記第１の事象タイプである場合に、前記処理回路が、前記第１の事象タイプを処理するために使用される前記より安全性の低いドメイン内の前記プログラム・コードにダミー戻りアドレスを提供するように構成され、前記ダミー戻りアドレスは、プログラム・コードの有効なアドレスではなく、
前記第１の事象タイプを処理するために使用される前記より安全性の低いドメイン内の前記プログラム・コードの完成時に、前記ダミー戻りアドレスが、前記戻りアドレスを前記安全なスタックからフェッチさせる、請求項１及び２のいずれか一項に記載のデータ処理装置。

【請求項4】

前記事象が例外である場合に、前記スタック・アクセス回路によって記憶される前記所定の処理状態が所定の署名を含み、
前記障害チェック回路が、前記より安全性の低いドメインから前記安全なドメインへの例外戻りの受信時に前記所定の署名が前記スタック・アクセス回路によって記憶された前記所定の処理状態内に存在しない場合に第２の障害条件を識別するように構成された、請求項２に記載のデータ処理装置。

【請求項5】

前記第１の障害条件及び第２の障害条件の両方が、前記所定の署名を使用して検出可能となるように、前記所定の署名が、前記所定の相対的位置で記憶された前記第１の値を形成する、請求項４に記載のデータ処理装置。

【請求項6】

前記事象が関数呼出しである場合に、前記処理回路が、前記関数呼出しによって識別される前記より安全性の低いドメイン内の前記プログラム・コードにダミー関数呼出し戻りアドレスを提供するように構成され、前記ダミー関数呼出し戻りアドレスが、プログラム・コードの有効なアドレスではないアドレスの範囲から選択され、そして、
前記所定の署名が、前記ダミー関数呼出し戻りアドレスとは異なる値を有する、請求項４及び５のいずれか一項に記載のデータ処理装置。

【請求項7】

前記事象が例外である場合に、前記処理回路が、前記例外を処理するために使用される前記より安全性の低いドメイン内の前記プログラム・コードにダミー例外戻りアドレスを提供するように構成され、前記ダミー例外戻りアドレスが、プログラム・コードの有効なアドレスではないアドレスの範囲から選択され、そして、
前記所定の署名が、前記ダミー例外戻りアドレスとは異なる値を有する、請求項４、５及び６のいずれか一項に記載のデータ処理装置。

【請求項8】

前記処理回路が、前記第２の障害条件に応答して前記安全なドメイン内で障害処理プログラム・コードを実行する、請求項４から７までのいずれか一項に記載のデータ処理装置。

【請求項9】

前記例外戻りの繰り返しが再び、前記第２の障害条件が識別される原因となるように、前記第２の障害条件が識別された場合にスタック・ポインタ値が調節されない、請求項４から８までのいずれか一項に記載のデータ処理装置。

【請求項10】

前記所定の相対的位置が、前記スタック・アクセス回路によって使用されるスタック・フレーム内の所定の位置である、請求項１から９までのいずれか一項に記載のデータ処理装置。

【請求項11】

前記所定の位置が、前記スタック・フレームの下部の位置である、請求項１０に記載のデータ処理装置。

【請求項12】

前記処理回路が、前記第１の障害条件に応答して前記安全なドメイン内で障害処理プログラム・コードを実行する、請求項１から１１までのいずれか一項に記載のデータ処理装置。

【請求項13】

前記第１の事象タイプの戻りの繰り返しが再び、前記第１の障害条件が識別される原因となるように、前記第１の障害条件が識別された場合にスタック・ポインタ値が調整されない、請求項１から１２までのいずれか一項に記載のデータ処理装置。

【請求項14】

前記安全なスタックの初期化時に、第２の値が前記安全なスタックの前記所定の相対的位置で記憶され、前記第２の値が、前記第１の値とは異なり、またプログラム・コードの有効なアドレスではなく、そして、
前記障害チェック回路が、前記所定の相対的位置で記憶された前記データが前記第２の値である場合に、前記より安全性の低いドメインから前記安全なドメインへの戻りの受信時に第３の障害条件を識別するように構成された、請求項１から１３までのいずれか一項に記載のデータ処理装置。

【請求項15】

複数のレジスタをさらに備え、
前記事象が例外である場合に、前記スタック・アクセス回路によって記憶される前記所定の処理状態がさらに、少なくとも１つのサブセットの前記レジスタの内容を含む、
請求項１から１４までのいずれか一項に記載のデータ処理装置。

【請求項16】

前記複数のスタックがさらに、前記より安全性の低い領域内のより安全性の低いスタックを備え、そして、
前記処理回路が、バックグラウンド処理が実行されていた前記ドメインに基づいて、どのスタックにデータを記憶するか、又はどのスタックからデータをロードするかを判定するように構成された、請求項１から１５までのいずれか一項に記載のデータ処理装置。

【請求項17】

データ処理装置でデータを処理する方法であって、前記データ処理装置が、プログラム・コードに応答してデータ処理動作を実行するための処理回路と、データを記憶するためのデータ・ストアとを備え、前記データ・ストアが、安全な領域及びより安全性の低い領域を含む複数の領域を備え、前記安全な領域が、安全なドメインで動作するときに前記処理回路によってアクセス可能であり、より安全性の低いドメインで動作するときに前記処理回路によってアクセス可能でない極秘データを記憶するように構成され、前記データ・ストアが、前記安全な領域内の安全なスタックを含む複数のスタックを備え、
前記安全なドメインから前記より安全性の低いドメインへの遷移を必要とする事象に応答して所定の処理状態を前記安全なスタックに記憶するステップと、
前記事象が第１の事象タイプである場合に、前記安全なスタックで所定の相対的位置に記憶された少なくとも１つの戻りアドレスを前記所定の処理状態として記憶するステップと、
前記事象が第２の事象タイプである場合に、前記所定の相対的位置で記憶された少なくとも１つの第１の値であって、プログラム・コードの有効なアドレスではない前記第１の値を前記所定の処理状態として記憶するステップと、
前記より安全性の低いドメインから前記安全なドメインへの第１の事象タイプの戻りの受信時に、前記所定の相対的位置で記憶された前記データが前記第１の値である場合に、第１の障害条件を識別するステップと
を含む、方法。

【請求項18】

プログラム・コードに応答してデータ処理動作を実行するためのデータ処理手段と、
データを記憶するためのデータ記憶手段であり、前記データ記憶手段が、安全な領域及びより安全性の低い領域を含む複数の領域を備え、前記安全な領域が、安全なドメインで動作するときに前記データ処理手段によってアクセス可能であり、より安全性の低いドメインで動作するときに前記データ処理手段によってアクセス可能でない極秘データを記憶するように構成された、データ記憶手段と
を備えるデータ処理装置であって、前記データ記憶手段が、前記安全な領域内の安全なスタックを含む複数のスタックを備え、
前記処理手段が、前記安全なドメインから前記より安全性の低いドメインへの遷移を必要とする事象に応答して所定の処理状態を前記安全なスタックに記憶するためのスタック・アクセス手段を含み、
前記事象が第１の事象タイプである場合に、前記スタック・アクセス手段によって記憶される前記所定の処理状態が、前記安全なスタックで所定の相対的位置に記憶された少なくとも１つの戻りアドレスを含み、
前記事象が第２の事象タイプである場合に、前記スタック・アクセス手段によって記憶される前記所定の処理状態が、前記所定の相対的位置で記憶された少なくとも１つの第１の値であり、プログラム・コードの有効なアドレスではない前記第１の値を含み、そして、
前記処理手段がさらに、前記より安全性の低いドメインから前記安全なドメインへの第１の事象タイプの戻りの受信に応答する、前記所定の相対的位置で記憶された前記データが前記第１の値である場合に第１の障害条件を識別するための障害チェック手段を備える、データ処理装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データ処理の分野に関し、詳細には、安全なドメイン及びより安全性の低いドメインを有するデータ処理に関する。

【背景技術】

【0002】

多数のデータ処理システム及びアーキテクチャが、極秘データ及びコードのセクションを不正な人又はプロセスによるアクセスから隔離及び保護する方法を提供する。セキュリティを提供することができることは重要であるが、この保護に関連するパフォーマンス及び回路領域におけるオーバヘッドが存在する。

【0003】

マイクロコントローラなどの小さなシステムにおいて、これらのオーバヘッドが低く保たれることは非常に重要であり、したがって、セキュリティのレベルとパフォーマンスの間の何らかの妥協が行われる必要があることがある。

【0004】

データ及びコードを安全に保つ１つの方法が、英国ケンブリッジのＡＲＭ（登録商標）によって、同社のＴｒｕｓｔｚｏｎｅアーキテクチャで提供され、Ｔｒｕｓｔｚｏｎｅアーキテクチャでは、安全な状態及び安全ではない状態が存在し、安全な側のセキュリティを保護するソフトウェア・ハンドラがそれらの状態間の遷移に使用される。本手法は、高度なセキュリティを実現するが、すべての呼出しがソフトウェア・ハンドラを介してプロキシされる必要があるので、ソフトウェア・ハンドラの形でのかなりのソフトウェア介入が、セキュリティ状態を変更するために必要とされ、システムのパフォーマンスを低減するとともに、安全なソフトウェアのための外部アプリケーション・プログラム・インターフェースＡＰＩを開発するために必要とされる労力を増やす。同様に、安全ではないドメインにおける処理を必要とする安全なドメインにある間に生じる例外もまた、安全な例外ハンドラを介してプロキシされる必要があり、これが、制御が安全ではない例外ハンドラに移動する前に安全な状態が保護されることを可能にする。

【0005】

米国特許第７９６６４６６号及び米国特許出願公開第２００８／０２５０２１６号は、データ・ストアが安全な側及び安全ではない側を有し、現在実行されているコードのこのデータ・ストア内の位置が、プロセッサが動作しているドメイン、及び、したがってアクセスすることが許されるデータを決定する、代替の安全なシステムを開示する。

【0006】

安全な状態を含む多数のシステム・アーキテクチャは、これが安全な状態でデータ及びプログラム・コードのセキュリティを保護するタスクを簡略化するため、（通常は、例外の使用によって）状態間で遷移するための１つの機構のみを許容する。しかし、速度及び効率の向上を目的として、安全な状態とより安全性の低い状態の間で遷移するための複数の機構を提供することもまた可能である。たとえば、Ｍｉｃｒｏｃｈｉｐ Ｔｅｃｈｎｏｌｏｇｙ Ｉｎｃ．によって開発されたＣｏｄｅＧｕａｒｄシステムは、セキュリティ状態間で遷移するための機構として例外及び直接関数呼出しの両方を可能にする。しかし、状態間で遷移するための複数の機能の使用は、たとえば、より安全性の低い状態のソフトウェアが、安全な状態からより安全性の低い状態に遷移するために使用される最初の機構とは異なるタイプである戻り機構を介して安全な状態に戻ろうとすることを（たとえば、例外から戻るための関数呼出し戻り、又は関数呼出しから戻るための例外戻りを使用することによって）可能にし、悪意ある攻撃に対する脆弱性を増大させる。

【先行技術文献】

【特許文献】

【0007】

【特許文献1】米国特許第７９６６４６６号

【特許文献2】米国特許出願公開第２００８／０２５０２１６号

【0008】

（発明の概要）
第１の態様から見ると、本発明はデータ処理装置を提供し、前記データ処理装置は以下を備える：プログラム・コードに応答してデータ処理動作を実行するように構成された処理回路、データを記憶するように構成されたデータ・ストア、前記データ・ストアは、安全な領域及びより安全性の低い領域を含む複数の領域を備え、その安全な領域は、安全なドメインで動作するときに前記処理回路によってアクセス可能であり、より安全性の低いドメインで動作するときに前記処理回路によってアクセス可能でない極秘データを記憶するように構成され、前記データ・ストアは、前記安全な領域内の安全なスタックを含む複数のスタックを備え、その処理回路は安全なドメインからより安全性の低いドメインへの遷移を必要とする事象に応答して安全なスタックに所定の処理状態を記憶するように構成されたスタック・アクセス回路を含み、前記事象が第１の事象タイプである場合には、スタック・アクセス回路によって記憶される所定の処理状態は、安全なスタックで所定の相対的位置に記憶された少なくとも１つの戻りアドレスを含み、その事象が第２の事象タイプである場合には、スタック・アクセス回路によって記憶される所定の処理状態は、前記所定の相対的位置で記憶された少なくとも１つの第１の値を含み、前記第１の値はプログラム・コードの有効なアドレスではなく、そして、その処理回路は、より安全性の低いドメインから安全なドメインへの第１の事象タイプの戻りの受信時に前記所定の相対的位置で記憶されたデータが前記第１の値である場合に第１の障害条件を識別するように構成された障害チェック回路をさらに備える。

【0009】

本発明によれば、複数の事象タイプが安全なドメインとより安全性の低いドメインの間の遷移を引き起こすことが可能にされる。事象が、安全なドメインからより安全性の低いドメインへの遷移を必要とする場合、スタック・アクセス回路は、より安全性の低いドメインへの遷移が起こる前に安全なスタックである種の所定の処理状態を記憶するように構成される。その所定の処理状態として安全なスタックで記憶されるものは、事象タイプに依存することになり、より安全性の低いプログラム・コードが、異なる事象タイプに関連する戻りを使用し、安全なドメインに戻ろうとする場合には、これが検出されることを確実にするように選択される。

【0010】

具体的には、安全なドメインからより安全性の低いドメインへの遷移を引き起こす事象が第１の事象タイプである場合、スタック・アクセス回路が安全なスタックで記憶する所定の処理状態は、少なくとも１つの戻りアドレスを含み、その戻りアドレスは安全なスタックで所定の相対的位置に記憶される（たとえば、所定の処理状態を記憶するためにスタック・アクセス回路によって使用されるスタック・フレームの下部の入力で、又は、その下部の入力に関連する何らかの所定のオフセットで）。

【0011】

同様に、事象が第２の事象タイプである場合、その事象においてスタック・アクセス回路によって記憶される所定の処理状態は、その所定の相対的位置で記憶される少なくとも１つの第１の値を含む。

【0012】

第１の事象タイプの戻りが、その後、より安全性の低いドメインから安全なドメインに受信される場合、障害チェック回路は、所定の相対的位置からデータを検索することになる。第１の事象タイプの戻りが使用されているので、その場合、その所定の相対的位置は、スタック・アクセス回路によって前に記憶された戻りアドレスを記憶するはずである。しかし、そうではなくて、それが第１の値を記憶する場合、これは、安全なドメインからより安全性の低いドメインへの最初の遷移が第２の事象タイプによったという事実にかかわらず、より安全性の低いプログラム・コードが第１の事象タイプの戻りを介して戻ろうとしているシナリオを示し、この状況で、障害チェック回路は、第１の障害条件を識別することになり、したがって、そのような活動にフラグを立てる。したがって、この機構は、安全なドメインからより安全性の低いドメインへの遷移を前に引き起こした事象タイプを前提として使用されるべきものではなくて安全なドメインへの異なる事象タイプの戻りを使用することによって安全なコードへの任意の分岐を間接的に実行しようとすることを含む、様々な攻撃を悪意のあるユーザが行なうのを防ぐ。

【0013】

第１の事象タイプ及び第２の事象タイプは、様々な形をとり得る。しかし、一実施例で、第１の事象タイプは関数呼出しであり、そして、第２の事象タイプは例外である。したがって、前述の機構は、安全なドメインからより安全性の低いドメインへの例外分岐に続いて安全なドメインへの関数呼出し戻りを実行しようと試みる悪意のある攻撃が防がれることになることを確実にすることになる。

【0014】

一実施例で、事象が前記第１の事象タイプである場合、処理回路は、前記第１の事象タイプを処理するために使用される前記より安全性の低いドメイン内のプログラム・コードにダミー戻りアドレスを提供するように構成され、そのダミー戻りアドレスはプログラム・コードの有効なアドレスではない。次いで、前記第１の事象タイプを処理するために使用されるより安全性の低いドメイン内のプログラム・コードを完成するときに、そのダミー戻りアドレスが、前記戻りアドレス（すなわち、実際の戻りアドレス）が安全なスタックからフェッチされるようにする。具体的には、ダミー戻りアドレスを見るとき、スタック・アクセス回路は安全なスタックから所定の相対的位置で保持されたデータをロードするように構成され、したがって、障害チェック回路は、そのデータが予期された戻りアドレスを指定するか、或いはそうではなくて障害条件を示す前述の第１の値であるかをチェックすることができる。

【0015】

一実施例で、ダミー戻りアドレスはまた、事象が安全なドメインからより安全性の低いドメインへの遷移を引き起こすときに、その後の戻り（そのダミー戻りアドレスを使用する）が安全なドメインに戻る遷移を引き起こすことになることを確実にするために使用することができ、したがって、障害チェック回路が所望のチェックを実行できるようにする。

【0016】

一実施例で、事象が例外である場合、スタック・アクセス回路によって記憶される所定の処理状態は所定の署名を含み、そして、障害チェック回路は、より安全性の低いドメインから安全なドメインへの例外戻りの受信時に所定の署名がスタック・アクセス回路によって記憶される所定の処理状態内に存在しない場合には第２の障害条件を識別するように構成される。

【0017】

そのような手法によって、例外戻りが、関数呼出しを介して起こる安全なドメインからより安全性の低いドメインへの遷移に続いてより安全性の低いドメインから発行される場合、そのとき、スタック・アクセス回路によって安全なスタックで記憶された所定の処理状態は、その所定の署名を含まないことになり、したがって、これは、不正な戻りを使用する企てられた攻撃を示すことになる。

【0018】

所定の署名は、安全なスタック内の任意の適切な位置に置くことができ、任意の所望の形をとることができる。しかし、特に効率的な一実施例で、所定の署名は、所定の相対的位置で記憶された前述の第１の値を形成する。結果として、その単一の所定の署名は、第１の障害条件及び第２の障害条件の両方が障害チェック回路によって検出可能になることを可能にする。

【0019】

一実施例で、事象が関数呼出しである場合、処理回路は、前記関数呼出しによって識別される前記より安全性の低いドメインのプログラム・コードにダミー関数呼出し戻りアドレスを提供するように構成され、そのダミー関数呼出し戻りアドレスはプログラム・コードの有効なアドレスではない範囲のアドレスから選択され、そして、前記所定の署名は前記ダミー関数呼出し戻りアドレスとは異なる値を有する。所定の署名がダミー関数呼出し戻りアドレスとは異なる値を有することを確実にすることによって、実行されることになる必要なアクションは分析されている値のみから判定することができ、その値が関数呼出し戻りに由来するか又はスタックから読み取られたかとは無関係であるので、これは、処理回路の実装を簡略化する。

【0020】

別法として、又は追加で、事象が例外である場合、処理回路は、前記例外を処理するために使用される前記より安全性の低いドメイン内のプログラム・コードにダミー例外戻りアドレスを提供するように構成され、そのダミー例外戻りアドレスはプログラム・コードの有効なアドレスではないアドレスの範囲から選択され、そして、前記所定の署名は前記ダミー例外戻りアドレスとは異なる値を有する。さらに、実装の効率性が、所定の署名をダミー例外戻りアドレスとは異なるようにすることによって、実現され得る。

【0021】

一実施例で、所定の相対的位置は、スタック・アクセス回路によって使用されるスタック・フレーム内の所定の位置である。その位置は、原則として、スタック・フレーム内の任意の位置でもよいが、一実施例では、所定の位置は、スタック・フレームの下部の位置、すなわちスタック・ポインタによって指される位置、である。

【0022】

第１の障害条件が生じさせられた後にはそれが処理され得る、いくつかの方法が存在する。しかし、一実施例では、処理回路は、前記第１の障害条件に応答して前記安全なドメイン内で障害処理プログラム・コードを実行する。障害処理プログラム・コードが安全なドメイン内で実行されることを確実にすることによって、これは、より安全性の低いドメインの攻撃者が制御を取り戻すことを防ぎ、その結果、攻撃を再試行するのを防ぐ。

【0023】

攻撃の再試行を阻止するための代替機構として、第１の事象タイプの戻りの繰り返しもまた前記第１の障害条件が識別されるように、データ処理装置は、前記第１の障害条件が識別される場合にスタック・ポインタ値が調整されないように構成され得る。その結果、スタック・ポインタを調整しないことによって、攻撃者は、安全なスタックの最後の位置を単に破壊し、次いで安全なスタック内の異なる場所で入力するために攻撃を再試行することはできない。

【0024】

一実施例で、前述の機構は両方とも、より安全性の低いドメインからの攻撃の再試行に対する頑強性を実現するために使用することができる。前述の機構は、第１の障害条件の処理に関して説明されたが、それらはまた、第２の障害条件の処理にも同等に適用され得る。

【0025】

一実施例で、安全ではないドメインからの潜在的攻撃を生じさせ得るもう１つのシナリオが、安全なスタックの初期化に続いて生じる。この時点で、安全なスタックは空であることになる。その時に、実行されているプログラム・コードがより安全性の低いドメイン内である場合、そのプログラム・コードが安全なドメインに戻ろうと試み得ることが起こり得る。合法的にそこから戻られることになる安全なドメインからより安全性の低いドメインへの元の遷移は存在しないので、そのような戻りは防がれるべきである。一実施例で、データ処理装置は、安全なスタックの初期化時に、第２の値が安全なスタックで前記所定の相対的位置で記憶され、前記第２の値が前記第１の値とは異なり、プログラム・コードの有効なアドレスではないことを確実にすることによって、そのようなシナリオからの保護を実現する。障害チェック回路は、その場合、より安全性の低いドメインから安全なドメインへの戻りの受信時に、前記所定の相対的位置で記憶されたデータが前記第２の値である場合に第３の障害条件を識別するように構成される。本実施例によれば、より安全性の低いドメインからの戻りは、安全なスタックで所定の相対的位置に記憶されたデータを障害チェック回路にロードさせることになり、本シナリオでは、そのデータは前述の第２の値を識別することになり、第３の障害条件を検出させる。第３の障害条件の処理は、第１の障害条件及び第２の障害条件について前述したのと同じ方法で、攻撃の再試行もまた防がれることを確実にしつつ、行われ得る。

【0026】

一実施例で、第３の障害条件は第１の障害条件と同じであり、したがって、同じ障害処理コードがこれらの障害条件の両方に使用される。したがって、そのような実施例では、障害チェック回路が第１の値と第２の値を区別する必要はない。

【0027】

一実施例で、データ処理装置は複数のレジスタをさらに備え、事象が例外である場合、スタック・アクセス回路によって記憶される所定の処理状態は、少なくとも１つのサブセットの前記レジスタの内容をさらに備える。１つの特定の実施例で、その内容がスタック・アクセス回路によって記憶されるレジスタの数は、例外が安全なドメインによって処理されることになるか又はより安全性の低いドメインによって処理されることになるかに依存することになる。

【0028】

一実施例で、その複数のスタックは、前記より安全性の低い領域内のより安全性の低いスタックをさらに含み、そして、処理回路は、バックグラウンド処理が実行されていたドメインに基づいて、どのスタックにデータを記憶するか、又はどのスタックからデータをロードするかを判定するように構成される。本願で、「バックグラウンド処理」という用語は、関数呼出し又は例外によって中断された処理を示すために使用される。少なくとも例外では、より優先度の高い例外が既に処理中のより優先度の低い例外に割り込むことが可能である。したがって、例外処理ルーチン自体が、より優先度の高い例外（本明細書では先制する例外という）によって割り込まれた場合、次いで、割り込まれた例外処理ルーチン自体は、先制する例外の「バックグラウンド処理」になり得る。

【0029】

第２の態様から見ると、本発明は、データ処理装置でデータを処理する方法を提供し、前記データ処理装置は、プログラム・コードに応答してデータ処理動作を実行するための処理回路と、データを記憶するためのデータ・ストアとを備え、前記データ・ストアは安全な領域及びより安全性の低い領域を含む複数の領域を備え、安全な領域は、安全なドメインで動作するときに前記処理回路によってアクセス可能であり、より安全性の低いドメインで動作するときに前記処理回路によってアクセス可能でない極秘データを記憶するように構成され、前記データ・ストアは、前記安全な領域内の安全なスタックを含む複数のスタックを備え、そして、前記方法は、以下を含む：安全なドメインからより安全性の低いドメインへの遷移を必要とする事象に応答して所定の処理状態を安全なスタックに記憶するステップと、前記事象が第１の事象タイプである場合に、安全なスタックで所定の相対的位置に記憶された少なくとも１つの戻りアドレスを所定の処理状態として記憶するステップと、その事象が第２の事象タイプである場合に、前記所定の相対的位置で記憶された少なくとも１つの第１の値を所定の処理状態として記憶するステップであって、前記第１の値がプログラム・コードの有効なアドレスではないステップと、より安全性の低いドメインから安全なドメインへの第１の事象タイプの戻りの受信時に、前記所定の相対的位置で記憶されたデータが前記第１の値である場合に第１の障害条件を識別するステップ。

【0030】

第３の態様から見ると、本発明は、データ処理装置を提供し、前記データ処理装置は、以下を備える：プログラム・コードに応答してデータ処理動作を実行するための処理手段、データを記憶するためのデータ記憶手段、前記データ記憶手段は安全な領域及びより安全性の低い領域を含む複数の領域を備え、その安全な領域が、安全なドメインで動作するときに前記処理手段によってアクセス可能であり、より安全性の低いドメインで動作するときに前記処理手段によってアクセス可能でない極秘データを記憶するように構成され、前記データ記憶手段が、前記安全な領域内の安全なスタックを含む複数のスタックを備え、その処理手段は、安全なドメインからより安全性の低いドメインへの遷移を必要とする事象に応答して所定の処理状態を安全なスタックに記憶するためのスタック・アクセス手段を含み、前記事象が第１の事象タイプである場合には、スタック・アクセス手段によって記憶される所定の処理状態が、安全なスタックで所定の相対的位置に記憶された少なくとも１つの戻りアドレスを含み、その事象が第２の事象タイプである場合には、スタック・アクセス手段によって記憶される所定の処理状態が、前記所定の相対的位置で記憶された少なくとも１つの第１の値であって、プログラム・コードの有効なアドレスではない前記第１の値を含み、そして、その処理手段はさらに、より安全性の低いドメインから安全なドメインへの第１の事象タイプの戻りの受信に応答して前記所定の相対的位置で記憶されたデータが前記第１の値である場合に第１の障害条件を識別するための障害チェック手段を備える。

【図面の簡単な説明】

【0031】

【図1】安全な及び安全ではない領域を有するデータ・ストアを有する、一実施例によるデータ処理装置を示す図である。

【図2】一実施例によるメモリ・アドレス空間を概略的に示す図である。

【図3A】記載の実施例の技法がそれに対する保護を提供することを目指す攻撃シナリオを示す図である。

【図3B】記載の実施例の技法がそれに対する保護を提供することを目指す異なる攻撃シナリオを示す図である。

【図4A】一実施例による関数呼出し又は例外の受信時の安全なスタックでの所定の処理状態の記憶を概略的に示す図である。

【図4B】様々なシナリオの所定の処理状態の形を示す図である。

【図5】関数呼出しの受信時の一実施例での処理回路の動作を示す流れ図である。

【図6】例外の受信時の一実施例での処理回路の動作を示す流れ図である。

【図7】分岐動作が関数呼出し戻り又は例外戻りである状況を含む、分岐動作を処理するときの一実施例での処理回路の動作を示す流れ図である。

【図8A】一実施例による、安全なスタックが初期化されるときにその安全なスタックで記憶された所定の署名がどのようにして使用されてより安全性の低いドメインから安全なコードに分岐しようとする不正な試みを防ぐことができるかを概略的に示す図である。

【図8B】一実施例による、安全なスタックが初期化されるときにその安全なスタックで記憶された所定の署名がどのようにして使用されてより安全性の低いドメインから安全なコードへの分岐しようとする不正な試みを防ぐことができるかを概略的に示す図である。

【図9】末尾連鎖式例外の連鎖を処理するときに状態保存及び復元動作を実行する一例を示す図である。

【図10】状態保存動作を制御するためのステータス情報を指示するための例外戻り値の部分の使用の一例を示す図である。

【図11】被発呼側レジスタの状態保存を実行する第１の例をより詳細に示す流れ図である。

【図12A】最初の例外の入力時に例外戻りアドレスを設定する一例を示す流れ図である。

【図12B】末尾連鎖式例外の入力時の例外戻りアドレスの設定の一例を示す流れ図である。

【図13】例外から戻るときに実行される状態復元の一例を示す流れ図である。

【図14】より詳細に例外戻り処理を示す流れ図である。

【図15】不必要な状態保存及び復元動作が、図１０に示すステータス情報を使用し、回避され得る例を示す図である。

【図16】不必要な状態保存及び復元動作が、図１０に示すステータス情報を使用し、回避され得る例を示す図である。

【図17】より高い優先度の例外によるより優先度の低い例外の先制の一例を示す図である。

【図18A】先制が状態保存の実行の途中で生じるときに、状態保存がどのようにして実行され得るかの例を示す図である。

【図18B】先制が状態保存の実行の途中で生じるときに、状態保存がどのようにして実行され得るかの例を示す図である。

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

【0032】

図１は、たとえばマイクロコントローラでもよいデータ処理装置１０を示す。それは、命令を処理するための処理回路２０と、処理回路２０によって処理されたデータを記憶するための、及びまたは処理回路２０が実行するプログラム・コードを記憶するためのデータ・ストア３０とを備える。

【0033】

データ・ストア３０は、異なるセキュリティの２つの領域、安全な領域３２及び安全ではない領域３４（本明細書では、より安全性の低い領域とも呼ばれる）、を有する。安全な領域３２で記憶されたデータは、それが実行しているときに安全ではない領域３４に記憶されたコードにアクセスすることはできない。

【0034】

データ処理装置１０はまた、安全な領域３２及び安全ではない領域３４へのアクセスを制御するメモリ保護ユニットＭＰＵ（ｍｅｍｏｒｙ ｐｒｏｔｅｃｔｉｏｎ ｕｎｉｔ）４０を有する。この制御はメモリ保護ユニットを介して実行され得るが、他の実施例では、それは、現在実行されている領域コードが記憶されることを監視する及びこれに基づいてそのメモリの異なる領域へのアクセスを制御する処理装置内の回路によって、より分散された形で行われ得る。

【0035】

この実施例では、処理回路２０が実行しているドメインのセキュリティは、現在実行されているコードが記憶された領域から判定することができる。したがって、安全なデータ・ストア３２に記憶された安全なプログラム・コードは、安全なドメインで実行され、安全なスタック３６を使用してデータ値を記憶する。同様に、安全ではないデータ・ストア３４に記憶された安全ではないコードは、安全ではないドメインで実行され、実行中にデータ値を記憶するために安全ではないスタック３８を使用する。動作中の現在のドメインを判定するための他の技法もまた、たとえば制御フロー変更命令に従ってどのドメインでプロセッサが動作すべきかを識別する目標ドメイン値に基づいて、可能である。

【0036】

処理回路２０は、実行されることになる命令をフェッチするためのフェッチ回路２２を有する。処理回路２０はまた、これらの命令を復号するための復号回路２４と、それらを実行するための実行回路２６とを有する。実行されることになる命令は、メモリ保護ユニットＭＰＵ４０を介してデータ・ストア３０からフェッチ回路２２によってフェッチされる。それらの命令及びデータは、安全な領域及び安全ではない領域へのアクセスを制御し、安全なデータを安全ではない側から隔離する、ＭＰＵ４０を介して検索される。

【0037】

本実施例では、データ処理中に使用される汎用レジスタを有するレジスタ・バンク６０が存在する。これらの汎用レジスタは、どの命令が次に実行されるものであるかを指示するプログラム・カウンタＰＣ（ｐｒｏｇｒａｍ ｃｏｕｎｔｅｒ）と、スタック内のどのポイントで次のデータ・アクセスが行われるべきかを指示するスタック・ポインタＳＰ（ｓｔａｃｋ ｐｏｉｎｔｅｒ）とを有する。本実施例では、安全な側のスタックと安全ではない側のスタックが存在するので、安全なスタック・ポインタＳＳＰ（ｓｅｃｕｒｅ ｓｔａｃｋ ｐｏｉｎｔｅｒ）と安全ではないスタック・ポインタＮＳＰ（ｎｏｎ−ｓｅｃｕｒｅ ｓｔａｃｋ ｐｏｉｎｔｅｒ）とが存在するが、これらのうちの１つのみがどの時点においても実行されているプログラムに直接に可視である。いくつかの実施例では、各スタックのための複数のスタック・ポインタが存在し得るが、やはりどの時点においても１つのみが可視であることになることに留意されたい。処理回路２０によって処理されているデータ値を記憶するためのレジスタ・バンク６０内の汎用レジスタもまた存在する。本実施例で、これらはＲ０からＲ１２の印を付される。

【0038】

レジスタ・バンク６０はまた、例外が取得される又は関数が呼び出されるときに戻り値を記憶するために使用され得るリンク・レジスタ６５を備える。戻り値は、システムが戻りが例外戻り又は関数戻りであるかどうかを判定すること及び例外又は関数から戻るときに何の処理が必要とされるかを判定することを可能にする。関数の完了に続いて処理されることになるプログラム命令のアドレスを指示する関数戻りアドレスと、実際の関数アドレスがより安全性の低いドメインからそれを隠すために安全なスタックに記憶された関数戻りを指示するダミー関数戻り値と、例外戻りを指示し、その例外戻りをどのように処理するか、たとえば、状態を復元するときにどのスタックにアクセスするか、及びいくつのレジスタがロードされる必要があるか、をプロセッサが判定することを可能にすることができる、バックグラウンド処理が処理されたドメインのセキュリティ・レベルの指示などの情報を含み得る、例外戻り（ＥＸＣ＿ＲＥＴＵＲＮ）値とを含む、異なる種類の戻り値が使用され得る。異なる形の戻り値が、後で説明されることになる。

【0039】

図１はまた、浮動小数点レジスタなどの追加の特定目的レジスタを有する追加のレジスタ・バンク６４を示す。一実施例で、値は、安全なコンフィギュレーション・レジスタ（ＳＣＲ：ｓｅｃｕｒｅ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｒｅｇｉｓｔｅｒ）６２で設定されて、追加のレジスタ・バンク６４内のレジスタのいずれかが安全なデータを記憶し得るかどうかを識別し、そうである場合、レジスタは、安全なドメインからより安全性の低いドメインへの及びその逆の遷移を制御するときに管理される必要がある１セットのレジスタの部分を（レジスタ・バンク６０のレジスタとともに）形成すると考えられることになる。

【0040】

安全なドメインからより安全性の低いドメインへの及びその逆の遷移を引き起こし得るいくつかの機構が存在する。記載の実施例によれば、セキュリティ・ドメイン間で遷移するための１つの許容される機構は、関数呼出し機構であり、それによって関数呼出しが発行されて、その関数呼出しによって識別される別のソフトウェア・ルーチンへの遷移を可能にするために、現在のソフトウェア・ルーチンの実行を一時的に停止させることができ、安全なドメイン又はより安全性の低いドメインのいずれかで実行されることになるこの他方のソフトウェア・ルーチンは、その他方のソフトウェア・ルーチンがデータ・ストア３０内のどこに記憶されるかに依存する。その他方のソフトウェア・ルーチンが実行された後には、次いで、関数呼出し戻りが、一時的に停止された最初のソフトウェア・ルーチンの実行に戻るために、実行される。いくつかの関数呼出しが、現在のソフトウェア・ルーチンと同じドメイン内で実行されることになる目標ソフトウェア・ルーチンを識別することになるが、他の例では、目標ソフトウェア・ルーチンは、現在のソフトウェア・ルーチンが実行しているドメインと異なるドメインでの実行を必要とし得る。

【0041】

前述の実施例によれば、セキュリティ・ドメイン間での遷移に使用され得るもう１つの機構は、例外機構である。この機構によれば、例外の発生時に、現在のソフトウェア・ルーチンの実行は、一時的に停止されることになり、その代わりに、実行は、例外を処理するために使用される例外処理ルーチンに分岐することになり、使用される例外処理ルーチンは、生じる例外のタイプに依存する。例外処理ルーチンが実行された後は、例外戻りが次いで使用されて、生じる例外の結果として一時的に停止された最初のソフトウェア・ルーチンに戻ることになる。

【0042】

例外制御回路２８が、例外の取得を制御するために提供され、これらの例外は、より安全なドメインからより安全性の低いドメインへの遷移をもたらし、極秘データを記憶することができるレジスタのセットは、これらのレジスタに記憶されたデータがより安全性の低い側に使用可能になるのを避けるために、その例外の取得に先立ってクリアされることになる。これらのレジスタのうちのいくつか又はすべてに記憶された状態は、例外から戻るときにその状態が復元され得るように、スタック・アクセス回路７０の制御の下で安全なスタックに記憶されることになる。例外処理を目的として、適切なスタックへのレジスタ内容の記憶を制御するために使用されるスタック・アクセス回路７０は、例外制御回路２８の部分を形成すると考えることができる。しかし、より一般的には、安全なドメインからより安全性の低いドメインへの遷移を必要とする関数呼出しの発生時に安全なスタックへの所定の処理状態の記憶に関連する何らかのスタック・アクセス回路７０もまた存在し、したがって、スタック・アクセス回路７０は、図１で例外制御回路２８に対して別個に識別される。

【0043】

さらに、図１に示すように、障害チェック回路７５が、より安全性の低いドメイン内のソフトウェアが安全なドメインからより安全性の低いドメインに遷移するために使用される最初の機構とは異なるタイプである戻り機構を介して安全なドメインに戻ろうとする（たとえば、例外から戻るための関数呼出し戻り、又は関数呼出しから戻るための例外戻りを使用することによって）状況を検出するために提供される。障害チェック回路７５の部分は、例外制御回路２８内に含まれる（すなわち、例外戻りをチェックする責任を有する部分）と考えることができるが、障害チェック回路７５の他の部分は、処理回路のハードウェア内の他の場所に分散することができる。たとえば、関数呼出し戻りをチェックする責任を有する部分は、一実施例で、フェッチ回路２２と関連付けられ得る。障害チェック回路７５の動作は、後でより詳細に論じられることになる。

【0044】

図１で、データ・ストア３０は単一の安全な領域及び単一のより安全性の低い領域を含むが、本明細書に記載の技法は、３つ以上の異なるセキュリティ領域を備える異なる実装形態にも同様に適用可能である。

【0045】

また、図１は、実行ステージ２６などの処理回路２０の他の部分とは別個なものとして例外制御回路２８及びスタック・アクセス回路７０を示すが、実際には、例外制御回路２８及びスタック・アクセス回路７０は、処理回路２０のいくつかの要素を少なくとも部分的に再使用して例外の処理及びスタック動作を制御することができる。

【0046】

図２は、一実施例で使用され得るメモリ・アドレス空間を概略的に示す。メモリ・アドレス空間１００は、分割されて１つ又は複数の安全な領域及び１つ又は複数のより安全性の低い領域を形成することになる。簡単にするために、図２では、単一の安全な領域及び単一のより安全性の低い領域が存在すると仮定される。安全なアドレス空間１０２の一部分が、安全なドメインで実行されることになるプログラム・コードの記憶のために確実にされることになる一方で、安全なアドレス空間１０４の別の部分は安全なスタック３６に割り当てられることになる。安全なアドレス空間１０６の残りは、たとえば、メモリ・ヒープとして、実行中に割り当てられる空きスペースとしてなど、様々な目的で使用されることになる。より安全性の低いアドレス空間もまた、同様の方法で分割されることになり、それにより、より安全性の低いドメインで実行されることになるプログラム・コードの記憶のための部分１１０、より安全性の低いスタック３８に割り当てられる部分１１２、及び残りの部分１１４を提供する。

【0047】

記載の実施例によれば、メモリ・アドレス空間はまた、この領域内のアドレスがプログラム・コードのための有効なアドレスではない、予約された領域１２０を含む。以下にさらに詳細に論じるように、これらの予約されたアドレスのうちのいくつかは、記載の実施例のための所望の機能を提供するために使用される。

【0048】

速度及び効率の改善を目的として、前述の実施例は、安全なドメインとより安全性の低いドメイン、すなわち関数呼出し機構と例外機構、の間で遷移するための２つの機構を提供する。しかし、複数のドメイン遷移機構の使用は、悪意ある攻撃への脆弱性を高め、たとえば、より安全性の低いドメイン内のソフトウェアが、安全なドメインからより安全性の低いドメインに遷移するために使用される最初の機構とは異なるタイプの戻り機構を介して安全なドメインに戻ろうとすることを可能にする。２つの特定の攻撃シナリオが、図３Ａ及び３Ｂに示される。図３Ａに示すように、何らかの安全なコードがポイント１４５で実行し、そして、ポイント１５０で関数呼出しが、より安全性の低いドメイン内に存在する関数に対して行われると仮定される。その関数は、次いで、ポイント１５５で実行されるが、ポイント１６０で、より安全性の低いソフトウェアが、例外戻り機構を使用することによって安全なコードへの任意の分岐を試みる。

【0049】

同様に、図３Ｂでは、何らかの安全なコードがポイント１７５で実行し、そして、ポイント１８０で、例外（たとえば、割込み）が生じ、より安全性の低いドメインにおける例外処理ルーチンへの分岐を引き起こすと仮定される。この例外処理ルーチンは、ポイント１８５で実行されるが、その後にポイント１９０で、より安全性の低いドメイン内のソフトウェアが安全なドメインへの関数戻りを行おうと試みる。

【0050】

システムのセキュリティが維持されることになる場合、そのようなシナリオが起こることが許された場合、これは、安全なデータへのアクセスを得るための機構を提供することができる安全なコードへの任意の分岐をより安全性の低いソフトウェアが行おうとすることを可能にすることになるので、前述の攻撃シナリオの両方が防がれる必要がある。

【0051】

そのような攻撃から保護するために、スタック・アクセス回路７０が、図４Ａ及び４Ｂを参照してより詳細に論じられるように、安全なドメインからより安全性の低いドメインへの遷移を引き起こす関数呼出し又は例外が生じるときに安全なスタックのスタック・フレームに所定の処理状態を格納するように構成される。図４Ａでは、安全なプログラムＦＯＯは安全なドメインで現在実行していて、次いで、関数呼出し又は例外が、ＦＯＯが完了する前に生じると仮定される。関数呼出し又は例外の発生に先立って、ＦＯＯは、通常は、ＦＯＯによって使用される一時的データを記憶するために、安全なスタック２００で割り当てられたスタック・フレーム２０５を使用することになる。関数呼出し又は例外の発生時に、別個のスタック・フレーム２１０が、次いで、スタック・アクセス回路７０のために割り当てられることになり、そして、そのスタック・アクセス回路は、次いで、関数呼出しによって識別される必要のあるソフトウェア・ルーチンへの又は例外を処理するために必要とされる例外処理ルーチンへの分岐に先立って、スタック・フレーム２１０内で所定の処理状態を記憶することになる。

【0052】

例外が生じる状況を第１に考えると、そのとき、例外処理ルーチンが安全なドメイン内で実行されようとする場合、スタック・フレーム２１０内のスタック・アクセス回路によって記憶される所定の処理状態は、図４Ｂによって識別されるレジスタ２１５の内容を含む。これらのレジスタは、本明細書で、「発呼側」レジスタと呼ばれ、それらは、スタック・アクセス回路７０（又は例外制御回路２８）が、例外処理ルーチンが実行されることになるドメインに関わらず、スタックへの状態保存の責任を常に取ることになる、レジスタである。デフォルトで、例外処理ルーチンは、その場合、レジスタ（本明細書で「被発呼側」レジスタと呼ばれる）の残りの状態保存の責任を有することになる。具体的には、例外処理ルーチンは、その場合、例外処理ルーチンの本体におけるレジスタの再使用に先立って、例外処理ルーチンが実行しているドメインに関連するスタックに被発呼側レジスタの状態を保存することになる。さらに、例外処理ルーチンが完了された後には、例外処理ルーチンは、次いで、例外戻りの発行に先立ってそれらの被発呼側レジスタの状態を復元する（通常は、それらをスタックから関連レジスタにコピーして戻すことによって）責任を有することになる。

【0053】

しかし、前述の実施例によれば、例外が安全なドメインからより安全性の低いドメインへの遷移を必要とすることになる、前のバックグラウンド処理が安全なドメインにおいてであった状況で、スタック・アクセス回路７０は、さらに、処理回路を例外処理ルーチンの実行に遷移させる前に、スタック・フレーム２１０内での被発呼側レジスタの状態保存の責任を取る。したがって、図４Ｂに示すように、この状況で、スタック・フレーム２１０内に記憶された所定の処理状態は、２２０の形を取る。図４Ｂで具体的に識別された発呼側及び被発呼側レジスタは、単に、どのように発呼側及び被発呼側レジスタが分割され得るかの一例であり、厳密にどのレジスタが発呼側レジスタ又は被発呼側レジスタであると考えられるかは、実装形態に応じて変わることになる。

【0054】

図４Ｂにやはり示すように、例外処理ルーチンがより安全性の低いドメイン内にあり、したがって安全なドメインからより安全性の低いドメインへの遷移を必要とする状況で、スタック・アクセス回路はまた、スタック・フレーム２１０内の所定の相対的位置で所定の署名２２２を記憶するように構成され、図示された実施例では、この所定の相対的位置はスタック・フレーム内の下部の位置である。この所定の署名は、様々な形を取り得るが、一実施例では、プログラム・コードの有効なアドレスに対応しない値を有するように選択される。一実施例で、その所定の署名は、メモリ・アドレス空間の予約された部分内のアドレス値１２０のうちの１つを有するように選択される。１つの特定の実施例で、その所定の署名は、値０ｘＦ０Ａ５１２５Ａを有する。

【0055】

通常は、関数呼出しの発生時に、スタック・アクセス回路７０は、通常は、スタック・フレーム２１０内で所定の処理状態を記憶しないことになる。したがって、関数呼出しが、やはり安全なドメイン内にある目標コードを識別する場合、所定の処理状態は記憶されない。しかし、関数呼出しがより安全性の低いドメイン内で目標コードを識別する場合、そのとき、スタック・アクセス回路７０は、関数呼出しが完了された後にＦＯＯの実行を再開するために必要とされることになる戻りアドレス２２５をスタック・フレーム２１０内に記憶するように構成される。この戻りアドレス２２５は、より安全性の低いドメインへの遷移を必要とする例外発生の場合に所定の署名２２２が記憶されるときと同じ所定の相対的位置、すなわち、スタック・フレーム内の下部の位置、で記憶される。

【0056】

安全なスタック内に記憶された実際の戻りアドレス２２５の代わりに、より安全性の低いドメイン内の目標コードが、実際にはプログラム・コードの有効なアドレスではないダミー関数呼出し戻りアドレス内で提供される。一実施例で、そのダミー関数呼出し戻りアドレスは、予約されたアドレス１２０のうちの１つから選択され、前述の所定の署名２２２とは異なる値を有するようにさらに選択される。

【0057】

関数呼出しの発生時に、ソフトウェアは、たとえ状態保存が図４Ｂに示すスタック・フレームによるハードウェアによって必要とされない場合でも、やはりレジスタ状態の状態保存を実行することができる。レジスタの発呼側及び被発呼側レジスタへの分割は、それが、関数呼出しの前に実行されるソフトウェア（発呼側ソフトウェア）及び関数呼出しの後に実行されるソフトウェア（被発呼側ソフトウェア）の両方がどのレジスタが状態保存を受けるかに影響を及ぼすことを可能にするので、そのような関数呼出しに有用である。たとえば、発呼側ソフトウェアが、それがある特定の発呼側レジスタを使用しなかった、又はいくつかの発呼側レジスタ内のデータの使用を終了したと認識した場合、そのとき、それらのレジスタ内の値は関数呼出しの後に保持される必要はないことになり、したがって、これらのレジスタは状態保存を受ける必要はない。同様に、被発呼側ソフトウェアがある特定の被発呼側レジスタを使用していないことになる場合、そのとき、被発呼側ソフトウェアはこれらのレジスタの状態保存を実行する必要はない。したがって、発呼側及び被発呼側ソフトウェアの両方が状態保存のためのレジスタの選択に影響を及ぼすことを可能にすることで、適切な場合に状態保存の量を低減することによってパフォーマンスの改善を可能にする。相対的に、発呼側ソフトウェアのみ又は被発呼側ソフトウェアのみが状態保存の責任を有する場合、そのとき、他方のソフトウェアがそのレジスタが保存されることを必要とする場合に備えて、いくつかのレジスタが余計に保存されることがある。図５は、一実施例による、関数呼出しの発生時に処理回路によって実行されるステップを示す流れ図である。ステップ３００で、現在実行しているコードが安全なドメインで実行されているかどうかが判定される。そうでない場合、次いで、本処理はステップ３１０に直接進み、そこで、リンク・レジスタ（ＬＲ：ｌｉｎｋ ｒｅｇｉｓｔｅｒ）が戻りアドレスと等しく設定される。その後、本処理はステップ３２５に進み、そこで、分岐が新しい関数（すなわち、関数呼出しの目標として識別されるプログラム・コード）に実行される。戻りアドレスはリンク・レジスタ内で設定されてあるので、新しい関数が完了したとき、正しい戻りアドレスが関数呼出し戻り内で指定され得る。

【0058】

ステップ３００で現在実行しているコードが安全なドメイン内で実行されていると判定された場合、次いで、ステップ３０５で、関数呼出しの宛先である新しい関数がより安全性の低いドメイン内で実行されることになるかどうかが判定される。これが判定され得るいくつかの方法が存在するが、一実施例で、これは、関数呼出しの目標アドレスが安全なメモリ領域又はより安全性の低いメモリ領域に関連するアドレスであるかどうかを判定することによって単純に達成される。それがより安全性の低いメモリ領域に関連する場合、これは、その関数呼出しの宛先がより安全性の低いドメイン内であることを示す。関数呼出しの宛先がより安全性の低いドメイン内でない場合、次いで、再び、本処理はステップ３１０に進む。

【0059】

しかし、関数呼出しの宛先がより安全性の低いドメイン内である場合、そのとき、これは、安全なドメインからより安全性の低いドメインへの遷移の必要性を示し、そして、この時点で、本処理はステップ３１５に進み、そこで、リンク・レジスタが、前述のようにダミー関数呼出し戻りアドレスに設定される。加えて、ステップ３２０で、実際の戻りアドレスが、スタック・アクセス回路７０によって安全なスタックにプッシュされる。その後、本処理はステップ３２５に進み、そこで、分岐が、関数呼出しの目標である新しい関数に実行される。

【0060】

図５に示すハードウェア動作と同様に、関数呼出しの前に実行するソフトウェアはまた、レジスタからデータの状態保存を実行することができ、関数呼出しの後に実行するソフトウェアはまた、被発呼側レジスタからデータの状態保存を実行することができる。

【0061】

図６は、例外の発生時の処理回路の動作（割込みである例外の一例）を示す流れ図である。ステップ４００で、リンク・レジスタは、ダミー例外戻りアドレスを選択するように設定され、一実施例では、選択することができる複数の異なるダミー例外戻りアドレスが存在する。一実施例で、起こり得るダミー例外戻りアドレスの各々は、プログラム・コードの有効なアドレスではないアドレスであることになる。ステップ４００のさらなる詳細は、後で説明されることになる。その後、ステップ４０５で、発呼側の保存されたレジスタが、バックグラウンド処理ドメイン、すなわち、そこでバックグラウンド・コードが実行されていたドメイン、のスタックにプッシュされる。

【0062】

その後、ステップ４０８で、バックグラウンド処理が安全なドメイン内であったかどうかが判定され、そうでない場合、本処理はステップ４３２に直接進む。以下に記載のように、バックグラウンド処理が安全なドメイン内であったかどうかは、リンク・レジスタ６５内に置かれた例外戻り値に基づいて判定され得る。バックグラウンド処理が安全なドメイン内であった場合、次いで、ステップ４１０で、現在実行しているコードが安全なドメインで実行されているかどうかが判定され、そうでない場合、本処理は再びステップ４３２に直接進む。しかし、現在実行しているコード（バックグラウンド処理でもよく、又は前の末尾連鎖式例外でもよい）が安全なドメインで実行されているとステップ４１０で判定された場合、次いで、ステップ４１２で、宛先がより安全性の低いドメイン内であるかどうか、すなわち、例外を処理するために必要とされる例外処理コードがより安全性の低いドメイン内で実行されることになるかどうかが、判定される。そうでない場合、次いで、再び、本処理はステップ４３２に直接進む。しかし、宛先がより安全性の低いドメイン内である場合、そのとき、これは、バックグラウンド処理が安全なドメイン内であった、安全なドメインからより安全性の低いドメインへの遷移が存在することになる状況を示す。したがって、本処理はステップ４２０に進み、そこで、被発呼側の保存されたレジスタがバックグラウンド・ドメインのスタックにプッシュされ、前述の所定の署名がスタック・フレームの下部に書き込まれる。バックグラウンド処理に関連するスタックは、リンク・レジスタ６５内に置かれた例外戻り値から判定することができる。本ステップのさらなる詳細は、後から提供されることになる。

【0063】

ステップ４３０で、例外制御回路２８は、すべてのレジスタがクリアされることを確実にする。一例で、すべてのレジスタが、ステップ４３０でクリアされ得る。一代替実施例では、レジスタがスタックにプッシュされるときにそれらのレジスタがクリアされることが可能であり、したがって、発呼側レジスタはステップ４０５の間にクリアすることができ、被発呼側レジスタはステップ４２０又は４３０の間にクリアすることができる。

【0064】

ステップ４３０に続いて、又はステップ４０８、４１０及び４１２でチェックされた条件のいずれも生じなかった場合、そのとき、本処理は、ステップ４３２に進む。例外入力が末尾連鎖式例外である場合、そのとき、リンク・レジスタ６５は新しい例外戻り値で更新される。本ステップは、図１２Ｂに関して以下にさらに詳しく論じられることになる。

【0065】

ステップ４３５で、本処理は、例外処理ルーチンに分岐する。

【0066】

例外処理ルーチンは、次いで、被発呼側レジスタの状態保存を実行することができる。一実施例で、例外処理ルーチンは、たとえ被発呼側レジスタ内のデータがステップ４２０で既にスタックにプッシュされ、クリアされた場合でも（この場合、ハードウェアは、被発呼側レジスタからデータを安全なスタックに格納したことになり、一方、ソフトウェアは、より安全性の低いスタックに被発呼側レジスタからクリアされた値を格納することになる）、被発呼側レジスタの状態保存をいつも実行することができる。別法として、例外処理ルーチンは、被発呼側レジスタの状態保存が既に実行されたかどうかを検出することができ、そうである場合、被発呼側レジスタの状態保存を省略することができる。

【0067】

図７は、どのように分岐動作が処理されるかを示す流れ図である。そのような分岐動作は、正規の分岐処理動作、関数呼出し戻り及び例外戻りを含み得る。図７は分岐動作について示されるが、代替実施例で、同様の機構は、命令フローでの変更を引き起こし得る任意の命令、たとえば、宛先レジスタとしてプログラム・カウンタを有するロード命令、との関連で使用され得る。

【0068】

ステップ５００で、分岐動作によって指定された目標アドレスが予約されたアドレス範囲１２０内であるかどうかが判定され、この特定の実施例で、これは、目標アドレスが０ｘＦ０００００００以上である場合に当てはまる。そうでない場合、そのとき、これは正規の分岐活動を示し、そして、本処理はステップ５０５に進み、そこで、正規の分岐処理が実行される。分岐動作の処理は当業者によく知られているので、正規の分岐処理のさらなる詳細は本明細書では提供されない。

【0069】

ステップ５００で目標アドレスが予約されたアドレス範囲１２０内であると判定された場合、次いで、ステップ５１０で、目標アドレスがダミー関数呼出し戻りアドレスに対応するかどうかが判定される。１つの特定の実施例で、ダミー関数呼出し戻りアドレスは０ｘＦ７ＦＦＦＦＦＦである。目標アドレスがダミー関数呼出し戻りアドレスに対応しない場合、次いで、ステップ５１５で、安全なスタック内のスタック・フレーム２１０の前述の所定の相対的位置が、安全なスタックから戻りアドレスを読み取るために、アクセスされる。その後、本処理はステップ５００に戻り、そこで、関数呼出し戻りが前の関数呼出しから戻るために正しく使用されたとみなし、ステップ５１５で読み取られた戻りアドレスは、プログラム・コードの実アドレスであることになり、したがって、本処理は、ステップ５０５で正規の分岐処理に分岐することになる。しかし、そうではなくて関数呼出し戻りが、例外から戻るための機構として不正確に使用された場合、次いで、スタック・フレーム２２０がステップ５１５でアクセスされるときに、所定の署名２２２が、実際の戻りアドレスとして検索されることになる。そのアドレスが、次いで、ステップ５００で分析されるとき、それが予約された範囲内であることが判定されることになるが、ステップ５１０で、そのアドレスがダミー関数呼出し戻りアドレスではないことが判定されることになる。本処理は、次いで、ステップ５２０に進み、そこで、アドレスが有効な例外戻りアドレスのうちの１つではないことが判定されることになり、それに応じて、本処理は、ステップ５２５に分岐することになり、そこで、障害が、関数呼出し戻りが不正確に使用されたことを識別するために、作成されることになる。

【0070】

例外戻りが指定される状況をここで考えると、そのとき、この例外戻りが、安全なドメインからより安全性の低いドメインへの遷移を引き起こす前の例外に関連する場合、これは、目標アドレスとしていくつかの異なる有効な例外戻りアドレスのうちの１つを識別することになり、それらの起こり得る例外戻りアドレスの各々は、予約された範囲１２０内にあり、所定の署名及びダミー関数呼出し戻りアドレスの両方と異なる。したがって、本処理は、ステップ５００からステップ５１０に、そして、そこからステップ５２０に進むことになり、そこで、はい（ｙｅｓ）経路が、次いで、ステップ５３０まで辿られることになる。例外戻り処理ステップ５３０の詳細は、後で説明されることになる。現在の例外より低い又は同等の優先度の及びバックグラウンド処理より高い優先度の新しい例外が、この現在の例外が戻る時点で実行を待っている状況では、その場合、その新しいより優先度の低い例外が、末尾連鎖式例外として選ばれることになり（すなわち、その新しい例外が、現在の例外が選ばれるより前に起こっていたバックグラウンド処理に戻るより前に、現在の例外の完了に続いて直ちに処理されることになる）、そして、本処理は、図７に示すように、図６のステップ４０８に分岐して戻ることになる。

【0071】

ステップ５３０の例外戻り処理が実行され、さらなる末尾連鎖式例外が保留されていない後は、本処理はステップ５３５に進み、そこで、例外戻り処理ステップ５３０が、所定の署名がスタック・フレーム２１０内に記憶された処理状態内で予期されるべきであると指示したかどうかが判定される。前述のように、これは、例外が安全なドメインからより安全性の低いドメインへの遷移を引き起こし、バックグラウンド・コードが安全なドメインで実行された場合に、当てはまることになる。所定の署名が予期されない場合、次いで、本処理は、ステップ５４０に単に進み、そこで、関連レジスタ値がスタック・フレームから積み重ねを解除される。この処理は、図１３に関して後でより詳細に説明されることになる。

【0072】

しかし、ステップ５３５で、所定の署名が予期されると判定された場合、次いで、本処理はステップ５４５に進み、そこで、スタック・フレーム２１０の下部が読み取られ、検索された値が所定の署名と比較される。ステップ５５０で、マッチがあるかどうかが判定され、そうである場合、本処理はステップ５４０に進む。しかし、マッチが存在しない場合、次いで、本処理は、ステップ５５５に進み、そこで、例外戻りが関数呼出しから戻ろうとして不正確に使用されたことを示す、障害が作成される。具体的には、例外戻りが不正確に使用されて関数呼出しから戻ろうと試みた場合、ステップ５４５での安全なスタックの読取りは、所定の署名と一致しないことになる、戻りアドレス２２５が検索される結果をもたらすことになり、それによって、ステップ５５５で障害を作成させることになる。

【0073】

ステップ５２５又はステップ５５５で作成された障害が処理され得るいくつかの方法が存在する。一実施例で、処理回路は、いずれかの障害条件に応答して、安全なドメイン内で適切な障害処理プログラム・コードを実行する。障害処理プログラム・コードが安全なドメイン内で実行されることを確実にすることによって、これは、より安全性の低いドメインで攻撃者が制御を取り戻すこと、したがって攻撃を再試行することを防ぐ。

【0074】

攻撃の再試行を阻止するための代替機構として、データ処理装置は、いずれかの障害条件が識別された場合にスタック・ポインタ値が調整されないように、戻りの再生がまた同障害条件を識別させることになるように、構成され得る。したがって、スタック・ポインタを調整しないことによって、攻撃者は、安全なスタックの最後の位置を単に破壊することができず、次いで、安全なスタック内の異なる場所で入力するために、攻撃を再試行する。一実施例で、前述の機構の両方が、より安全性の低いドメインからの攻撃の再試行に対する頑強性を実現するために使用され得る。

【0075】

一実施例で、より安全性の低いドメインからの潜在的攻撃を引き起こし得るもう１つのシナリオは、安全なスタックの初期化に続いて生じる。この時点で、安全なスタックは、空であることになる。その時点で、実行されているプログラム・コードがより安全性の低いドメイン内である場合、プログラム・コードは、安全なドメインに戻ろうと試み得ることが起こり得る。安全なドメインからより安全性の低いドメインへ合法的に戻されることになる、元の遷移は存在しないので、そのような戻りは防がれるべきである。図８Ａ及び８Ｂは、そのような戻りが成功するのを防ぐために使用することができる機構を示す。図８Ａに示すように、安全なスタック６００が初期化されるとき、所定の署名値６０２が、安全なスタックに記憶される（一実施例で、この値は、スタックが初期化されるときにソフトウェアによって記憶される）。この所定の署名値は、通常は、図４Ｂを参照して前述された所定の署名２２２とは異なることになるが、やはりプログラム・コードの有効なアドレスに対応しない値であることになる。１つの特定の実施例で、所定の署名６０２は、値０ｘＦ０５ＡＥＤＡ５を有する。

【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】

特定の実施例が本明細書で説明されたが、本発明はそれらに限定されないこと、及び、それらへの多数の修正及び追加が本発明の範囲内で行われ得ることが理解されよう。たとえば、以下の従属請求項の特徴の様々な組合せが、本発明の範囲を逸脱することなしに独立請求項の特徴と行われ得る。

【図1】

【図2】

【図3A】

【図3B】

【図4A】

【図4B】

【図5】

【図6】

【図7】

【図8A】

【図8B】

【図9】

【図10】

【図11】

【図12A】

【図12B】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18A】

【図18B】