JP2006506752A - 安全処理システムにおける例外タイプ - Google Patents

安全処理システムにおける例外タイプ Download PDF

Info

Publication number
JP2006506752A
JP2006506752A JP2004570294A JP2004570294A JP2006506752A JP 2006506752 A JP2006506752 A JP 2006506752A JP 2004570294 A JP2004570294 A JP 2004570294A JP 2004570294 A JP2004570294 A JP 2004570294A JP 2006506752 A JP2006506752 A JP 2006506752A
Authority
JP
Japan
Prior art keywords
mode
exception
safety
safe
secure
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2004570294A
Other languages
English (en)
Other versions
JP4447471B2 (ja
Inventor
ワット、サイモン、チャールズ
ドーナン、クリストファー、ベントリー
オリオン、リュック
ショサード、ニコラ
ベルネ、リオネル
ブロシエ、ステファン、エリク、セバスティアン
Original Assignee
エイアールエム リミテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GB0226905A external-priority patent/GB0226905D0/en
Priority claimed from GB0226902A external-priority patent/GB0226902D0/en
Priority claimed from GB0303449A external-priority patent/GB0303449D0/en
Application filed by エイアールエム リミテッド filed Critical エイアールエム リミテッド
Publication of JP2006506752A publication Critical patent/JP2006506752A/ja
Application granted granted Critical
Publication of JP4447471B2 publication Critical patent/JP4447471B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/48—Indexing scheme relating to G06F9/48
    • G06F2209/481—Exception handling

Abstract

複数のモードおよび複数のドメインで作動できるプロセッサを備え、前記複数のドメインが安全ドメインまたは非安全ドメインを含み、前記複数のモードが、
前記安全ドメインにおけるモードである少なくとも１つの安全モードと、
前記非安全ドメインにおけるモードである少なくとも１つの非安全モードとを含み、
前記プロセッサが安全モードでプログラムを実行しているときは、前記プロセッサが非安全モードで実行中にアクセスできない安全データにアクセスし、
前記プロセッサが例外ハンドラーを使用する例外処理をトリガーするための１つ以上の例外条件に応答自在であり、前記プロセッサが前記安全ドメインで作動しているか、または非安全ドメインで作動しているかに応じて、前記プロセッサが複数の可能な例外ハンドラーから前記例外ハンドラーを選択するようになっている、データを処理するための装置が提供される。

Description

本発明はデータ処理システムに関し、より詳細には、安全ドメインと非安全ドメインとを有するデータ処理システム内で提供される例外のタイプに関する。
データ処理システムは、このデータ処理システムにロードされたアプリケーションを実行するためのプロセッサを一般に含む。このプロセッサはオペレーティングシステムの制御により作動する。特定のアプリケーションを実行するのに必要なデータは一般にデータ処理装置のメモリに記憶される。これらのデータはアプリケーション内に含まれる命令および／またはプロセッサにおいてこれら命令を実行する間に使用される実際のデータ値から成ることが理解できよう。
アプリケーションのうちの少なくとも１つによって使用されるデータが、プロセッサで実行し得る他のアプリケーションによってアクセスできないような機密データとなっている場合が多い。一例として、データ処理装置がスマートカードであり、アプリケーションの１つが有効化、認証、暗号解読などを実行するために、例えば安全キーを使用するようなセキュリティアプリケーションである場合を挙げることができる。かかる状況では、機密データを安全に維持し、データ処理装置にロードできる他のアプリケーション、例えばその安全データにアクセスしようとする目的でデータ処理装置にロードされたハッキングアプリケーションによってアクセスできないようにすることは、明らかに重要である。
公知のシステムでは、オペレーティングシステムの制御により実行されている他のアプリケーションから１つのアプリケーションの安全データにアクセスできないように保証するために十分なセキュリティを提供することは、オペレーティングシステム開発者の仕事であった。しかしながら、システムがより複雑になるにつれ、一般的な傾向としてオペレーティングシステムはより大きく、かつ複雑となっている。かかる状況では、オペレーティングシステム自身の内部で十分なセキュリティを保証することは次第に困難となりつつある。
米国特許出願第US2002/0007456A1号および米国特許第US6,282,657B号、および同第US6,292,874B号には、安全データを安全に記憶し、かつ悪意のあるプログラムコードから保護しようとするシステムの例が記載されている。
従って、データ処理装置のメモリ内に含まれるかかる安全データのセキュリティを維持せんとするための改良された技術を提供することが望ましい。
１つの様相から見れば、本発明は、複数のモードおよび複数のドメインで作動できるプロセッサを備え、前記複数のドメインが安全ドメインまたは非安全ドメインを含み、前記複数のモードが、
前記安全ドメインにおけるモードである少なくとも１つの安全モードと、
前記非安全ドメインにおけるモードである少なくとも１つの非安全モードとを含み、
前記プロセッサが安全モードでプログラムを実行しているときは、前記プロセッサが非安全モードで実行中にアクセスできない安全データにアクセスし、
前記プロセッサが例外ハンドラーを使用する例外処理をトリガーするための１つ以上の例外条件に応答自在であり、前記プロセッサが前記安全ドメインで作動しているか、または非安全ドメインで作動しているかに応じて、前記プロセッサが複数の可能な例外ハンドラーから前記例外ハンドラーを選択するようになっている、データを処理するための装置を提供するものである。
例外処理は安全システムにおけるセキュリティの脆弱性を提供する潜在力を有すると本発明は認識している。本発明は安全例外ハンドラーまたは非安全例外ハンドラーに選択的に向けることができる１つ以上の例外と非安全例外ハンドラーおよび安全例外ハンドラーのうちの専用の１つに向けられた１つ以上の例外との組み合わせを有するシステムを提供することにより、この問題を解決するものである。選択可能な例外を設けたことにより、覆すことがより困難な態様で、特定の例外の発生に対する、制限され、かつ良好に定められた応答を専用例外が提供しながら、種々のオペレーティングシステムの条件に適合するように、例外の取り扱いにおいて望ましいフレキシビリティの程度を得ることを可能にしている。一例として、ウォッチドッグタイマーによってトリガーされるような正式なセキュリティチェックをブロックできないように、安全例外ハンドラーによって取り扱いできるように保証された専用例外とウォッチドッグセキュリティタイマーとを関連付けできる。
本発明はセキュリティ活動、例えばスイッチ等でのレジスタ値のフラッシングに役割を果たすモニタモードで安全ドメインと非安全ドメインとの間のすべての切り替えを行わなければならないモニタモードを設けることと有利に組み合わされている。
専用例外の好ましい例としては、安全インターラプト信号例外、モード切り替えソフトウェアインターラプト信号およびリセット例外がある。選択可能な例外の好ましい例としてはインターラプト信号例外、ソフトウェアインターラプト信号、無定義命令例外、プリフェッチアボート例外、データアボート例外および高速インターラプト信号例外がある。
別の様相から見れば、本発明は、複数のモードおよび安全ドメインまたは非安全ドメインを含む複数のドメインで作動できるプロセッサによりプログラムを実行するステップを備え、前記複数のモードが、
前記安全ドメインにおけるモードである少なくとも１つの安全モードと、
前記非安全ドメインにおけるモードである少なくとも１つの非安全モードとを含み、
前記プロセッサが安全モードでプログラムを実行しているときは、前記プロセッサが非安全モードで実行中にアクセスできない安全データにアクセスし、
１つ以上の例外条件に応答して、例外ハンドラーを使用して例外処理をトリガーするステップを更に備え、前記プロセッサが前記安全ドメインで作動しているか、または非安全ドメインで作動しているかに応じて、前記プロセッサが複数の可能な例外ハンドラーから前記例外ハンドラーを選択するようになっている、データを処理するための方法を提供するものである。
以下、添付図面に示した本発明の好ましい実施例を参照して、単なる例示により本発明について更に説明する。
図１は本発明の好ましい実施例に係わるデータ処理装置を示すブロック図である。このデータ処理装置にはプロセッサコア１０が実装されており、このプロセッサコア１０内には命令のシーケンスを実行するようになっている代数論理ユニット（ＡＬＵ）１６が設けられている。このＡＬＵ１６が必要とするデータはレジスタバンク１４に記憶される。コア１０にはプロセッサコアのアクティビティを表示する、診断データを捕捉できるようにするための種々のモニタ機能が設けられている。一例として、埋め込み型トレースモジュール（ＥＴＭ）２２が設けられているが、このＥＴＭ２２はどのアクティビティをトレースするかを定める、ＥＴＭ２２内の所定の制御レジスタ２６のコンテンツに応じてプロセッサコアの所定アクティビティのリアルタイムのトレースを発生するようになっている。このトレース信号は一般にトレースバッファへ出力され、このバッファからこれらトレース信号をその後分析できる。種々の周辺機器（図示せず）によって立ち上げられ得る複数のインターラプトのサービスを管理するためのベクトル化されたインターラプトコントローラ２１が設けられている。
更に図１に示されるように、コア１０内に設けることができる別のモニタ機能として、デバッグ機能、１つ以上のスキャンチェーン１２に結合されたジョイントテストアクセスグループ（ＪＴＡＧ）コントローラ１８を介してコア１０と通信できるデータ通信装置の外部のデバッギングアプリケーションが挙げられる。プロセッサコア１０の種々の部分のステータスに関する情報は、スキャンチェーン１２およびＪＴＡＧコントローラ１８を介して外部デバッギングアプリケーションに出力できる。デバッグ機能をいつスタートし、停止すべきかを識別する条件をレジスタ２４内に記憶するのに、インサーキットエミュレータ（ＩＣＥ）２０が使用され、従ってこのエミュレータ２０は例えばブレークポイント、ウォッチポイントなどを記憶するのに使用される。
コア１０はメモリ管理ロジック３０を介してシステムバス４０に結合されており、メモリ管理ロジック３０はデータ処理装置のメモリ内のロケーションへアクセスするためにコア１０が発生したメモリアクセスリクエストを管理するようになっている。メモリの所定の部分は、システムバス４０に直接接続されたメモリユニット、例えば図１に示されるような密結合メモリ（ＴＣＭ）３６およびキャッシュ３８によって具現化できる。かかるメモリにアクセスするのに別のデバイス、例えばダイレクトメモリアクセス（ＤＭＡ）コントローラ３２を設けることもできる。チップの種々の素子の所定の制御パラメータを定義するための種々の制御レジスタ３４が一般に設けられ、これら制御レジスタを本明細書ではコプロセッサ１５（ＣＰ１５）のレジスタとも称す。
コア１０を含むチップは外部バスインターフェース４２を介し、外部バス７０（例えばＡＲＭユナイテッド社によって開発された「高度マイクロコントローラバスアーキテクチャ」（ＡＭＢＡ）仕様に従って作動するバス）へ結合でき、この外部バス７０に種々のデバイスを接続できる。これらデバイスはマスターデバイス、例えばデジタル信号プロセッサ（ＤＳＰ）５０またはダイレクトメモリアクセス（ＤＭＡ）コントローラ５２だけでなく、種々のスレーブデバイス、例えばブートＲＯＭ４４、スクリーンドライバ４６、外部メモリ５６、入出力（Ｉ／Ｏ）インターフェース６０またはキー記憶ユニット６４を含むことができる。図１に示されたこれら種々のスレーブデバイスはすべてデータ処理装置の全メモリの実装部分と見なすことができる。例えばブートＲＯＭ４４は外部メモリ５６のようにデータ処理装置のアドレス指定可能なメモリの一部を形成する。更に、スクリーンドライバ４６、Ｉ／Ｏインターフェース６０およびキー記憶ユニット６４などのデバイスはいずれも内部記憶素子、例えばレジスタまたはバッファ４８、６２、６６を含み、これらはいずれもデータ処理装置の全メモリの一部として別々にアドレス指定できる。後により詳細に説明するように、メモリの一部、例えば外部メモリ５６の一部を使用して、メモリアクセスの制御に対応する情報を定める１つ以上のページテーブル５８を記憶する。
当業者であれば理解できるように、外部バス７０には一般にアービタおよびデコーダロジック５４が設けられる。アービタは多数のマスタースレーブ、例えばコア１０、ＤＭＡ３２、ＤＳＰ５０、ＤＭＡ５２などが発生する多数のメモリアクセスリクエストの間の仲裁をするのに使用され、他方、デコーダは外部バス上のどのスレーブデバイスが特定のメモリアクセスリクエストを取り扱うべきかを決定するのを判断するのに使用される。
一部の実施例では、コア１０を含むチップの外部に外部バスを設けることができるが、別の実施例では、外部バスはコア１０を有するチップ上に設けられる。このことは、外部バスがオフチップであるときよりもより安全に、外部バス上の安全データを安全に維持できるという利点を有し、外部バスがオフチップである場合、安全データのセキュリティを高めるのにデータ暗号化技術を使用できる。
図２は、安全ドメインと非安全ドメインを有する処理システム上で作動する種々のプログラムを略図で示す。このシステムには少なくとも一部がモニタモードで実行されるモニタプログラム７２が設けられている。この実施例では、セキュリティステータスフラグにはモニタモードでしか書き込みアクセス可能ではなく、このセキュリティステータスフラグはモニタプログラム７２によって書き込みできる。このモニタプログラム７２は両方向の安全ドメインと非安全ドメインとのすべての切り換えを管理する責任を果たす。コアの外部から見ればモニタモードは常に安全であり、安全メモリ内にモニタプログラムが存在する。
非安全ドメイン内には非安全オペレーティングシステム７４と、この非安全オペレーティングシステム７４と協働して実行される複数の非安全アプリケーションプログラム７６、７８が設けられている。安全ドメイン内には安全カーネルプログラム８０が設けられている。この安全カーネルプログラム８０は安全オペレーティングシステムを形成すると見なすことができる。一般に、かかる安全カーネルプログラム８０は安全カーネル８０をできるだけ小さく、かつ簡単にすることができるように、安全ドメイン内に設けなければならない処理アクティビティにとって不可欠な機能しか提供しないように設計されている。安全カーネル８０をできるだけ小さく、かつ簡単にする理由は、このようにすると安全カーネルをできるだけ安全にできるからである。複数の安全アプリケーション８２、８４は安全カーネル８０と組み合わせて実行されるように図示されている。
図３は、異なるセキュリティドメインに関連する処理モードのマトリックスを示す。この特定の例では、処理モードはセキュリティドメインに対して対称的であるので、モデル１とモデル２は安全な形態および非安全な形態の双方に存在する。
モニタモードはシステム内で最高レベルのセキュリティアクセスを有し、この実施例では、モニタモードはシステムを非安全ドメインと安全ドメインとに両方向に切り換えできる権利が与えられた唯一のモードである。従って、すべてのドメインの切り換えはモニタモードおよびモニタモードにあるモニタプログラム７２の実行へ切り換えることにより行われる。
図４は、非安全ドメイン処理モード１、２、３、４および安全ドメイン処理モードａ、ｂ、ｃの別のセットを略図で示す。図３の対称的な構造と対照的に、図４は安全ドメインの一方または他方には処理モードの一部が存在できないことを示している。モニタモード８６は再び非安全ドメインと安全ドメインとをまたがるように図示されている。モニタモード８６は安全処理モードと見なすことができる。このモードでは安全ステータスフラグを変えることができ、モニタモードのモニタプログラム７２は自ら安全ステータスフラグをセットする能力を有するので、このモニタプログラムは全体としてシステム内の究極的レベルのセキュリティを有効に提供する。
図５はセキュリティドメインに対する処理モードの別の構造を略図で示す。この構造では、安全ドメインおよび非安全ドメインの双方だけでなく、更に別のドメインも識別される。この別のドメインは図示されている安全ドメインまたは非安全ドメインのいずれとも相互作用しなくてもよいように、システムの他の部分からアイソレートされ、この別のドメインが安全ドメインおよび非安全ドメインのどれに属すかという問題関係のないようにできる。
後に理解できるように、マイクロプロセッサのような処理システムには通常レジスタバンク８８が設けられ、このバンクにはオペランド値を記憶できる。図６は処理モードのうちの所定のモードにおけるレジスタ番号のうちの所定の番号に対して設けられた専用レジスタを有するレジスタバンクの一例の、プログラマーのモデル図を示す。より詳細には、図６の例は（英国ケンブリッジのＡＲＭリミテッド社のＡＲＭ７（登録商標）プロセッサ内に設けられるような）公知のＡＲＭレジスタバンクの拡張であり、このレジスタバンクには各処理モードに対して専用のセーブされたプログラムステータスレジスタ、専用のスタックポインタレジスタおよび専用のリンクレジスタＲ１４が設けられるが、この場合、このレジスタバンクはモニタモードを設けることによって拡張される。図６に示されるように、高速インターラプトモードは高速インターラプトモードに入ったときに他のモードからのレジスタコンテンツをセーブし、再記憶する必要がないように設けられた別の専用レジスタを有する。別の実施例では、このモニタモードには高速インターラプトモードと同じように別の専用レジスタを設け、安全ドメインの切り換えの処理をスピードアップし、かかる切り換えに関連したシステムの待ち時間（ｌａｔｅｎｃｙ）を小さくできる。
図７は、安全ドメインおよび非安全ドメインでそれぞれ使用される２つの完全な別個のレジスタバンク状にレジスタバンク８８が設けられた別の実施例を略図で示す。このことは非安全ドメインへの切り換えをしたときに安全ドメイン内で作動できる、レジスタ内に記憶された安全データにアクセス可能になることを防止する１つの方法である。しかしながら、この構造は非安全ドメインおよび安全ドメインの双方でアクセス可能なレジスタ内にデータを入れる、高速かつ効率的な手順を使用することにより、可能かつ好ましいように、非安全ドメインから安全ドメインへのデータが通過する可能性を阻止するものである。
安全レジスタバンクを設ける重要な利点は１つのワールドから別のワールドに切り換える前に、レジスタのコンテンツをフラッシングさせる必要をなくてもよいようにすることである。待ち時間（ｌａｔｅｎｃｙ）が重要な問題でなければ、例えば図６のように安全ドメインのワールドに対して重複したレジスタを有しない、より簡単なハードウェアシステムを使用できる。このモニタモードはあるドメインから別のドメインへ切り換える役割を果たす。コンテンツのリストア、前のコンテンツのセーブだけでなく、レジスタのフラッシングはモニタモードで少なくとも部分的に作動中のモニタプログラムによって実行される。従って、このシステムは仮想化モデルのように働く。以下、このタイプの実施例について更に検討する。例えば本明細書に説明するセキュリティの特徴を構築したＡＲＭ７のプログラマーのモデルについて参照すべきである。
プロセッサモード
安全ワールドにおける複製モードの代わりに同じモードが安全ドメインおよび非安全ドメインの双方をサポートする（図８参照）。モニタモードは（例えばコプロセッサコンフィギュレーションレジスタから記憶されたＳビットを読み出すように）コアの現在のステータスが安全であるか、非安全であるかを知る。
図８ではＳＭＩ（ソフトウェアモニタインターラプト命令）が生じるたびに、コアはあるワールドから別のワールドに正しく切り換えるためのモニタモードに入る。
ユーザーモードからＳＭＩが許可される図９を参照する。
１．スケジューラはスレッド１を開始する。
２．スレッド１は安全機能＝＞ＳＭＩ安全コールを実行しなければならず、コアはモニタモードに入る。ハードウェアの制御により、Ｒ１４＿ｍｏｎおよびＳＰＳＲ＿ｍｏｎ（モニタモードのためのセーブされたプロセッサステータスレジスタ）が現在のＰＣおよびＣＰＳＲ（現在のプロセッサステータスレジスタ）が記憶され、ＩＲＱ／ＦＩＱインターラプトがディスエーブルされる。
３．モニタプログラムは次のタスクを行う。
−Ｓビットをセットする（安全ステータスフラグ）。
−安全アプリケーションが作動中に例外が生じた場合でも、非安全コンテクストを失うことができないようにスタック内に少なくともＲ１４＿ｍｏｎおよびＳＰＳＲ＿ｍｏｎをセーブする。
−開始する新しいスレッド：安全スレッド１があるかどうかをチェックする。（一部の実施例におけるスレッドＩＤテーブルを介し）手順はスレッド１が安全ワールド内でアクティブであることを表示する。
−ＩＲＱ／ＦＩＱインターラプトを再イネーブルする。次に安全ユーザーモードで安全アプリケーションがスタートできる。
４．安全スレッド１が終了するまで作動し、モニタプログラムモードの安全機能からのリターンへ分岐（ＳＭＩ）する（次にコアがモニタモードに入ったときにＩＲＱ／ＦＩＱインターラプトがディスエーブルされる）。
５．安全からのリターン機能は次のタスクを行う。
−安全スレッド１が終了したことを表示する（例えばスレッドＩＤテーブルの場合、テーブルからスレッド１を除く）。
−スタックから非安全コンテクストをリストアし、必要なレジスタをフラッシングし、非安全ドメインへのリターンが一旦なされると、安全データを読み出しできないようにする。
−次にＳＵＢＳ命令（この命令はプログラムカウンタを正しいポイントにリストアし、ステータスフラグを更新する）により非安全ドメインへ戻るように分岐し、（リストアされたＲ１４＿ｍｏｎからの）ＰＣおよび（ＳＰＳＲ＿ｍｏｎからの）ＣＰＳＲをリストアする。よって、非安全ドメインにおけるポイントへのリターンはスレッド１において前に実行されたＳＭＩに続く命令となる。
６．スレッド１はエンドまで実行され、スケジューラへ戻すようにハンドを与える。
上記機能の一部を、特定の実施例によっては、モニタプログラムと安全オペレーティングシステムとに分割できる。
別の実施例では、ユーザーモードではＳＭＩが生じないようにすることが望ましい。
安全ワールドへの進入
リセット
ハードウェアのリセットが生じると、ＭＭＵはディスエーブルされ、ＡＲＭコア（プロセッサ）はセットされたＳビットにより安全スーパーバイザーモードへ分岐する。一旦、安全ブートが終了されると、モニタモードに進むＳＭＩを実行でき、所望した場合モニタは、非安全ワールド（非安全ｓｖｃモード）におけるＯＳへ切り換えできる。遺産（ｌｅｇａｃｙ）ＯＳを使用したい場合、このＯＳは単に安全スーパーバイザーモードへブートでき、安全ステートを無視できる。
ＳＭＩ命令
この命令（モード切り換えソフトウェアインターラプト命令）は、非安全ドメイン内の非安全モードからコールできる（前に述べたようにＳＭＩを特権モードに制限することが望ましいことがある）が、関連するベクトルによって決定されるターゲット進入ポイントは常に固定されており、モニタモード内にある。これは、実行すべき（例えば命令によってパスされるオペランドによって制御される）適当な安全機能に分岐するためのＳＭＩハンドラーまでである。
図６のタイプのレジスタバンク内のレジスタバンクの共用レジスタを使用し、非安全ワールドから安全ワールドまでのパラメータのパスを実行できる。
非安全ワールド内でＳＭＩが生じると、ＡＲＭコアがハードウェア内の次のアクションを行うことができる。
−モニタモードへのＳＭＩベクトルへ分岐すること（次にモニタモードに入るので、安全メモリへのアクセスが許可される）。
−ＰＣをＲ１４＿ｍｏｎにセーブし、ＣＰＳＲをＳＰＳＲ＿ｍｏｎにセーブすること。
−モニタプログラムを使ってＳビットをセットすること。
−モニタモードでの安全例外ハンドラーの実行をスタートすること（マルチスレッドの場合、コンテクストをリストア、すなわちセーブすること）。
−適当な機能を実行するための安全ユーザーモード（またはＳＶＣモードのような別のモード）への分岐。
−コアがモニタモードとなっている間、ＩＲＱおよびＦＩＱをディスエーブルすること（待ち時間（ｌａｔｅｎｃｙ）が大きくなる）。
安全ワールドの出口
安全ワールドから出る可能性は２つある。すなわち、
−安全機能を終了し、この機能をコールした前の非安全モードに戻ること。
−非安全例外（例えばＩＲＱ／ＦＩＱ／ＳＭＩ）により安全機能をインターラプトすること。
安全機能の通常のエンド
安全機能は正常に終了し、ＳＭＩの直後の命令で非安全ワールド内のアプリケーションをレジュームしなければならない。安全ユーザーモードでは、「安全ワールドからのリターン」ルーチンに対応する適当なパラメータにより、モニタモードにリターンするようにＳＭＩ命令を実行する。このステージでは、非安全ワールドと安全ワールドとの間のデータの漏れを防止するためにレジスタをフラッシュし、非安全コンテクスト汎用レジスタをリストアし、非安全バンクレジスタが非安全ワールドで持っていた値により、非安全バンクレジスタを更新する。Ｒ１４＿ｍｏｎおよびＳＰＳＲ＿ｍｏｎは「ＭＯＶＳ ＰＣ、Ｒ１４」命令を実行することにより、ＳＭＩの後で非安全アプリケーションをレジュームするように適当な値を得る。
非安全例外に起因する安全機能の出口
この場合、安全機能は終了せず、取り扱いの必要なインターラプトがあれば、非安全例外ハンドラーに進む前に安全コンテクストをセーブしなければならない。
安全インターラプト
安全インターラプトに対してはいくつかの可能性がある。
次のことに応じて２つの可能な解決案が提案される。
−どんな種類のインターラプトであるか（安全または非安全）。
−（安全ワールドまたは非安全ワールドのいずれかにおいて）ＩＲＱが生じたときにコアはどのモードになっているか。
解決案１
この解決案では、安全インターラプトおよび非安全インターラプトをサポートするのに２つの別個のピンが必要とされる。
非安全ワールド内にある間、
−ＩＲＱが生じた場合、コアはＡＲＭ７のようなＡＲＭコアにおけるように、このインターラプトを取り扱うためにＩＲＱモードに進む。
−ＳＲＩＱが生じた場合、コアはモニタモードに進み、非安全コンテクストをセーブし、次に安全ＩＲＱハンドラーに進み、安全インターラプトを取り扱う。
安全ワールド内にある間、
−ＳＩＲＱが生じた場合、コアは安全ＩＲＱハンドラーに進む。コアは安全ワールドから離れない。
−ＩＲＱが生じた場合、コアはモニタモードに進み、このモードで安全コンテクストがセーブされ、次に非安全ＩＲＱハンドラーに進み、この非安全インターラプトを取り扱う。
換言すれば、現在のワールドに属しないインターラプトが生じると、コアは直接モニタモードに進み、そうでない場合、コアは現在のワールドに留まる（図１０参照）。
安全ワールドで発生するＩＲＱ
図１１Ａ参照：
１．スケジューラはスレッド１を開始する。
２．スレッド１は安全機能＝＞ＳＭＩ安全コールを実行しなければならず、コアはモニタモードに入る。Ｒ１４＿ｍｏｎおよびＳＰＳＲ＿ｍｏｎに現在のＰＣおよびＣＰＳＲが記憶され、ＩＲＱ／ＦＩＱインターラプトがディスエーブルされる。
３．モニタハンドラー（プログラム）は次のタスクを行う。
−Ｓビットをセットする。
−安全アプリケーションが作動中に例外が生じた場合でも、非安全コンテクストを失うことができないようにスタック内に少なくともＲ１４＿ｍｏｎおよびＳＰＳＲ＿ｍｏｎをセーブする（可能な場合には別のレジスタもプッシュする）。
−開始する新しいスレッド：安全スレッド１があるかどうかをチェックする。（スレッドＩＤテーブルを介し）手順はスレッド１が安全ワールド内でアクティブであることを表示する。
−次に安全ユーザーモードで安全アプリケーションがスタートでき、ＩＲＱ／ＦＩＱインターラプトを再イネーブルする。
４．安全スレッド１の実行中にＩＲＱが生じる。コアは直接モニタモード（特殊ベクトル）にジャンプし、モニタモードでＲ１４＿ｍｏｎに現在のＰＣを記憶し、ＳＰＳＲ＿ｍｏｎにＣＰＳＲを記憶する。
５．安全コンテクストをセーブしなければならず、前の非安全コンテクストをリストアする。モニタハンドラーは適当な値によりＲ１４＿ＩＲＱ／ＳＰＳＲ＿ＩＲＱを更新するように、ＩＲＱモードとなることができ、次に制御を非安全ＩＲＱハンドラーへ移す。
６．ＩＲＱハンドラーはＩＲＱをサービスし、次に非安全ワールドでスレッド１へ制御を戻す。ＣＰＳＲおよびＰＣにＳＰＲＳ＿ＩＲＱおよびＲ１４＿ＩＲＱをリストアすることにより、次にスレッド１はインターラプトされたＳＭＩ命令をポイントする。
７．ＳＭＩ命令を再実行する（２と同じ命令）。
８．モニタハンドラーはこのスレッドが前にインターラプトされていると判断し、スレッド１のコンテクストをリストアする。次に、ユーザーモードで安全スレッド１に分岐し、インターラプトされた命令をポイントする。
９．終了するまで安全スレッド１が作動し、モニタモード（専用ＳＭＩ）で（安全からのリターン）機能に分岐する。
１０．（安全からのリターン）機能は次のタスクを行う。
−安全スレッド１が終了したことを表示する（すなわちスレッドＩＤテーブルの場合、テーブルからスレッド１を除く）。
−スタックから非安全コンテクストをリストアし、必要なレジスタをフラッシングし、非安全ワールドへのリターンが一旦なされた場合に、安全データを読み出しできないようにする。
−ＳＵＢＳ命令により非安全ワールドに戻るように分岐し、（リストアされたＲ１４＿ｍｏｎからの）ＰＣおよび（ＳＰＲＳ＿ｍｏｎからの）ＣＰＳＲをリストアする。よって、非安全ワールド内のリターンポイントはスレッド１において前に実行されたＳＭＩに続く命令となるはずである。
１１．エンドまでスレッド１が実行され、スケジューラに制御を戻す。
非安全ワールドで生じるＳＩＲＱ
図１１Ｂ参照：
１．スケジュールがスレッド１を開始する。
２．安全スレッド１の実行中にＳＩＲＱが生じる。コアは直接モニタモード（特別ベクトル）にジャンプし、モニタモードでＲ１４＿ｍｏｎに現在のＰＣを記憶し、ＳＰＳＲ＿ｍｏｎにＣＰＳＲを記憶し、ＩＲＱ／ＦＩＱをディスエーブルする。
３．非安全コンテクストをセーブしなければならず、次にコアは安全ＩＲＱハンドラーに進む。
４．ＩＲＱハンドラーはＳＩＲＱをサービスし、次に適当なパラメータを有するＳＭＩを使ってモニタモードハンドラーに制御を戻す。
５．モニタハンドラーはＳＵＢＳ命令がコアを非安全ワールドに戻し、インターラプトされたスレッド１をレジュームするように非安全コンテクストをリストアする。
６．スレッド１はエンドまで実行され、次にスケジューラにハンドを戻す。
図１１Ａの手順は安全ワールドに入るための決定方法を提供する利点を有する。しかしながら、インターラプトのプライオリティに関連した問題がある。すなわちＳＩＲＱが安全インターラプトハンドラーで作動している間、より高いプライオリティを有する非安全ＩＲＱが生じる。一旦この非安全ＩＲＱが終了すると、コアが安全インターラプトをレジュームできるように、ＳＩＲＱイベントを再び作成する必要が生じる。
解決案２．
この手順（図１２参照）では、２つの別個のピンまたは１つのピンだけで安全インターラプトおよび必要がインターラプトをサポートできる。２つのピンを設けることによってインターラプトの待ち時間（ｌａｔｅｎｃｙ）を小さくできる。
非安全ワールド内にある場合に、
−ＩＲＱが生じた場合、コアはＡＲＭ７のシステム内と同じようにこのインターラプトを取り扱うように、ＩＲＱモードに進む。
−ＳＩＲＱが生じた場合、コアはＩＲＱハンドラーに進み、ここでＳＭＩ命令がコアをモニタモードに分岐させ、非安全コンテクストをセーブし、次に安全ＩＲＱハンドラーに進み、安全インターラプトを取り扱う。
安全ワールド内にある間に、
−ＳＩＲＱが生じた場合、コアは安全ＩＲＱハンドラーに進む。コアは安全ワールドを離れない。
−ＩＲＱが生じた場合、コアは安全ＩＲＱハンドラーに進み、ここでＳＭＩ命令がコアをモニタモード（ここで安全コンテクストがセーブされる）に分岐させ、次に非安全ＩＲＱハンドラーに進み、この非安全インターラプトを取り扱う。
安全ワールド内でのＩＲＱの発生
図１３Ａ参照：
１．スケジュールがスレッド１を開始する。
２．スレッド１は安全機能＝＞ＳＭＩ安全コールを実行しなければならず、コアはモニタモードに入る。Ｒ１４＿ｍｏｎおよびＳＰＳＲ＿ｍｏｎに現在のＰＣおよびＣＰＳＲが記憶され、ＩＲＱ／ＦＩＱがディスエーブルされる。
３．モニタハンドラーは次のタスクを行う。
−Ｓビットをセットする。
−安全アプリケーションが作動中に例外が生じた場合でも、非安全コンテクストを失うことができないようにスタック内（最終的には他のレジスタ内）に少なくともＲ１４＿ｍｏｎおよびＳＰＳＲ＿ｍｏｎをセーブする。
−ローンチする新しいスレッド：安全スレッド１があるかどうかをチェックする。（スレッドＩＤテーブルを介し）手順はスレッド１が安全ワールド内でアクティブであることを表示する。
−次に安全ユーザーモードで安全アプリケーションがスタートでき、ＩＲＱ／ＦＩＱを再イネーブルする。
４．安全スレッド１の実行中にＩＲＱが生じる。コアは直接安全ＩＲＱモードにジャンプする。
５．コアはＲ１４＿ＩＲＱに現在のＰＣを記憶し、ＳＰＲＳ＿ＩＲＱにＣＰＳＲを記憶する。ＩＲＱハンドラーはこれが非安全インターラプトであることを検出し、ＳＭＩを実行し、適当なパラメータによりモニタモードに入る。
６．安全コンテクストをセーブしなければならず、前の非安全コンテクストをリストアする。モニタハンドラーはＣＰＳＲを読み出すことにより、ＳＭＩがどこから来たものであるかを知る。モニタハンドラーはＩＲＱモードに進み、Ｒ１４＿ＩＲＱ／ＳＰＳＲ＿ＩＲＱを読み出し、安全なコンテクストを適当にセーブすることもできる。更に、モニタハンドラーはＩＲＱルーチンが終了した場合、リストアしなければならない非安全コンテクストをこれら同じレジスタにセーブすることもできる。
７．ＩＲＱハンドラーはＩＲＱをサービスし、次に非安全ワールドでスレッド１へ制御を戻す。ＳＰＲＳ＿ＩＲＱおよびＲ１４＿ＩＲＱをＣＰＳＲおよびＰＣにリストアすることにより、次にコアはインターラプトされたＳＭＩ命令をポイントする。
８．ＳＭＩ命令を再実行する（２と同じ命令）。
９．モニタハンドラーはこのスレッドが前にインターラプトされていると判断し、スレッド１のコンテクストをリストアする。次に、ユーザーモードで安全スレッド１に分岐し、インターラプトされた命令をポイントする。
１０．終了するまで安全スレッド１が作動し、モニタモード（専用ＳＭＩ）で（安全からのリターン）機能に分岐する。
１１．（安全からのリターン）機能は次のタスクを行う。
−安全スレッド１が終了したことを表示する（すなわちスレッドＩＤテーブルの場合、テーブルからスレッド１を除く）。
−スタックから非安全コンテクストをリストアし、必要なレジスタをフラッシングし、非安全ワールドへのリターンが一旦なされた場合に、安全データを読み出しできないようにする。
−ＳＵＢＳ命令により非安全ワールドに戻るように分岐し、（リストアされたＲ１４＿ｍｏｎからの）ＰＣおよび（ＳＰＲＳ＿ｍｏｎからの）ＣＰＳＲをリストアする。よって、非安全ワールド内のリターンポイントはスレッド１において前に実行されたＳＭＩに続く命令となるはずである。
１２．エンドまでスレッド１が実行され、スケジューラにハンドを戻す。
非安全ワールドで生じるＳＩＲＱ
図１３Ｂ参照：
１．スケジュールがスレッド１を開始する。
２．安全スレッド１の実行中にＳＩＲＱが生じる。
３．コアは直接ｉｒｑモードにジャンプし、Ｒ１４＿ｉｒｑに現在のＰＣを記憶し、ＳＰＳＲ＿ｉｒｑにＣＰＳＲを記憶する。次にＩＲＱをディスエーブルする。ＩＲＱハンドラーはこれがＳＩＲＱであることを検出し、適当なパラメータによりＳＭＩ命令を実行する。
４．一旦モニタモードになると、非安全コンテクストをセーブしなければならず、次にコアは安全ＩＲＱハンドラーに進む。
５．安全ＩＲＱハンドラーはＳＩＲＱサービスルーチンをサービスし、次に適当なパラメータを有するＳＭＩを使ってモニタモードハンドラーに制御を戻す。
６．モニタハンドラーはＳＵＢＳ命令が非安全コンテクストをリストアし、よってＳＵＢＳ命令がコアを非安全ワールドに戻し、インターラプトされたＩＲＱハンドラーをレジュームする。
７．ＩＲＱハンドラーは次にＳＵＢＳを実行することにより、非安全スレッドに戻ることができる。
８．スレッド１はエンドまで実行され、次に制御をスケジューラに戻す。

図１２の手順により、入れ子状のインターラプトの場合、ＳＩＲＱイベントを再作成する必要はないが、安全インターラプトが実行される保証はない。
例外ベクトル
仮想アドレスの見地から物理的ベクトルテーブルは単一ベクトルテーブルとして見えるが、少なくとも２つの物理的ベクトルテーブルが維持される。一方のテーブルは非安全メモリ内の非安全ワールドのためのものであり、一方は（非安全ワールドからアクセスできない）安全メモリ内の安全ワールドのためのものである。安全ワールドおよび非安全ワールド内に使用される仮想−物理メモリの異なるマッピングによって同じ仮想的メモリアドレスが効果的に物理メモリ内に記憶されている異なるベクトルテーブルにアクセスできるようになる。モニタモードは物理メモリ内の第３ベクトルテーブルを提供するのに常にフラットなメモリマッピングを使用できる。
インターラプトが図１２の手順に従う場合、各テーブルに対し、図１４に示されるような次のベクトルが生じる。このベクトルセットは安全メモリおよび非安全メモリの双方で重複する。
Figure 2006506752
注：リセットへの進入は安全ベクトルテーブル内でしかない。非安全ワールドでリセットが実行されると、コアハードウェアはスーパーバイザーモードに入ることおよびＳビットのセットを強制し、安全メモリ内でリセットベクトルにアクセスできる。
図１５は安全モード、非安全モードおよびモニタモードにそれぞれ適用できる３つの例外ベクトルテーブルを示す。これら例外ベクトルテーブルは安全および非安全オペレーティングシステムの条件および特性に一致するように例外ベクトルでプログラムすることができる。例外ベクトルテーブルの各々はメモリ内のテーブルをポイントするベースアドレスを記憶するＣＰ１５内の関連するベクトルテーブルベースアドレスレジスタを有することができる。例外が生じると、ハードウェアはシステムの現在のステートに対応するベクトルテーブルベースアドレスレジスタを基準にし、使用すべきベクトルテーブルのベースアドレスを決定する。これとは異なり、異なるモードで適用される仮想−物理メモリの異なるマッピングを使用して、異なる物理メモリアドレスに記憶された３つの異なるベクトルテーブルを分離できる。図１６に示されるように、プロセッサのコアに関連するシステム（コンフィギュレーション制御）コプロセッサ（ＣＰ１５）には例外トラップマスクレジスタが設けられている。この例外トラップマスクレジスタはそれぞれの例外のタイプに関連するフラグを提供し、これらフラグはハードウェアが処理を現在のドメイン内で関連する例外のためのいずれかのベクトルに向けて作動するのか、またはスイッチをモニタモード（ある種の安全モードである）へ切り換えるべきかを表示し、次にモニタモードベクトルテーブル内のベクトルに従う。この例外トラップマスクレジスタ（例外制御レジスタ）はモニタモードからしか書き込みできない。非安全モードでは、例外トラップマスクレジスタへの読み出しアクセスも阻止されるようにできる。更にシステムは安全ブートおよび後方へのコンパチビリティを保証するように、安全ベクトルテーブルで指定されるような安全スーパーバイザーモードでシステムをリセットベクトルに常にジャンプさせるように構成されているので、図１６の例外トラップマスクレジスタはリセットベクトルのためのフラグを含まないことが理解できよう。また図１５では、完全を期すために、安全スーパーバイザーモードの安全ベクトルテーブルを除くベクトルテーブルには、リセットベクトルが示されていることが理解できよう。
図１６は、安全ブート中のモニタプログラムにより例外トラップマスクレジスタ内の異なる例外タイプに対するフラグをプログラムできることも示している。これとは異なり、フラグの一部またはすべてが物理的入力信号によって所定の実行手段で提供できる。すなわち安全インターラプト信号が受信されたときに、対応するモニタモードの安全インターラプトリクエストベクトルの実行およびモニタモードへの進入を常に強制するように、安全インターラプトフラグＳＩＲＱをハードウェア化できる。図１６は非安全ドメインの例外に関係する例外トラップレジスタの部分しか示していない。安全例外に対してプログラマブルビットの同様なセットが提供される。
これまでの記載から、例外制御レジスタフラグに応じて１つのレベルではハードウェアは現在のドメイン例外ハンドラーによってインターラプトをサービスさせるか、またはモニタモード例外ハンドラーによってサービスさせるかのいずれかに作動することが理解できようが、これは適用される制御の第１レベルにすぎない。例えば安全モードで例外が生じて、安全モードの例外ベクトルが安全モード例外ハンドラーに従うことが可能であるが、この安全モード例外ハンドラーはこの例外が非安全例外ハンドラーによって良好に処理される性質のものであると判断する。従って、非安全モードへの切り換え、および非安全例外ハンドラーを呼び出すのにＳＭＩ命令を利用する。ハードウェアが非安全例外ハンドラーを開始するように働く場合、この逆も可能であるが、その場合、処理を安全例外ハンドラーまたはモニタモード例外ハンドラーに向ける命令を実行する。
図１７は新しいタイプの例外に関連した別の可能性のあるタイプの切り換えリクエストをサポートするためのシステムの動作を略図で示すフローチャートである。ステップ９８において、ハードウェアは現在のプログラムステータスレジスタ（ＣＰＳＲ）における表示としてモニタモードを変えようと試みる命令を検出する。かかる試みが検出されると、新しいタイプの例外がトリガーされる。本明細書ではこの例外をＣＰＳＲ違反例外と称す。ステップ１００におけるこのＣＰＳＲ違反例外が発生する結果、モニタモード内での適当な例外ベクトルを参照し、ステップ１０２でＣＰＳＲ違反例外を取り扱うためのモニタプログラムが作動される。
これまで説明したＳＭＩ命令のためのサポートの他に、図１７に関連して説明した安全ドメインと非安全ドメインとの切り換えを開始するための手順を設けることができることも理解できよう。この例外手順は、ＳＭＩ命令を介し、すべての正当な試みを行うべき切り換えモードに対する不正な試みに応答するように設けることができる。これとは異なり、かかる手順は安全ドメインと非安全ドメインとを切り換える正当な方法でもよいし、または安全ドメインと非安全ドメインとを切り換える不正な試みを真に行うとはしていない場合でも、正常な動作の一部として処理ステータスレジスタをクリアにしようとする現在のコードとの後方コンパチビリティを与えるように設けることもできる。
上記のように、一般にプロセッサがモニタモードで作動しているとき、インターラプトをディスエーブルする。これはシステムのセキュリティを高めるために行われる。インターラプトが生じると、このときのプロセッサのステートがインターラプト例外レジスタに記憶され、よってインターラプト機能の完了時にインターラプトポイントでインターラプトされた機能の処理をレジュームできる。このプロセスはモニタモードで許可される場合、このことはモニタモードのセキュリティを下げ、起こり得る安全データが漏れるパスを生じさせ得る。この理由からモニタモードではインターラプトは一般にディスエーブルされる。しかしながら、モニタモード中のインターラプトをディスエーブルする結果、インターラプトの待ち時間（ｌａｔｅｎｃｙ）が大きくなる。
機能を実行するプロセッサのステートが記憶されていない場合、モニタモードでインターラプトを認めることが可能である。インターラプトに次いで、機能をレジュームしない場合に限り、これを行うことができる。従って、モニタモードでのインターラプトの待ち時間（ｌａｔｅｎｃｙ）の問題は、安全に再スタートできる機能のモニタモードにしか、インターラプトを認めないことによって解決できる。この場合、モニタモードでのインターラプトの後で、機能の処理に関係するデータを記憶せず、投げ棄て、インターラプトが一旦終了すると、その開始から機能の処理をスタートするようにプロセッサに命令される。上記例では、プロセッサは単にモニタモードに切り換わったポイントに戻るだけであるので、これを行うことは簡単なことである。機能を再スタートすることは、再スタートできる所定の機能に対してのみ可能であり、機能の再スタートは繰り返すことができる結果を生じることに留意すべきである。機能を再スタートした場合にプロセッサが異なる結果を生じるように機能がプロセッサのステートを変える場合、機能を再スタートすることはよいアイデアではない。この理由から、安全に再スタートできる機能だけをモニタモードでインターラプトでき、他の機能に対してはインターラプトをディスエーブルする。
図１８は、本発明の一実施例に従ってモニタモードで発生するインターラプトを取り扱う１つの方法を示す。非安全モードでは、タスクＡの処理中にＳＭＩが生じ、このことはプロセッサをモニタモードに切り換える。ＳＭＩ命令は専用非安全ＳＭＩベクトルによりコアをモニタモードにする。ＰＣの現在のステートがセーブされ、Ｓビットがセットされ、インターラプトがディスエーブルされる。一般に、非安全モードのＰＣおよびＣＰＳＲをセーブするのにＬＲ＿ｍｏｎおよびＳＰＳＲ＿ｍｏｎが使用される。
次に、１つの機能、すなわち機能Ｃがモニタモードで開始される。最初に機能Ｃが行うことは、インターラプトをイネーブルすることであり、次に機能Ｃが処理される。機能Ｃの処理中にインターラプトが生じた場合、インターラプトは受け入れられ実行されるように、インターラプトがディスエーブルされる。しかしながら、モニタモードインジケータはインターラプトの後で、機能をレジュームすべきでなく、むしろ再スタートすべきであることをプロセッサに表示する。これとは異なり、このことを別個の制御パラメータによりプロセッサに表示してもよい。従って、インターラプトに続き、インターラプト例外ベクトルをＬＲ＿ｍｏｎおよびＳＰＳＲ＿ｍｏｎの値で更新し、プロセッサの現在ステートを記憶しない。
図１８に示されるように、インターラプトタスク、すなわちタスクＢの完了の後でプロセッサはインターラプトレジスタにコピーされたＳＭＩ命令のアドレスを読み出し、ＳＭＩを実行し、機能Ｃの処理を再びスタートする。
上記プロセスは機能Ｃが再スタート可能な場合、すなわちプロセスＣを再スタートする結果、処理ステップを繰り返しできるようになる場合にしか作動しない。このことは機能Ｃが将来の処理に影響を与えるスタックポインタのようなプロセッサのステートを変更する場合のケースである。このように繰り返し可能な機能はべき等性（ｉｄｅｎｐｏｔｅｎｃｅ）を有すると称す。べき等性を有しない機能の問題を処理する１つの方法は、コードの最初の部分がべき等性を有するように機能を定義するコードを再配置することであり、べき等性を有するようにコードを構成し直すことができなかった場合、インターラプトをディスエーブルする。例えばコードＣがスタックへの書き込みに関係する場合、少なくとも最初にスタックポインタを更新することなく、このようにすることが可能である。コードを安全に再スタートできないと判断できた場合、機能Ｃに対するコードはインターラプトをディスエーブルするようにプロセッサに命令し、プロセッサがスタックポインタを正しい位置に更新できる。このことは図１８に示されており、ここでは機能Ｃの処理によりインターラプトは所定の方法でディスエーブルされる。
図１９は若干異なる例を示す。この例では、タスクＣを処理することによる所定の方法で別の制御パラメータがセットされる。このパラメータはタスクＣのその後の部分、厳密にはべき等性ではなく、最初にアップルーチンを実行することを条件に安全に再スタートできることを示す。このフィックスアップルーチンはタスクＣのスタートにプロセッサがどのようになっていたかを示すプロセッサのステートをリストアするように働くので、タスクＣを安全に再スタートし、プロセッサが行ったときにインターラプトされていなかったタスクのエンド時に同じプロセッサのステートを発生できる。一部の実施例では、別の制御パラメータをセットしたポイントにおいて若干の間、インターラプトをディスエーブルできるが、プロセッサの一部のステートは更新されるスタックポインタのように補正される。これによってプロセッサを後にアイデムポテントステートにリストアすることが可能となる。
別の制御パラメータをセットした後にインターラプトが生じた場合に続行できる２つの方法がある。フィックスアップルーチンを（Ｆ１で）即座に実行し、次にインターラプトを処理してもよいし、またインターラプトを即座に処理し、インターラプトの完了後にＳＭＩを実行し、タスクＣの再スタート前に（Ｆ２で）フィックスアップルーチンを実行してもよい。理解できるように、これら実施例のいずれにおいても、フィックスアップルーチンはモニタモードで実行され得ので、安全ドメインであることを知らないか、またはモニタモードであることを知らない非安全ドメインでの実行には影響がない。
図１９から判るように、コードＣの最初の部分はべき等性を有し、インターラプトの後にこれを再スタートできる。フィックスアップルーチンが高速で実行されることを条件に、第２部分は再スタート可能であり、このことは「別の」制御パラメータをセットすることによって表示される。コードの最終部分は再スタートできないので、このコードを処理する前にインターラプトをディスエーブルする。
図２０は別の例を示し、この場合、この例は他の例と異なっており、モニタモード中にインターラプトをイネーブルする。次に、モニタモードで作動する機能はインターラプトがもはや安全に再スタートできなくなるとすぐにインターラプトをディスエーブルするように働く。このことは、モニタモードでインターラプトされたすべての機能がレジュームされるのではなく、再スタートされた場合にしか可能ではない。
インターラプト時に所定のモードで作動するすべての機能をレジュームするのではなく再スタートすることを保証できるようにする方法は種々ある。１つの方法は、インターラプトされた命令がインターラプトされた命令のアドレスではなく、命令シーケンスのスタートのアドレスをセーブする新しいプロセッサステートを加える方法である。この場合、モニタモードは既にこのステートで作動する。別の方法は、各機能のスタート時にインターラプト例外レジスタに機能のスタートのアドレスをあらかじめロードし、インターラプト例外レジスタへのインターラプトの後のプロセッサのステートのその後の書き込みをディスエーブルする方法である。
図２０に示された実施例では、インターラプト機能の終了直後に機能の再スタートを行ってもよいし、または必要であれば、機能を安全に再スタートできるようにするのにフィックスアップルーチンの後で行ってもよい。
安全および非安全ドメイン、ならびにモニタモードを有するシステムに関連して、インターラプト待ち時間（ｌａｔｅｎｃｙ）を取り扱う上記方法について説明したが、この方法は特定の理由からレジュームすべきでない機能を有するシステムに明らかに適用できる。一般にかかる機能はインターラプトレジュームを大きくするインターラプトをディスエーブルすることによって作動する。再スタートを可能にすべき機能を補正し、インターラプト後に機能を再スタートするようにプロセッサを制御することにより、機能の処理の少なくとも一部に対してインターラプトをイネーブルできるようになり、更にインターラプトの待ち時間（ｌａｔｅｎｃｙ）を小さくすることに役立つ。例えばオペレーティングシステムの通常のコンテクストの切り換えに役立つ。
安全メモリおよび非安全メモリへのアクセス
図１を参照して説明したように、データ処理装置は特にＴＣＭ３６、キャッシュ３８、ＲＯＭ４４、スレーブデバイスのメモリおよび外部メモリ５６を含むメモリを有する。例えば図３７を参照して説明したように、メモリは安全メモリと非安全メモリに分割されている。製造時にメモリの安全メモリ領域と非安全メモリ領域との間には一般に物理的な区別はないが、その代わり、これら領域は安全ドメインで作動しているときのデータ処理装置の安全オペレーティングシステムによって定められる。従って、メモリデバイスの物理的部分を安全メモリとして割り当て、任意の物理部分を非安全メモリとして割り当てできる。
図２〜５を参照して説明するように、処理システムは安全ドメインと非安全ドメインとを有する。安全ドメインでは安全カーネルプログラム８０が設けられ、このプログラムは安全モードで実行される。安全ドメインと非安全ドメインとをまたがり、少なくとも一部がモニタモードで実行されるモニタプログラム７２が設けられる。本発明の実施例ではモニタプログラムの一部はモニタモードで実行され、一部は安全モードで実行される。例えば図１０に示されるように、特にスーパーバイザーモードＳＶＣを含む安全モードは複数ある。
モニタプログラム７２は両方向の安全ドメインと非安全ドメインとのすべての切り換えを管理する役割を果たす。「プロセッサモード」の章において、図８および９を参照し、これら機能の一部について説明する。モニタプログラムは前記非安全モードから前記安全モードへの切り換えを開始するために、非安全モードで発行されたモード切り換えリクエストＳＭＩおよび前記安全モードから前記非安全モードへの切り換えを開始するために安全モードで発生されたモード切り換えリクエストＳＭＩに対して応答できる。「ワールド間の切り換え」なる章で説明したように、モニタモードでは安全ドメインおよび非安全ドメインの一方から他方へのレジスタのうちの少なくとも一部の切り換えが行われる。このことはあるドメインに存在するレジスタのステートをセーブし、他のドメインにあるレジスタへの新しいステートの書き込み（または以前にセーブされたステートをレジスタにリストアすること）を必要とする。本明細書でも説明したように、かかる切り換えを実行する際には一部のレジスタへのアクセスをディスエーブルすることができる。好ましくはモニタモードではすべてのインターラプトモードをディスエーブルする。
モニタモードが実行されるモニタモードは安全ドメインと非安全ドメインとにまたがっているので、モニタプログラムが恐らく安全であることが重要である。すなわちモニタプログラムは実行しようとする機能しか実行しない。従って、モニタプログラムはできるだけ簡単であれば有利である。安全モードによってプロセスが安全ドメインでしか実行できないようにすることができる。本発明のこの実施例では、特権安全モードおよびモニタモードにより同じ安全メモリおよび非安全メモリにアクセスすることが可能となっている。特権安全モードが同じ安全メモリおよび非安全メモリを「見る」ことを保証することにより、モニタモードでしか実行されない機能を安全モードに移し、モニタプログラムの簡略化を可能にできる。更に、このことによって特権安全モードで作動するプロセスが直接モニタプログラムに切り換わり、逆にモニタモードから特権安全モードに切り換わることができるようになる。特権安全モードからモニタモードへの切り換えが許可されると、モニタモードで非安全モードへの切り換えを行うことができる。非特権安全モードはモニタモードに入るのにＳＭＩを使用しなければならない。このシステムはリセット後、特権安全モードに入る。モニタモードと特権安全モードとの切り換えはドメイン間で移動するときのステートのセーブを容易にするように行われる。
別の実施例ではＳフラグへのアクセスは安全特権モードからだけでなくモニタモードからでも認められる。プログラムフローの制御を維持しながら、プロセッサをモニタモードに切り換えるように安全特権モードが認められる場合、かかる安全特権モードは有効にＳフラグ（ビット）を変える能力を既に有している。従って、モニタモードでしかＳフラグを変更できないことを定めるが、追加されることは是認されない。その代わり、１つ以上の安全特権モードにより変更できる他のコンフィギュレーションフラグを同じようにＳフラグを記憶できる。現在の技術には１つ以上の安全特権モード内でＳフラグを変更できるかかる実施例が含まれる。
次に、前に説明した実施例に戻ると、本装置はモードを定め、かつモードの特権レベル、すなわちモードが認める機能のセットを定めるプロセッサコア１０を有する。従って、このプロセッサコア１０は安全モードおよびモニタモードが安全および非特権メモリにアクセスでき、モニタモードがアクセスを認めているすべてのメモリへアクセスできるようにし、かつ特権安全モードで作動中のプロセスが直接モニタモードへ切り換わり、モニタモードから特権安全モードに切り換えできるように公知の態様で構成されている。このプロセッサコア１０は次のことを可能にするようになっていることが好ましい。
本発明の一例では、メモリは安全メモリと非安全メモリとに区分されており、安全メモリと非安全メモリの双方はモニタモードおよび安全モードでしかアクセスできない。非安全メモリはモニタモード、安全モードおよび非安全モードでアクセスできることが好ましい。
本発明の別の例では、モードおよび１つ以上の安全モードでは非安全メモリへのアクセスが安全モードに対して否定され、非安全モードでは非安全メモリへのアクセスが安全モードおよびモニタモードに対して否定される。従って、安全メモリはモニタモードおよび安全モードでしかアクセスできず、非安全メモリは非安全モードでしかアクセスできないので、セキュリティが高まる。
本発明の例では、装置のリセットまたはブートは安全モード、特権モードよりもより高い特権を有するモードと見なすことができるモニタモードで実行できる。しかしながら、本発明の多くの例では直接切り換えが安全モードとモニタモードとの間で認められているので、可能である安全モードでリセットまたはブートを行うようになっている。
図２を参照して説明したように、安全ドメインおよび安全モードでは安全カーネル８０（またはオペレーティングシステム）が機能し、この安全カーネル８０のもとで１つ以上の安全アプリケーションプログラム８２、８４が作動できる。安全カーネルおよび／または安全アプリケーションプログラム、または安全モードで作動するその他のプログラムコードは、安全メモリおよび非安全メモリの双方にアクセスすることが認められる。
プロセッサを有する装置を参照して本発明の例について説明したが、本発明は適当なプロセッサで作動するときにこの章で説明したように作動するようにプロセッサを構成するコンピュータプログラムによって実行できる。
プログラマーのモデルの見解から検討した本技術の別の実施例の説明を次のように図２１〜２３を参照して下記に示す。
次の説明では、英国ケンブリッジのＡＲＭリミテッド社によって設計されたようなＡＲＭプロセッサに関連して理解すべき次の用語を使用するものとする。
−Ｓビット：専用ＣＰ１５レジスタに含まれる安全ステートビット。
−「安全／非安全ステート」。このステートはＳビットの値によって定められ、このステートはコアが安全ワールドにアクセスできる（安全ステートとなっており、すなわちＳ＝１となっているとき）のか、または非安全ワールドだけに制限されている（Ｓ＝０）のかのいずれかを表示する。モニタモード（更に参照）は、Ｓビットステータスを無効にすることに留意されたい。
−「安全ワールド」は安全コードを実行するときにしかアクセスできないすべてのハードウェア／ソフトウェア（コア、メモリ....）をグループ分けする。
−モニタモード：安全ステートと非安全ステートとの間でコアを切り換える役割を果たす新しいモードである。
簡単な要約として、
−コアは常に非安全ワールドにアクセスできる。
−コアは安全ステートまたはモニタモードになっているときにしか、安全ワールドにアクセスできない。
−ＳＭＩ：ソフトウェアモニタインターラプト：専用ＳＭＩ例外ベクトルによりコアがモニタモードに入るようにする新しい命令である。「スレッドＩＤ」は（ＯＳによって制御される）各スレッドに関連した識別子である。ＯＳが非安全ワールドで作動する一部のタイプのＯＳに対し、安全機能がコールされるごとに現在のスレッドＩＤをパラメータとして送り、安全機能と、そのコールしている非安全アプリケーションとをリンクしなければならない。従って、安全ワールドはマルチスレッドをサポートできる。
−安全インターラプトは安全周辺機器が発生したインターラプトを定める。
プログラマーのモデル
カーボン（Ｃａｒｂｏｎ）コアの概観
本技術を使用するプロセッサに対して本明細書で使用する用語であるカーボンアーキテクチャの概念は、２つのワールド、すなわち安全ワールドと非安全ワールドとに分離することから成る。安全ワールドは非安全ワールドにどんなデータもリークしてはならない。
提案する解決案では、安全ステートと非安全ステートとは同じ（現在存在する）レジスタバンクを共用する。この結果、ＡＲＭコアに存在するすべての現在のモード（Ａｂｏｒｔ（アボート）、Ｕｎｄｅｆ（無定義）、ＩＲＱ、Ｕｓｅｒ（ユーザー）、....が各ステートで存在することになる。
コアは専用ＣＰ１５レジスタ内でインスタンス生成される新しいステートビット、Ｓ（安全）ビットにより、自らが安全ステートで作動しているのか、または非安全ステートで作動しているのかを知る。
Ｓビットを変更するのに、すなわちあるステートから別のステートに変更するのに、どの命令またはイベントを許可するかを制御することが、本システムのセキュリティのキーとなる特徴である。現在の解決案は新しいモード、すなわち２つのステートの間の切り換えを監督するモニタモードを追加することを提案する。モニタモードは適当なＣＰ１５レジスタへの書き込みによりＳビットを変更することが認められた唯一のモードとなっている。
最後に、例外の取り扱いにある程度のフレキシビリティを追加することを提案するものである。リセットを除くすべての例外は、生じたステートまたはモニタモードに向けられたステートのいずれかで取り扱われ、この例外の取り扱いは専用ＣＰ１５レジスタにより構成可能なままとされる。
次のパラグラフでこの解決案の詳細について説明する。
プロセッサステートおよびモード
カーボンの新しい特徴
安全または非安全ステート（Ｓビット）
カーボンコアの主な１つの特徴は、Ｓビットが存在していることであり、このＳビットはコアが安全（Ｓ＝１）ステートとなっているか、または非安全（Ｓ＝０）ステートとなっているかのいずれかを表示する。安全ステートとなっているとき、コアは安全ワールドまたは非安全ワールド内のどのデータにもアクセスできる。非安全ステートとなっているときにコアは非安全ワールドだけに限定される。
この規則に対する唯一の例外は、Ｓビット情報を無効にするモニタモードに関係している。Ｓ＝０でも、コアはモニタモードとなっていれば安全特権アクセスを実行する。更なる情報がほしい場合には次のパラグラフであるモニタモードを参照されたい。
Ｓビットはモニタモードで読み出し書き込みできるにすぎない。Ｓビットがどんな値となっていても、他のモードがこのビットにアクセスしようとしても、このアクセスは無視されるか、またはその結果、Ｕｎｄｅｆｉｎｅｄ（無定義）例外が生じる。
リセットを除くすべての例外は安全ステートビットに影響しない。リセット時にＳビットがリセットされ、コアはスーパーバイザーモードでスタートする。より詳細な情報がほしい場合にはブートの章を参照されたい。
安全ステート／非安全ステートは別個であり、ＡＲＭ／Ｔｈｕｍｂ／Ｊａｖａ（登録商標）ステートと別個に作動する。
モニタモード
カーボンシステムの別の重要な特徴は、新しいモード、モニタモードを作成したことである。このモードは安全ステートと非安全ステートとの間のコアの切り換えを制御するのに使用される。このモニタモードは常に安全モードと見なされる。すなわちＳビットの値がどんな値であってもコアがモニタモードになっていると、コアは常に外部ワールドへの安全特権アクセスを実行する。
ＣＰＳＲモードビット（ＭＳＲ、ＭＯＶＳまたは等価的な命令）を書き込むだけで、どの安全特権モード（例えばＳ＝１のときの特権モード）もモニタモードに切り換わることができる。しかしながら、この切り換えは非安全モードまたは安全ユーザーモードでは禁止される。このことが起こった場合、命令は無視されるか、または例外を生じさせる。
専用ＣＰＳＲ違反例外に対するニーズが生じ得る。この例外は非安全モードまたは安全ユーザーモードからＣＰＳＲを直接書き込むことにより、モニタモードへの切り換えの試みにより生じる。
モニタモードがアクティブとなっているときにはリセットを除くすべての例外を実際にディスエーブルする：
・すべてのインターラプトをマスクする。
・すべてのメモリ例外を無視するか、またはこれら例外によって致命的例外が生じる。
・無定義／Ｕｎｄｅｆｉｎｅｄ／ＳＷＩ／ＳＭＩを無視するか、またはこれらによって致命的例外が生じる。
モニタモードに入るとき、インターラプトを自動的にディスエーブルし、システムモニタが作動中は他のタイプの例外が全く生じないよう、システムモニタを書き込むべきである。
モニタモードはあるプライベートレジスタを有する必要がある。この解決案は、レジスタの最小のセット、すなわちＲ１３（ｓｐ＿ｍｏｎ）、Ｒ１４（ｌｒ＿ｍｏｎ）およびＳＰＳＲ（ｓｐｓｒ＿ｍｏｎ）しか複製しないことを提案する。
モニタモードではＭＭＵをディスエーブルする（フラットアドレスマップ）だけでなく、ＭＰＵまたはパーティションチェッカーもディスエーブルする（モニタモードは常に安全特権外部アクセスを実行する）。しかしながら、特別にプログラムされたＭＰＵ領域の属性（キャッシュ性....）はまだアクティブである。別の例として、モニタモードが安全ドメインによって使用されているどのマッピングも使用できる。
新しい命令
この提案は、現在のＡＲＭ命令セットに１つの新しい命令を追加しなければならない。
モニタモードに入り、固定ＳＭＩ例外ベクトルで分岐するのにＳＭＩ（ソフトウェアモニタインターラプト）命令が使用される。この命令は非安全ステートと安全ステートとの間で切り換わることをモニタに表示するのに主に使用される。
別の例として（またはその追加として）、モニタモードがモニタスタックに、またはモニタスタックから、他のモードのステートをセーブ／リストアし、コンテクスト切り換え性能を改善できるようにするために、新しい命令を追加することが可能である。
プロセッサモード
前のパラグラフで説明したように、コアでは１つの新しいモード、すなわちモニタモードしか追加されない。現在のすべてのモードは利用できるままであり、安全ステートおよび非安全ステートで存在する。
実際にカーボンユーザーは図２１に示された構造を見ることになる。
プロセッサレジスタ
この実施例は、安全ワールドと非安全ワールドとが同じレジスタバンクを共用することを提案するものである。このことは、あるワールドからモニタモードを通して別のワールドに切り換わるときに、システムモニタは最初にワールドコンテクストをセーブし、第２のワールド内にコンテクストを作成（またはリストア）しなければならないことを意味する。
パラメータを送ることは容易なタスクとなる。システムモニタが一旦Ｓビットを切り換えた場合、最初のワールド内のレジスタに含まれたデータは第２ワールド内の同じレジスタで利用できるようになる。
しかしながら、厳密に制御しなければならないパラメータを送るための専用の限られた数のレジスタとは別に、安全データがリークするのを防止するために、安全ステートから非安全ステートに移る際に他のすべてのレジスタをフラッシングしなければならない。これはモニタカーネルによって保証しなければならない。
安全ステートから非安全ステートに切り換わるときに、レジスタを直接フラッシュするためのハードウェアメカニズムまたは新しい命令を実行できるようにすることも１つの可能性である。
提案される別の解決案は、現在存在するレジスタバンクのすべて（またはほとんど）をコピーし、よって安全ステートと非安全ステートとの間で２つの物理的に分離されたレジスタバンクを設けることである。この解決案はレジスタ内に含まれる安全データと非安全データとを明瞭に分離するという主な利点を有する。更にこのことは、安全ステートと非安全ステートとの間の高速のコンテクストの切り換えも可能にする。しかしながら、欠点として安全ワールドの非安全レジスタへのアクセスを可能にするある専用命令を作成しなければ、レジスタを通してパラメータを送ることが困難となるということが挙げられる。
図２２は、プロセッサモードに応じて利用できるレジスタを示す。プロセッサのステートはこの主題に影響するものではないことに留意されたい。
例外
安全インターラプト
現在の解決案
現在のコア内と同じインターラプトピン、例えばＩＲＱおよびＦＩＱを維持することが現在提案されている。（本明細書の後半で定義する）例外トラップマスクレジスタに関連し、システムが異なる種類のインターラプトを実行し、取り扱いできるようにする十分なフレキシビリティがなければならない。
ＶＩＣエンハンスメント
次のようにＶＩＣ（ベクトル化されたインターラプトコントローラ）を強化できる。このＶＩＣは各ベクトル化されたアドレスに関連する１つの安全情報ビットを含むことができる。このビットはモニタまたは安全特権モードでしかプログラムできない。このビットは当該インターラプトを安全として取り扱い、従って、安全側で取り扱うべきかどうかを表示する。
我々は２つの新しいベクトルアドレスレジスタも追加する。すなわち１つは、非安全ステートで生じるすべての安全インターラプト用のレジスタであり、他方は、安全ステートで生じるすべての非安全インターラプト用のレジスタである。
ＣＰ１５に含まれるＳビット情報は新しいＶＩＣ入力としてＶＩＣにも利用できる。
次の表は着信インターラプトのステータス（各インターラプトラインに関連するＳビットによって表示される安全または非安全）およびコアのステート（ＣＰ１５内のＳビット＝ＶＩＣ上のＳ入力信号）に応じた異なる可能性のあるシナリオを要約したものである。
Figure 2006506752
例外取り扱いコンフィギュレーション性
Ｃａｒｂｏｎのフレキシビリティを改善するためにＣＰ１５に新しいレジスタ、すなわち例外トラップマスクを追加する。このレジスタは次のビットを含む。
−ビット０：Ｕｎｄｅｆ例外 （非安全ステート）
−ビット１：ＳＷＩ例外 （非安全ステート）
−ビット２：プリフェッチアボート例外 （非安全ステート）
−ビット３：データアボート例外 （非安全ステート）
−ビット４：ＩＲＱ例外 （非安全ステート）
−ビット５：ＦＩＱ例外 （非安全ステート）
−ビット６：ＳＭＩ例外 （非安全ステート／安全ステートの双方）
−ビット１６：Ｕｎｄｅｆ例外 （非安全ステート）
−ビット１７：ＳＷＩ例外 （非安全ステート）
−ビット１８：プリフェッチアボート例外 （非安全ステート）
−ビット１９：データアボート例外 （非安全ステート）
−ビット２０：ＩＲＱ例外 （非安全ステート）
−ビット２１：ＦＩＱ例外 （非安全ステート）
リセット例外はこのレジスタに対応するビットを有しない。リセットは常に専用ベクトルを通してコアを安全スーパーバイザーモードに進入させる。
ビットがセットされている場合、対応する例外はコアをモニタモードに進入させる。そうでない場合、例外が生じたワールド内の対応するハンドラー内で例外が取り扱われる。
このレジスタはモニタモードでしか見ることができない。他のモードにおいて、このレジスタにアクセスしようとする命令は無視される。
このレジスタはシステムがモニタをサポートしているか否かに応じてシステム固有の値に初期化すべきである。この機能はＶＩＣによって制御できる。
例外ベクトルの表
別個の安全ワールドと非安全ワールドとが生じるので、別個の安全例外別個の表と非安全例外ベクトルの表も必要となる。
更にモニタは一部の例外をトラップし得るので、モニタ専用の第３の例外ベクトルの表も必要となる。
次の表は３つの異なる例外ベクトルの表を要約したものである。
Figure 2006506752
Figure 2006506752
Figure 2006506752
モニタモードでは例外ベクトルがコピーされるので、各例外は２つの異なる関連ベクトルを有する。
−１つのベクトルは非安全ステートで生じた例外用のベクトルであり、
−１つのベクトルは安全ステートで生じた例外用のベクトルである。
モニタカーネルは例外が生じた場合に発生ステートを検出する必要性をそれ以上必要としないので、このことは例外待ち時間（ｌａｔｅｎｃｙ）を小さくするのに有効となり得る。
この特徴は、数種の例外に限られており、ＳＭＩは安全ステートと非安全ステートとの切り換えを改善するための最も適当な候補の１つである。
ワールド間の切り換え
ステートを切り換える際に、モニタモードはそのモニタスタックに最初のステートのコンテクストをセーブし、モニタスタックからの第２のステートのコンテクストをリストアしなければならない。
従って、モニタモードはプライベートレジスタ（ｒｌ４、ＳＰＳＲ、....）を含む他の任意のモードのレジスタにアクセスしなければならない。
これを取り扱うために、提案された解決案はＣＰＳＲを書き込むだけでモニタモードに直接切り換える権利を、安全ステートにおける特権モードに与えることから成る。
かかるシステムでは、ワールド間の切り換えを次のように実行する。
−モニタモードに入る。
−Ｓビットをセットする。
−スーパーバイザーモードに切り換え、 −モニタスタックにスーパーバイザーレジスタをセーブする（当然ながらスーパーバイザーモードはモニタスタックポインタにアクセスしなければならないが、これは例えば共通レジスタ（Ｒ０〜Ｒ８）を使用することにより容易に行うことができる。
−システムモードに切り換え、 −モニタスタックにレジスタ（ユーザーモードと同じ）をセーブする。
−すべてのモードに対してモニタスタック上のＩＲＱレジスタ．．．．等々。
−すべてのモードのすべてのプライベートレジスタを一旦セーブすると、簡単なＭＳＲ命令によりモニタモードへ戻る（＝ＣＰＳＲモードフィールド内にモニタ値を単に書き込む）。
その他の解決案も検討した。
−モニタが自己のスタックに他のモードのプライベートレジスタをセーブできるようにする新しい命令を加えること。
−モニタを新しい「ステート」として実行すること。すなわち（適当なアクセス権を有するように）モニタステートとなり、ＩＲＱ（または他の）モードとなり、ＩＲＱ（または他の）プライベートレジスタを見ることができるようにすること。
基本的なシナリオ（図２３参照）
１．スレッド１は非安全ワールドで作動中である（Ｓビット＝０）。このスレッドは安全機能＝＞ＳＭＩ命令を実行しなければならない。
２．ＳＭＩ命令は非安全ＳＭＩベクトルを通してコアを入力モードにする。
非安全モードのＰＣおよびＣＰＳＲをセーブするようにＬＲ＿ｍｏｎおよびＳＰＳＲ＿ｍｏｎを使用する。
この段階ではＳビットは無変更のままであるが、システムはそのときに安全ステートにある。
モニタカーネルはモニタに非安全コンテクストをセーブする。
モニタカーネルはＬＲ＿ｍｏｎおよびＳＰＳＲ＿ｍｏｎもプッシュする。
次にモニタカーネルはＣＰ１５レジスタに書き込むことによって「Ｓ」ビットを変更する。
この実施例ではモニタカーネルは（例えばスレッドＩＤテーブルを更新することにより）安全ワールドで「安全スレッド１」をスタートするトラックを維持する。
最後に、モニタカーネルはモニタモードから出て安全スーパーモードに切り換わる。「ＬＲ＿ｍｏｎおよびＳＰＳＲ＿ｍｏｎを更新した後のＭＯＶＳ命令」
３．安全カーネルはアプリケーションを正しい安全メモリロケーションへディスパッチし、（例えばＭＯＶＳを使って）ユーザーモードに切り換わる。
４．安全ユーザーモードで安全機能を実行する。一旦終了すると、安全機能は適当なＳＷＩを実行することによって「出口」機能をコールする。
５．ＳＷＩ命令は専用ＳＷＩベクトルを通してコアを安全ＳＶＣモードにし、次に専用ＳＷＩベクトルは「出口」機能を実行する。この「出口」機能はモニタモードに戻るように切り換わるよう、「ＳＭＩ」により終了する。
６．ＳＭＩ命令は専用安全ＳＭＩベクトルを通してコアをモニタモードにする。
安全ｓｖｃモードのＰＣおよびＣＰＳＲをセーブするのにＬＲ＿ｍｏｎおよびＳＰＳＲ＿ｍｏｎを使用する。
Ｓビットは無変更のままである（すなわち安全ステート）。
モニタカーネルは安全スレッド１が終了した事実を登録する（スレッドＩＤテーブルから安全スレッド１のＩＤを除く）。
次にモニタカーネルはＣＰ１５レジスタに書き込みをすることにより「Ｓ」ビットを変更し、非安全ステートに戻る。
モニタカーネルはモニタスタックから非安全コンテクストをリストアする。
モニタカーネルはステップ２で前にセーブしたＬＲ＿ｍｏｎおよびＣＰＳＲ＿ｍｏｎもロードする。
最後に、モニタカーネルはＳＵＢＳによりモニタモードから出る。これによってコアは命令時に非安全ユーザーモードに戻る。
７．通常、スレッド１がレジュームできる。
図６を参照すると、すべてのレジスタは安全ドメインと非安全ドメインとの間で共用される。モニタモードでは安全ドメインおよび非安全ドメインのうちの一方から他方へレジスタを切り換える切り換えが行われる。これを行うには、上記「ワールド間の切り換え」の章でも説明したように、一方のドメインにあるレジスタのステートをセーブし、レジスタへの間のステートを他方のドメインに書き込み（またはレジスタ内の前にセーブしたステートをリストア）しなければならない。
この切り換えを行うのにかかる時間を短縮するのが望ましい。切り換えを行うのにかかる時間を短縮するには、安全ドメインと非安全ドメインとの切り換え時に共用されるレジスタをディスエーブルし、内部に記憶されているデータ値を変えないままにする。例えば非安全ドメインから安全ドメインへの切り換えを検討する。例えば図６に示されたＦＩＱレジスタは安全ワールドでは必要でないと仮定する。従って、これらレジスタをディスエーブルし、これらレジスタを安全ドメインに切り換える必要はなく、これらレジスタのコンテンツをセーブする必要もない。
レジスタをディスエーブルすることはいくつかの方法で行うことができる。１つの方法は、これらレジスタを使用するモードをロックアウトすることである。モードをディスエーブルすることを表示する制御ビットをＣＰ１５レジスタに書き込むことによってこれを行う。
これとは異なり、ＣＰ１５レジスタに再び制御ビットを書き込むことにより、命令に基づく方法によって命令時にレジスタへのアクセスをディスエーブルしてもよい。ＣＰ１５レジスタに書き込まれるビットはモードではなくレジスタに明示的に関係しているので、モードはディスエーブルされず、このモードはディスエーブルされず、このレジスタへのアクセスがディスエーブルされる。
ＦＩＱレジスタは高速インターラプトに関連するデータを記憶する。ＦＩＱレジスタがディスエーブルされ、高速インターラプトが生じた場合、プロセッサはモニタでの例外を表示する信号を発生する。この例外に応答し、モニタモードは１つのドメインに関連し、前記ディスエーブルされたレジスタ内に記憶されていたデータ値をセーブし、他方のドメインに関連した新しいデータ値をディスエーブルされたレジスタにロードし、ＦＩＱモードレジスタを再イネーブルする。
プロセッサはドメインを切り換える際にモニタモードですべてのバンクレジスタをディスエーブルするようにプロセッサを構成できる。これとは異なり、ドメインを切り換える際に共用レジスタの所定のレジスタをディスエーブルし、他方をプログラマーの選択によってディスエーブルしてもよいという点で、レジスタのディスエーブル化を選択的とすることができる。
モニタモードでドメインを切り換える際に、１つ以上の共用レジスタをディスエーブルし、１つ以上の他方の共用レジスタが一方のドメインを出るときにセーブされたデータを有し、他方のドメインにロードされた新しいデータを有するようにプロセッサを構成してもよい。新しいデータをゼロデータとすることができる。
図２４は従来のＡＲＭコアに安全処理オプションを追加する原理を略図で示す。この図は現在あるコアに安全処理オプションを追加することにより、安全処理オプションを含むプロセッサをどのように形成できるかを略図で示している。現在存在する遺産オペレーティングシステムと後方コンパーチブルとすべき場合、プロセッサの従来の非安全部分で作動する遺産システムが直観的に考えられる。しかしながら、この図の下方部分に略で示し、更に下記で詳細に説明するように、実際には遺産システムが作動するのはシステムの安全部分内である。
図２５は安全および非安全ドメインを有するプロセッサを示し、更にリセットを示し、図２と同様な図となっている。図２は安全ドメインでの処理を制御する安全ＯＳシステムおよび非安全ドメインでの処理を制御する非安全ＯＳシステムにより、セキュリティ機密タイプのオペレーションを作動させるようになっているプロセッサを示す。しかしながら、このプロセッサは従来の遺産オペレーティングシステムに後方コンパーチブルでもあるので、プロセッサは遺産オペレーティングシステムを使ってセキュリティに機密でないように作動し得る。
図２５に示されるように、リセットは安全ドメイン内にあり、ここではＳビットまたはセキュリティステータスフラグセットによりどんなタイプのオペレーションのリセットも生じる。セキュリティ非機密タイプのオペレーションの場合、安全ドメインでリセットが生じ、処理は安全ドメイン内で続く。しかしながら、処理を制御する遺産オペレーティングシステムはシステムのセキュリティの特徴については知らない。
図２５に示されるように、処理を安全機密状態とすべきか、または実際に安全に非機密状態とするのかに応じて、安全スーパーバイザーモード内での処理をスタートさせるアドレスを設定するようにリセットが行われる。一旦リセットが行われると、次にブートまたは再ブート手順内に存在する追加タスクが実行される。このブート手順については後述する。
ブート手順
ブート手順は次の特徴を尊重しなければならない。
−遺産ＯＳとのコンパチビリティを維持すること。
−システムのセキュリティを保証するように、最も特権性のあるモードでブートすること。この結果、カーボンコアは安全スーパーバイザーモードでブートすることになる。
次に、異なるシステムは次のようになる。
−遺産ＯＳを作動させたいシステムに対してはＳビットを考慮せず、コアはスーパーバイザーモードでブートする
−カーボンの特性を使用したいシステムに対しては（潜在的にモニタモードにスワップした後に）コアはシステム内のすべての安全保護を構成できるようにしなければならない安全特権モードでブートする。
上記ブート手順の詳細に関し、本発明の実施例のプロセッサはすべてのケースにおいて安全スーパーバイザーモードで処理をスタートするようにプロセッサをリセットする。セキュリティに機密でないタイプのオペレーションの場合、Ｓビットがセットされているので（しかしながらオペレーティングシステムはこのことを知らない）セキュリティはここでは問題ではないが、オペレーティングシステムは実際には安全ドメインで作動中である。このことには、非安全ドメインからアクセスできないメモリ部分はこの状況ではアクセス可能であるという利点がある。
セキュリティに機密であるシステムはシステムのセキュリティを保証するのに役立つので、すべてのケースにおいて安全スーパーバイザーモードでブートすることはセキュリティに機密なシステムでも有利である。安全機密システムでは、ブート時に提供されるアドレスは安全スーパーバイザーモードでブートプログラムを記憶した場所をポイントするので、システムを安全システムとして構成し、モニタモードへの切り換えを可能にする。一般に安全スーパーバイザーモードからモニタモードへの切り換えが認められ、この切り換えはモニタモードコンフィギュレーションを初期化するよう、適当な時間の安全システムがモニタモードでの処理をスタートできるようにする。
図２６はステップ１において非安全スレッドＮＳＡが非安全オペレーティングシステムによって実行されることを示す。ステップ２において、非安全スレッドＮＳＡはモニタモードを介して安全ドメインをコールし、ステップ３においてモニタモードプログラムを作動させる。モニタモードプログラムはＳビットを変更し、ドメインを切り換え、ステップ５で安全オペレーティングシステムに移る前に必要なコンテクストのセーブおよびコンテクストのリストアを行う。次にステップ６においてインターラプトＩＲＱを受ける前に、対応する安全スレッドＳＡを実行する。ステップ７でインターラプト取り扱いハードウェアがモニタモードへのリターンをトリガーし、ここでインターラプトを安全オペレーティングシステムで取り扱うのか、または非安全オペレーティングシステムで取り扱うのかが判断される。この場合、インターラプトはステップ９でスタートする非安全オペレーティングシステムによって取り扱われる。このインターラプトが非安全オペレーティングシステムによって取り扱われると、ステップ１１において通常のスレッド切り換え動作の前に非安全スレッドＮＳＡは非安全オペレーティングシステムにおける現在のタスクとしてレジュームされる。このスレッドの切り換えはタイミングイベントまたは同等なものの結果とすることができる。ステップ１２では、非安全オペレーティングシステムにより非安全ドメインで異なるスレッドＮＳＢが実行され、次にステップ１４においてこのことは、モニタドメイン／プログラムを介し、安全ドメインへのコールを行う。ステップ７におけるモニタプログラムは安全スレッドが既に実行を終了しているので、または通常のリクエストが残っていることに起因し、安全オペレーティングシステムが残されているのではなく、インターラプトの結果として最後にサスペンドされたことを表示するためのフラグを記憶しており、他の一部の手順を使用する。従って、安全オペレーティングシステムはインターラプトによってサスペンドされたのでステップ１５におけるモニタプログラムはリターンスレッドＩＤ（例えば非安全スレッドＮＳＢがリクエストしたような安全オペレーティングシステムによってスタートすべきスレッドの識別子だけでなく、その他のパラメータデータ）を指定する、ソフトウェア疑似インターラプトを使用する安全オペレーティングシステムに再進入する。ソフトウェア疑似インターラプトのこれらパラメータをレジスタ値として送ることができる。
ソフトウェア疑似インターラプトはステップ１５において安全オペレーティングシステムのリターンインターラプトハンドラールーチンをトリガーする。このリターンインターラプトハンドラールーチンはソフトウェア疑似インターラプトのリターンスレッドＩＤを検査し、このＩＤがサスペンド前に安全オペレーティングシステムが実行され、最後にインターラプトされた安全スレッドＳＡのスレッドＩＤと一致するかどうかを判断する。この場合、一致せず、従ってステップ１６では安全オペレーティングシステムは安全スレッドＳＡのコンテクストがセーブされた後に、非安全スレッドＮＳＢによって指定されたリターンスレッドへのスレッドの切り換えを実行するようにトリガーされる。次に、必要なようにインターラプトされたポイントから後に安全スレッドＳＡを再スタートできる。
図２７は図２６に示された挙動の別の例のタイプを略図で示す。この例では、ＩＲＱを取り扱うために非安全オペレーティングシステムの制御下で処理が続行される間、非安全スレッドの切り換えはないので、安全オペレーティングシステムのリターンインターラプトハンドラーによりソフトウェア疑似インターラプトが受信されると、オペレーティングシステムはスレッドの切り換えは不要であると判断し、ステップ１５で安全スレッドＳＡをレジュームするだけである。
図２８はリターンスレッドハンドラーによって実行される処理を略図で示すフローチャートである。ステップ４００２において、リターンスレッドハンドラーがスタートされる。ステップ４００４において、ソフトウェア疑似インターラプトからのリターンスレッド識別子が検査され、安全オペレーティングシステムがサスペンドされたときに、現在実行中の安全スレッドと比較される。これらが一致した場合、処理はステップ４００６に進み、ここで安全スレッドがレジュームされる。ステップ４００４での比較が一致していない場合、処理はステップ４００８に進み、ここでステップ４０１０での新しい安全スレッドへの切り換えが行われる前に、（その後のレジュームのために）旧い安全スレッドのコンテクストがセーブされる。新しいスレッドは既に途中にあるので、ステップ４０１０はレジュームである。
図２９はスレーブ安全オペレーティングシステムがマスター非安全オペレーティングシステムによって実行されるタスクの切り換えに従うことができるようにする処理を略図で示す。マスター非安全オペレーティングシステムは他のオペレーティングシステムとそのアクティビティを伝え、コーディネートする手順を有しない遺産オペレーティングシステムであり得るので、マスターとしてしか作動しない。図２９における初期進入ポイントでは、非安全オペレーティングシステムは非安全スレッドＮＳＡを実行中である。この非安全スレッドＮＳＡはソフトウェアのインターラプト、例えばＳＭＩコールを使って安全オペレーティングシステムにより実行すべき安全スレッドへのコールを行う。このＳＭＩコールはステップ２においてモニタモードで実行中のモニタプログラムに進み、ここでモニタプログラムはステップ４における安全オペレーティングシステムへコールを送る前に、必要なコンテクストのセーブおよび切り換えを実行する。次に安全オペレーティングシステムは対応する安全スレッドＳＡをスタートさせる。この安全スレッドはモニタモードを介し、タイマー事象の結果として非安全オペレーティングシステムへ制御をリターンできる。ステップ９において非安全スレッドＮＳＡが再び安全オペレーティングシステムに制御を送るとき、このＮＳＡは元のソフトウェアインターラプトを再発生することによってこれを行う。ソフトウェアインターラプトはＮＳＡを識別する非安全スレッドＩＤ、アクティブにすべきターゲット安全スレッドの安全スレッドＩＤ、例えば安全スレッドＳＡを識別するスレッドＩＤだけでなくその他のパラメータも含む。
ステップ９で発生したコールはモニタプログラムにより送られ、ステップ１２にて安全オペレーティングシステムにより安全ドメイン内で受信されると、非安全オペレーティングシステムによるコンテクストの切り換えがあったかどうかの判断をするために非安全スレッドＩＤを検査できる。安全オペレーティングシステム下の正しいスレッドが新しいスレッドとして再スタートされたか、またはスタートされたかを見るために、ターゲットスレッドの安全スレッドＩＤを検査することもできる。図２９の例では、安全オペレーティングシステムにより安全ドメイン内でスレッドの切り換えは不要とされる。
図３０は図２９に類似するが、ステップ９において、非安全オペレーティングシステムの制御下の非安全ドメイン内でスレッドの切り換えが行われる点が異なっている。従って、ステップ１１において安全オペレーティングシステムに対し、ソフトウェアのインターラプトコールをするのは別の非安全スレッドＮＳＢである。ステップ１４では安全オペレーティングシステムは非安全スレッドＮＳＢの異なるスレッドＩＤを認識し、よって安全スレッドＳＡのコンテクストをセーブし、安全スレッドＳＢをスタートさせることに関係するタスクの切り換えを行う。
図３１は安全オペレーティングシステムのスレッドをスタートさせるか、またはスレッドをレジュームするためのコールとしてソフトウェアインターラプトを受信したときに安全オペレーティングシステムが実行する処理を略図で示すフローチャートである。ステップ４０１２ではコールが受信される。ステップ４０１４ではパラメータが安全オペレーティングシステムでの現在アクティブな安全スレッドに一致するかどうかを判断するように、コールのパラメータが検査される。一致している場合、ステップ４０１６でこの安全スレッドを再スタートする。一致していなければ、ステップ４０１８に進み、ここで新しくリクエストされたスレッドを利用できるかどうかの判断を行う。新たにリクエストされたスレッドが安全オペレーティングシステムで実行中の他のあるスレッドによって既に使用されている排他的リソースであるか、または排他的リソースを必要とするような理由により、利用できないことがある。かかるケースでは、非安全オペレーティングシステムにリターンされた適当なメッセージにより、ステップ４０２０でコールを拒否する。ステップ４０１８における判断の結果が新しいスレッドを利用できるという判断である場合、処理はステップ４０２２に進み、ここで後に起こり得るレジュームのために旧い安全スレッドのコンテクストをセーブする。ステップ４０２４において、安全オペレーティングシステムに対してなされたソフトウェアインターラプトコール内で指定された新しい安全スレッドへの切り換えが行われる。
図３２は異なるインターラプトを有する多数のオペレーティングシステムを有するシステム内で取り扱いのインターラプトが異なるオペレーティングシステムによって処理されると、プライオリティの反転が生じ得るようなオペレーションを略図で示す。
この処理が安全スレッドＳＡを実行する安全オペレーティングシステムによりスタートする。この処理は最初のインターラプトＩｎｔ１によりインターラプトされる。これはインターラプトを安全ドメイン内または非安全ドメイン内で処理すべきかどうかを判断するのに、モニタモード内のモニタプログラムをトリガーする。この場合、インターラプトは安全ドメイン内で処理すべきであり、処理は安全オペレーティングシステムに戻され、インターラプトＩｎｔ１のためのインターラプト取り扱いルーチンがスタートされる。Ｉｎｔ１のためのインターラプト取り扱いルーチンの実行の途中において、より高いプライオリティを有する別のインターラプトＩｎｔ２が受信される。従って、Ｉｎｔ１のためのインターラプトハンドラーが停止され、インターラプト２を取り扱うべきかどうかの判断をするのにモニタモード内のモニタプログラムが使用される。この場合、非安全オペレーティングシステムによりインターラプトＩｎｔ２を取り扱うべきであるので、制御は非安全オペレーティングシステムへ送られ、Ｉｎｔ２のためのインターラプトハンドラーがスタートされる。インターラプトＩｎｔ２のためのこのインターラプトハンドラーが完了すると、非安全オペレーティングシステムは安全ドメイン内でサービスをサスペンドしたペンディング中のインターラプトＩｎｔ１があるかどうかを表示する情報を有していない。従って、非安全オペレーティングシステムは別の処理、例えばタスクの切り換え、異なる非安全スレッドＮＳＢのスタートを実行でき、他方、元のインターラプトＩｎｔ１はサービスされないままである。
図３３は、図３２のオペレーションに関連する問題を回避できるようにする技術を示す。インターラプトＩｎｔ１が生じると、モニタプログラムはこれを非安全ドメインへ送り、ここでスタブインターラプトハンドラーがスタートされる。このスタブインターラプトハンドラーは比較的小さく、モニタモードを介して処理を安全ドメインに迅速に戻し、安全ドメイン内のインターラプトＩｎｔ１のためのインターラプトハンドラーをトリガーする。このインターラプトＩｎｔ１は主に安全ドメイン内で処理され、非安全ドメイン内のスタブインターラプトハンドラーの開始は安全ドメイン内でインターラプトがペンディング中となっていることを非安全ドメインに表示するためのあるタイプのプレイスホルダと見なすことができる。
インターラプトＩｎｔ１のための安全ドメイン内のインターラプトハンドラーは再び高いプライオリティのＩｎｔ２を受ける。このことは前と同じように非安全ドメイン内のインターラプトＩｎｔ２のためのインターラプトハンドラーの実行をトリガーする。しかしながらこの場合、Ｉｎｔ２のためのそのインターラプトハンドラーが終了するとき、非安全オペレーティングシステムはインターラプトＩｎｔ１のためのスタブインターラプトハンドラーが未解決であることを示すデータを有するので、このスタブインターラプトハンドラーをレジュームする。このスタブインターラプトハンドラーはあたかも安全ドメインへコールバックしたポイントでサスペンドされたかのように見えるので、このコールは再実行され、従って安全ドメインへの切り換えが行われる。一旦安全ドメインに戻ると、安全ドメイン自身はインターラプトＩｎｔ１がサスペンドされたポイントにおいて、インターラプトＩｎｔ１のためのインターラプトハンドラーを再スタートできる。安全ドメイン内でインターラプトＩｎｔ１のためのインターラプトハンドラーが完了すると、もともと実行中の安全スレッドＳＡがレジュームされる前に非安全ドメイン内のスタブインターラプトハンドラーを閉じるよう、非安全ドメインに対するコールがなされる。
図３４は関連するプライオリティを有する異なるタイプのインターラプトおよびそれらをどのように取り扱うことができるかを略図で示す。高いプライオリティのインターラプトは非安全ドメインによって取り扱われるより高いプライオリティのインターラプトがないことを条件に、純粋に安全なドメインのインターラプトハンドラーを使用して取り扱うことができる。その後のインターラプトよりも高いプライオリティを有し、非安全ドメイン内で取り扱われるインターラプトがあった場合、すべてのより低いインターラプトを純粋に安全ドメイン内で取り扱わなければならないか、またはこれらすべてのプライオリティの低いインターラプトは、図３３に示されるスタブインターラプトハンドラー技術を利用しなければならず、よって安全ドメイン内で主な取り扱いが行われた場合でも非安全ドメインはこれらインターラプトのトラックを維持できる。
前に述べたように、安全ドメインと非安全ドメインとの切り換えを実行するのにモニタモードが使用される。２つの異なるドメインの間でレジスタを共用する実施例では、これらレジスタ内のステートをメモリにセーブし、宛て先ドメインのための新しいステートをメモリからこれらレジスタにロードしなければならない。２つのドメイン間では共用されないレジスタに関してはステートをセーブする必要はない。その理由は、これらレジスタには他のドメインからアクセスされることはなく、ステート間の切り換えは、安全ドメインと非安全ドメインの切り換えの直接の結果として実行される（すなわちＣＰ１５レジスタのうちの１つに記憶されたＳビットの値は非共用レジスタのどれを使用するかを決定する）からである。
モニタモードの間で切り換えしなければならないステート部分はプロセッサによるメモリへのアクセスを制御するプロセッサコンフィギュレーションデータである。各ドメイン内にはメモリの異なるビュー、例えば安全データを記憶するために安全メモリにアクセスする安全ドメインがあり、この安全メモリは非共用ドメインからアクセスできないので、ドメイン間を切り換えるときにプロセッサコンフィギュレーションデータを変更しなければならないことは明らかである。
図３５に示されるように、ＣＰ１５レジスタ３４内にはこのプロセッサコンフィギュレーションデータが記憶され、一実施例ではドメインの間でこれらレジスタが共用される。従って、安全ドメインと非安全ドメインとの間でモニタモードを切り換えるときには、そのときにＣＰ１５レジスタ３４内にあるプロセッサコンフィギュレーションデータをＣＰ１５レジスタからメモリに切り換える必要があり、宛て先ドメインに関するプロセッサコンフィギュレーションデータをＣＰ１５レジスタ３４にロードしなければならない。
ＣＰ１５レジスタ内のプロセッサコンフィギュレーションデータは一般にシステム内のメモリへのアクセスに対して即座に生じる影響を及ぼすので、これら設定がモニタモードで作動している間にプロセッサによって更新される際に、これら設定は即座に有効となることは明らかである。しかしながら、このことは望ましくないことである。その理由はモニタモード中のメモリへのアクセスを制御するプロセッサコンフィギュレーションデータのスタティックなセットをモニタモードが有することが望ましいからである。
従って、図３５に示されるように、本発明の一実施例では、プロセッサがモニタモードで作動している間にＣＰ１５レジスタ３４内のプロセッサコンフィギュレーションデータを無効にするのに使用できるモニタモード固有のプロセッサコンフィギュレーションデータ２０００が提供されている。図３５に示された実施例では、このことはマルチプレクサ２０１０を設けることによって達成される。このマルチプレクサ２０１０はその入力端でＣＰ１５レジスタに記憶されたプロセッサコンフィギュレーションデータとモニタモード固有のプロセッサコンフィギュレーションデータ２０００との双方を受信する。更にマルチプレクサ２０１０はプロセッサが現在モニタモードで作動しているのかどうかを表示する制御信号をパス２０１５を通して受信する。プロセッサがモニタモードで作動していない場合、システムにはＣＰ１５レジスタ３４内のプロセッサコンフィギュレーションデータが出力されるが、プロセッサがモニタモードで作動している場合には代わりにマルチプレクサ２０１０はモニタモード固有のプロセッサコンフィギュレーションデータ２０００を出力し、プロセッサがモニタモードで作動している間にプロセッサコンフィギュレーションデータの一貫したセットを適用することを保証する。
モニタモード固有のプロセッサコンフィギュレーションデータはシステム内でハードコピーでき、このデータを操作できないように保証できる。しかしながら、安全な特権モードで作動中にモニタモード固有のプロセッサコンフィギュレーションデータをプロセッサによってしか改変できないことを条件に、セキュリティを妥協することなく、モニタモード固有のプロセッサコンフィギュレーションデータ２０００をプログラマブルにすることが可能である。このことは、モニタモード固有のプロセッサコンフィギュレーションデータの設定に関するある程度のフレキシビリティを認めるものである。モニタモード固有のプロセッサコンフィギュレーションデータがプログラマブルであるようになっている場合、そのコンフィギュレーションデータをシステム内、例えばＣＰ１５レジスタ３４内の別個のセットのレジスタ内の適当な場所に記憶できる。
一般にモニタモード固有のプロセッサコンフィギュレーションデータはモニタモードでプロセッサを作動させるための極めて安全な環境を提供するように設定される。従って、上記実施例ではモニタモード固有のプロセッサコンフィギュレーションデータはプロセッサがモニタモードで作動している間、メモリ管理ユニット３０をディスエーブルするように指定でき、よってそうしなければメモリ管理ユニットによって適用され得る仮想−物理アドレス変換をディスエーブルする。かかる状況ではプロセッサは常に、メモリアクセスリクエストを発生するとき、例えばフラットマッピングを使用するときに直接物理アドレスを発生するようになる。このことは、仮想−物理アドレスマッピングに対して不正操作がなされたかどうかに拘わらず、モニタモードで作動中にプロセッサは信頼できる状態でメモリにアクセスできることを保証するものである。
モニタモード固有のプロセッサコンフィギュレーションデータはプロセッサがモニタモードで作動中にプロセッサが安全データにアクセスすることを認めることも一般に指定する。このことはドメインステータスビットの形態をとるメモリ許可データによって指定することが好ましい。このドメインステータスビットは安全プロセッサコンフィギュレーションデータ内の対応するドメインステータスビット（Ｓビット）に対して指定される同じ値を有する。従って、ＣＰ１５レジスタ内に記憶されるドメインステータスビットの実際の値に拘わらず、その値はモニタモードが安全データにアクセスすることを保証するよう、モニタモード固有のプロセッサコンフィギュレーションデータによって指定されるドメインステータスビットによって無効状態となる。
モニタモード固有のプロセッサコンフィギュレーションデータはメモリの一部へのアクセスを制御するのに使用される別のデータも指定できる。例えばモニタモード固有のプロセッサコンフィギュレーションデータはプロセッサがモニタモードで作動している間、データにアクセスするのにキャッシュ３８を使用すべきでないことを指定できる。
上記実施例では、プロセッサコンフィギュレーションデータを含むＣＰ１５レジスタのすべてがドメイン間で共用されると仮定している。しかしながら別の実施例では、例えばプロセッサコンフィギュレーションデータの特定のアイテムを記憶するために２つのレジスタが設けられるよう、多数のＣＰ１５レジスタがバンク状となる。すなわち、一方のレジスタには非安全ドメイン内でアクセスでき、このレジスタは非安全ドメインのためのプロセッサコンフィギュレーションデータのそのアイテムの値を含み、他方のレジスタには安全ドメイン内でアクセスでき、このレジスタは安全ドメインのためのプロセッサコンフィギュレーションデータのそのアイテムの値を含む。
バンク状とされないＣＰ１５レジスタはＳビットを含むレジスタであるが、基本的には他のＣＰ１５レジスタのいずれも、所望すればバンク状とすることができる。かかる実施例では、モニタモードによるプロセッサコンフィギュレーションの切り換えは共用されているレジスタ内にそのときにあるプロセッサコンフィギュレーションデータを、共用されているＣＰ１５レジスタからメモリに切り換え、共用されているＣＰ１５レジスタに宛て先ドメインに関係するプロセッサコンフィギュレーションデータをロードしなければならない。バンク状レジスタに対してはプロセッサコンフィギュレーションデータをメモリに記憶させる必要はなく、その代わり、対応する共用ＣＰ１５レジスタ内に記憶されているＳビットの値を変える結果として自動的に切り換えが行われる。
前に述べたように、モニタモード固有のプロセッサコンフィギュレーションデータは対応するＣＰ１５レジスタ内に記憶されているビットを無効にし、安全ドメインで使用されたドメインステータスビットに対して使用されたビットと同じ値（すなわち上記実施例では１のＳビット値）を有するドメインステータスビットを含む。多数のＣＰ１５レジスタがバンク状となっている場合、このことは図１５内のモニタモード固有のプロセッサコンフィギュレーションデータ２００の少なくとも一部をバンク状レジスタ内に記憶された安全プロセッサコンフィギュレーションデータから誘導できることを意味する。その理由は、レジスタのコンテンツは切り換えプロセッサ中にメモリに書き込まれることはないからである。
従って、一例としてモニタモード固有のプロセッサコンフィギュレーションデータはモニタモードでないときに使用したステータスビットを無効にするよう、ドメインステータスビットを指定し、好ましい実施例では、このステータスビットは安全ドメインで使用されたビットと同じ値を有するので、このことはバンク状ＣＰ１５レジスタのどれにアクセスできるようにするかを選択するロジックが安全バンク状ＣＰ１５レジスタへアクセスできるようにすることを意味する。モニタモード固有のプロセッサコンフィギュレーションデータの対応する部分として、モニタモードがこの安全プロセッサコンフィギュレーションデータを使用できるようにすることにより、ソースの節約を実行できる。その理由は、モニタモード固有のプロセッサコンフィギュレーションデータのアイテムに対してレジスタの別個のセットを設ける必要がなくなるからである。
図３６は、１つのドメインと別のドメインとの間の切り換えが必要なときにプロセッサコンフィギュレーションを切り換えるのに実行されるステップを示すフローチャートである。前に述べたようにドメイン間の切り換えを起こすためにＳＭＩ命令が発せられる。従って、ステップ２０２においてＳＭＩ命令の発生が待たれる。ＳＭＩ命令が受信されると、プロセッサはステップ２０３０へ進み、プロセッサはモニタモードでのモニタプログラムの実行を開始する。このことはマルチプレクサ２０１０へパス２０１５上の制御信号が入力される結果、モニタプログラム固有のプロセッサコンフィギュレーションデータが使用され、マルチプレクサがそのモニタモード固有のプロセッサコンフィギュレーションデータを切り換える。前に述べたように、これはデータの内蔵されたセットでもよいし、またはそのデータの所定の部分をバンク状レジスタ内に記憶された安全プロセッサコンフィギュレーションデータから誘導してもよい。
その後、ステップ２０４０においてドメインから現在のステートがセーブされ、ＳＭＩ命令をメモリに発生する。このことは、そのドメインに対応するプロセッサコンフィギュレーションデータのステートを共用されているＣＰ１５レジスタからセーブすることを含む。一般にかかるステートの記憶をするためのメモリセットの一部が設けられる。次にステップ２０５０にて、宛て先ドメインのための対応するステートを含むメモリ部分をポイントするように、ステートポインタが切り換えられる。従って、一般にステート情報を記憶するためにメモリの２つの部分が割り当てられる。１つの部分は非安全ドメインのためのステートを記憶するために割り当てられ、他方は、安全ドメインのためのステートを記憶するために割り当てられるものである。
ステップ２０５０において、ステートポインタが一旦割り当てられると、ステートポインタによってそのときポイントされているステートがステップ２０６０にて対応する共用ＣＰ１５レジスタにロードされる。このロードは宛て先ドメインのためのコンフィギュレーションデータを対応するプロセッサにロードすることを含む。その後、ステップ２０７０にてモニタモードと同じようにモニタプログラムから出て、プロセッサは宛て先ドメイン内の必要なモードに切り換わる。
図３７は本発明の一実施例のメモリ管理ロジック３０の作動をより詳細に示す。メモリ管理ロジックはメモリ管理ユニット（ＭＭＵ）２００と、メモリ保護ユニット（ＭＰＵ）２２０とから成る。仮想アドレスを指定するコア１０によって発生されるメモリアクセスのリクエストはパス２３４を通してＭＭＵ２００へ送られる。ＭＭＵ２００は所定のアクセス制御機能、より詳細には仮想アドレスに対応する物理アドレスを決定するための役割およびアクセス許可権利を決定し、領域属性を決定する役割を果たす。
データ処理装置のメモリシステムは安全メモリと、非安全メモリとから成り、安全メモリはそのコアまたは他のデバイスが安全作動モードで作動中、従って安全ドメイン内で作動中に、コア１０または１つ以上のその他のマスターデバイスにしかアクセスできないようになっている安全データを記憶するのに使用される。
図３７に示される本発明の一実施例では、コア１０上で非安全モードで作動するアプリケーションによる安全メモリ内の安全データへのアクセスの試みのポリシングをＭＰＵ２２０内のパーティションチェッカー２２２によって実行する。ＭＰＵ２２０は安全オペレーティングシステムによって管理され、本明細書では安全カーネルとも称す。
本発明の好ましい実施例によれば非安全メモリ内、例えば外部メモリ５６の非安全メモリ部分内には非安全ページテーブル５８が設けられ、そのページテーブル内に定められた多数の非安全メモリ領域の各々のための対応するデスクリプタを記憶するのに使用される。このデスクリプタは情報を含み、この情報からＭＭＵ２００が所定のアクセス制御機能を実行できるようにするのに必要なアクセス制御情報をＭＭＵが誘導でき、従って図３７を参照して説明した実施例では、このデスクリプタは仮想−物理アドレスマッピング、アクセス許可権利および領域属性に関する情報を提供する。
更に本発明の好ましい実施例によれば、メモリシステムの安全メモリ内、例えば外部メモリ５６の安全部分内には、少なくとも１つの安全ページテーブル５８が設けられ、再びこのページテーブルはテーブル内に定められた多数のメモリ領域のための関連するデスクリプタを提供する。プロセッサが非安全モードで作動しているときには、メモリアクセスを管理する際に使用するための適当なデスクリプタを得るために非安全ページテーブルが参照されるが、プロセッサが安全モードで作動しているときは安全ページテーブルからのデスクリプタが使用される。
適当なページテーブルからＭＭＵへのデスクリプタの検索は次のように進む。コア１０が発生したメモリアクセスリクエストが仮想アドレスを指定した場合、多数の仮想アドレス部分の１つに対し、適当なページテーブルから得られた対応する物理アドレス部分を記憶するマイクロＴＬＢ２０６内でルックアップが実行される。従って、マイクロＴＬＢ２０６は仮想アドレスの所定部分とマイクロＴＬＢ内に記憶された対応する仮想アドレス部分とを比較し、一致しているかどうかを判断する。比較された部分は一般に仮想アドレスの最大位ビットの所定の数となる。このビット数はページテーブル５８内の粒度（ｇｒａｎａｌａｒｉｔｙ）に応じてきまる。マイクロＴＬＢ２０６は比較的少数のエントリー、例えば８個のエントリーしか含まないので、マイクロＴＬＢ２０６内で実行されるルックアップは一般に比較的迅速である。
マイクロＴＬＢ２０６内で一致が見いだされなかった場合、メモリアクセスリクエストはパス２４２を通してメインＴＬＢ２０８へ送られる。このＴＬＢ２０８はページテーブルから得られた多数のデスクリプタを含む。後により詳細に説明するように、非安全ページテーブルと安全ページテーブルの双方からのデスクリプタがメインＴＬＢ２０８内に共存でき、メインＴＬＢ内の各エントリーは対応するフラグ（本明細書ではドメインフラグと称する）を有する。このフラグはそのエントリー内の対応するデスクリプタが安全ページテーブルから得られたものであるか、または非安全ページテーブルから得られたものであるかを表示するように設定可能である。すべての安全作動モードがメモリアクセスリクエスト内の物理アドレスを直接指定する実施例では、メインＴＬＢは非安全デスクリプタしか記憶しないので、メインＴＬＢ内にかかるフラグは不要であることが理解できよう。
メインＴＬＢ２０８内ではメモリアクセスリクエスト内で発行された仮想アドレスの対応する部分が特定の作動モードに対応するメインＴＬＢ２０８内のデスクリプタに関連する仮想アドレス部分のいずれかに対応するかどうかを判断するために、同様なルックアッププロセスが実行される。従って、コア１０が非安全モードで作動している場合、非安全ページテーブルから得られたメインＴＬＢ２０８内のデスクリプタしかチェックしないが、他方、コア１０が安全モードで作動している場合、安全ページテーブルから得られたメインＴＬＢ内のデスクリプタしかチェックしない。
チェックプロセスの結果としてメインＴＬＢ内で一致があった場合、対応するデスクリプタからアクセス制御情報を抽出し、これをパス２４２を通して送り戻す。特にデスクリプタの仮想アドレス部分および対応する物理アドレス物理をパス２４２を通してマイクロＴＬＢ２０６へ送り、このマイクロＴＬＢ内のエントリー内に記憶する。アクセス許可ロジック２０２へはアクセス許可権利がロードされ、領域属性ロジック２０４内には領域属性がロードされる。マイクロＴＬＢに対してアクセス許可ロジック２０２と領域属性ロジック２０４とは別個にしてもよいし、またはマイクロＴＬＢ内に組み込んでもよい。
このポイントでは、マイクロＴＬＢ２０６内には一致があるので、ＭＭＵ２００はメモリアクセスリクエストを処理できる。従って、マイクロＴＬＢ２０６は物理アドレスを発生し、この物理アドレスはパス２３８を通して対応するメモリへルーティングするためのシステムバス４０へ出力できる。ルーティング先のメモリはオンチップメモリ、例えばＴＣＭ３６、キャッシュ３８など、または外部バスインターフェース４２を介してアクセスできる外部メモリユニットの１つである。同時に、アクセス許可ロジック２０２はメモリアクセスを認めるかどうかを判断し、現在の作動モードで、指定されたメモリロケーションへコアがアクセスすることを許可しないと判断した場合、バス２３０を通してコア１０へアボート信号を発生する。例えばコアがスーパーバイザーモードで作動しているときに、安全メモリ内、または非安全メモリ内のいずれかにあるメモリの所定の部分をコアによってしかアクセスできないものとして指定することができ、従って、例えばユーザーモードにあるときにコア１０がかかるメモリロケーションへのアクセスを求めた場合、コア１０がそのときに適当なアクセス権を有していないことをアクセス許可ロジック２０２が検出し、パス２３０を通してアボート信号を発生する。このことはメモリアクセスをアボートさせる。最終的に、領域属性ロジック２０４は特定のメモリアクセスのための領域属性、例えばアクセスがキャッシュ可能であるか、バッファ可能であるかを判断し、パス２３２を通してかかる信号を発生し、ここでかかる信号はメモリアクセスリクエストの対象であるデータを、例えばキャッシュ３８内でキャッシュできるかどうか、書き込みアクセスの場合、書き込みデータをバッファ化できるかどうかを判断するのに使用される。
メインＴＬＢ２０８内で一致がなかった場合、対応するページテーブル５８にアクセスするのに変換テーブルウォークロジック２１０が使用され、パス２４８を通して、必要とされるデスクリプタを検索し、次にパス２４６を通してメインＴＬＢ２０８へそのデスクリプタを送り、このメインＴＬＢへ記憶する。非安全ページテーブルおよび安全ページテーブルの双方のためのベースアドレスはＣＰ１５ ３４のレジスタ内に記憶され、プロセッサコアが作動しているそのときのドメイン、すなわち安全ドメインまたは非安全ドメインもＣＰ１５のレジスタ内でセットされ、そのドメインのステータスレジスタは非安全ドメインと安全ドメインとの間の切り換えが行われるときにモニタモードでセットされる。本明細書では、ドメインステータスレジスタのコンテンツをドメインビットと称す。従って、変換テーブルウォークプロセスを実行しなければならない場合、変換テーブルウォークロジック２１０はどのドメインでコア１０が作動しているか、従って、対抗するテーブルにアクセスするのにどのベースアドレスを使用するかについて知る。次に、仮想アドレスは適当なページテーブル内の適当なエントリーにアクセスし、必要なデスクリプタを得るためのベースアドレスに対するオフセットとして使用される。
デスクリプタが変換テーブルウォークロジック２１０によって検索され、そのデスクリプタがメインＴＬＢ２０８に入れられると、メインＴＬＢ内で一致が得られ、アクセス制御情報を検索し、これをマイクロＴＬＢ２０６、アクセス許可ロジック２０２および論理属性ロジック２０４内に記憶するのに、前に説明したプロセスが呼び出される。次に、ＭＭＵ２００によりメモリアクセスを作動させることができる。
先に述べたように、好ましい実施例ではメインＴＬＢ２０８は安全ページテーブルおよび非安全ページテーブルの双方からのデスクリプタを記憶できるが、一旦マイクロＴＬＢ２０６内に適当な情報が記憶されると、メモリアクセスリクエストはＭＭＵ２００によってしか処理されない。好ましい実施例では、メインＴＬＢ２０８とマイクロＴＬＢ２０６との間の情報の転送はＭＰＵ２２０内に設けられたパーティションチェッカー２２２によってモニタされ、コア１０が非安全モードで作動中にメインＴＬＢ２０８内のデスクリプタからのアクセス制御情報がマイクロＴＬＢ２０６内に転送された場合、安全メモリ内にある物理アドレスを発生させる場合にこのようなアクセス制御情報はマイクロＴＬＢ２０６へ転送されない。
安全メモリと非安全メモリとの間の区分を定義するパーティション情報をＣＰ１５ ３４のレジスタ内にセットできるメモリ保護ユニットが安全オペレーティングシステムにより管理される。次に、パーティションチェッカー２２２はこのパーティション情報を参照し、非安全モードにあるコア１０による安全メモリへのアクセスを認めるマイクロＴＬＢ２０６へのアクセス制御情報を転送するかどうかを判断することができる。より詳細には、好ましい実施例ではコア１０がＣＰ１５ドメインステータスレジスタ内のモニタモードによって設定されるドメインビットにより表示されるように、コア１０が非安全作動モードで作動しているときには、パーティションチェッカー２２２はメインＴＬＢ２０８からマイクロＴＬＢ２０６へ検索しようとする物理アドレス部分をパス２４４を介してモニタし、かつ物理アドレス部分に基づき、仮想アドレスに対して発生される物理アドレスが安全メモリ内にあるかどうかを判断するようになっている。かかる状況では、パーティションチェッカー２２２はパス２３０を通してコア１０へアボート信号を発生し、メモリアクセスが生じるのを防止する。
更にパーティションチェッカー２２２は実際に物理アドレス部分がマイクロＴＬＢ２０６に記憶されるのを防止するようにでき、またはこれとは異なり、物理アドレス部分をマイクロＴＬＢ２０６に記憶してもよいことが理解できよう。しかしながら、アボートプロセスの一部は、例えばマイクロＴＬＢ２０６をフラッシュすることによりマイクロＴＬＢ２０６からその不正確な物理アドレス部分を除くことである。
コア１０がモニタモードを介し、非安全作動モードと安全作動モードとの間で切り換わるときはいつも、モニタモードはＣＰ１５ドメインステータスレジスタ内のドメインビットの値を変更し、プロセッサの作動が変化しているドメインを表示する。ドメイン間での転送プロセスの一部として、マイクロＴＬＢ２０６をフラッシュし、従って安全ドメインと非安全ドメインとの切り換えに従う第１メモリアクセスはマイクロＴＬＢ２０６内に不一致を発生し、メインＴＬＢ２０８から直接、または適当なページテーブルからの適当なデスクリプタを検索することにより、検索すべきアクセス情報を必要とする。
コアが非安全ドメインで作動中に安全メモリへのアクセスを可能にするアクセス制御情報をマイクロＴＬＢ２０６で検索しようとする試みがなされる場合、メモリアクセスのアボートを発生することをチェッカー２２２が保証することを、上記アプローチにより理解できよう。
プロセッサコア１０が任意の作動モードにあるとき、メモリアクセスリクエストが直接物理アドレスを指定するようになっている場合、その作動モードにおいてＭＭＵ２００がディスエーブルされ、物理アドレスがパス２３６を通してＭＰＵ２２０へ送られる。安全作動モードではアクセス許可ロジック２２４および領域属性ロジック２２６はＣＰ１５ ３４内のパーティション情報レジスタ内の対応する領域に対して識別された領域属性およびアクセス許可権利に基づき、必要なアクセスの許可および領域属性分析を実行する。アクセスされる安全メモリロケーションが所定作動モード、例えば安全特権モードでしかアクセスできない安全メモリの一部内にある場合、別の作動モード、例えば安全ユーザーモードになっているコアによるアクセスの試みは、かかる状況においてＭＭＵのアクセス許可ロジック２０２がアボートを発生したのと同じように、アクセス許可ロジック２２４にパス２３０を通してコアにアボートを発生させる。同様に、領域属性ロジック２２６はＭＭＵの領域属性ロジック２０４が仮想アドレスにより指定されたメモリアクセスリクエストに対して信号を発生したのと同じように、キャッシュ可能で、かつバッファ可能な信号を発生する。アクセスが許可されたと仮定した場合、アクセスリクエストがパス２４０を通してシステムバス４０まで進み、このバスから適当なメモリユニットへルーティングされる。
アクセスリクエストが物理アドレスを指定する非安全アクセスを行うために、パス２３６を介し、パーティションチェッカー２２２へアクセスがルーティングされ、パーティションチェッカー２２２はＣＰ１５レジスタ３４内のパーティション情報を参照し、パーティションのチェックを実行し、物理アドレスが安全メモリ内のロケーションを指定したかどうかを判断し、指定したと判断した場合、再びパス２３０を通してアボート信号が発生される。
次に図３９および４０のフローチャートを参照し、メモリ管理ロジックの上記処理について説明する。図３９はコア１０で作動しているプログラムがステップ３００によって表示されるように、仮想アドレスを発生する状況を示す。モニタモードによってセットされるＣＰ１５ドメインステータスレジスタ３４内の適当なドメインビットは、コアが安全ドメイン内で現在作動中であるか、非安全ドメイン内で作動中であるかを表示する。コアが安全ドメイン内で作動している場合、プロセスはステップ３０２へ分岐し、ここで仮想アドレスの対応する部分とマイクロＴＬＢ内の仮想アドレス部分の１つとが一致するかどうかを見るために、マイクロＴＬＢ２０６内でルックアップが実行される。ステップ３０２で一致した場合、プロセスはステップ３１２へ直接分岐し、ここでアクセス許可ロジック２０２は必要なアクセス許可分析を実行する。ステップ３１４において、アクセス許可違反があったかどうかが判断され、違反があった場合、プロセスはステップ３１６に進み、ここでアクセス許可ロジック２０２はパス２３０を通してアボートを発生する。違反がなければ、すなわちかかるアクセス許可違反がない場合、プロセスはステップ３１４からステップ３１８へ進み、ここでメモリアクセスが進む。特に領域属性ロジック２０４はパス２３２を通して必要なキャッシュ可能、かつバッファ可能な属性を出力し、マイクロＴＬＢ２０６は前に説明したようにパス２３８を通して物理アドレスを発生する。
ステップ３０２において、マイクロＴＬＢ内で一致がある場合、ステップ３０４にてメインＴＬＢ２０８内でルックアッププロセスが実行され、メインＴＬＢ内に必要な安全デスクリプタが存在するかどうかを判断する。存在しない場合、ステップ３０６でページテーブルウォークプロセスが実行され、変換テーブルウォークロジック２１０は図３７を参照して前に説明したように、安全ページテーブルから必要なデスクリプタを入手する。次にプロセスがステップ３０８へ進むか、またはメインＴＬＢ２０８内に既に安全デスクリプタがある場合、ステップ３０４からステップ２０８へ直接進む。
ステップ３０８において、メインＴＬＢが有効なタブの付いた安全デスクリプタを含むと判断され、従ってプロセスはステップ３１０まで進み、ここでマイクロＴＬＢに物理アドレス部分を含むデスクリプタのサブ部分がロードされる。コア１０はそのときに安全モードで作動中であるので、パーティションチェック機能を実行するのにパーティションチェッカー２２２は必要とされない。
次にプロセスはステップ３１２に進み、ここで残りのメモリアクセスが上記のように進行する。
非安全メモリアクセスの場合、プロセスはステップ３００から３２０へ進み、ここで非安全デスクリプタからの対応する物理アドレス部分が存在するかどうかを判断するためのルックアッププロセスがマイクロＴＬＢ２０６で実行される。存在する場合、プロセスは直接ステップ３３６に分岐し、ここでアクセス許可ロジック２０２によりアクセス許可権がチェックされる。このポイントでは、適当な物理アドレス部分がマイクロＴＬＢ内に存在する場合、パーティションチェッカー２２２はマイクロＴＬＢ内に情報が記憶される前にこの情報を有効に規制するので、セキュリティ違反がないと見なし、よってマイクロＴＬＢ内にこの情報がある場合、適当な非安全情報であると判断することに注目することが重要である。ステップ３３６にて、アクセス許可がチェックされた場合、プロセスはステップ３３８に進み、ここで違反があるかどうかが判断され、違反がある場合、ステップ３１６でアクセス許可フォールト（ｆａｕｌｔ）アボートが発生される。違反がない場合、プロセスはステップ３１８に進み、上記のように残りのメモリアクセスが実行される。
ステップ３２０において、マイクロＴＬＢ内に一致が発見されない場合、プロセスはステップ３２２に進み、ここで対抗する非安全デスクリプタが存在するかどうかを判断するためのルックアッププロセスがメインＴＬＢ２０８内で実行される。デスクリプタが存在しない場合、変換テーブルウォークロジック２１０によりステップ３２４でページテーブルウォークプロセスが実行され、非安全ページテーブルからの必要な非安全デスクリプタをメインＴＬＢ２０８へ検索する。次にプロセスはステップ３２６に進むか、またはステップ３２２内でメインＴＬＢ２０８内の一致が生じた場合にはステップ３２２から直接ステップ３２６へ進む。ステップ３２６ではメインＴＬＢが当該仮想アドレスに対する有効なタグ付き非安全デスクリプタを含むと判断され、ステップ３２８においてパーティションチェッカー２２２は（デスクリプタ内の物理アドレス部分を仮定した場合）メモリアクセスリクエストの仮想アドレスから発生される物理アドレスが非安全メモリ内のロケーションをポイントしていることをチェックする。ポイントしていない場合、すなわち物理アドレスが安全メモリ内のロケーションをポイントしている場合、ステップ３３０にてセキュリティの違反があると判断され、プロセスはステップ３３２に進み、ここでパーティションチェッカー２２２により安全／非安全フォールトアボートが発生される。
しかしながら、パーティションチェッカーロジック２２２がセキュリティの違反がないと判断した場合、プロセスはステップ３３４へ進み、ここで物理アドレス部分を含む対応するデスクリプタのサブ部分がマイクロＴＬＢにロードされ、その後、ステップ３３６で前に説明したようにメモリアクセスが処理される。
次に、図４０を参照し、物理アドレスを直接発生するメモリアクセスリクエストの取り扱いについて説明する。上記のように、このシナリオではＭＭＵ２００は使用が止められる。このことは、ＣＰ１５レジスタの適当なレジスタ内の設定、例えばＭＭＵのイネーブルビットによって達成することが好ましく、この設定プロセスはモニタモードで実行される。従って、ステップ３５０にてコア１０は物理アドレスを発生し、この物理アドレスはパス２３６を通してＭＰＵ２２０へ送られる。次にステップ３５２において、ＭＰＵはリクエストされているメモリアクセスが所与の現在の作動モード、例えばユーザー、スーパーバイザーなどを進めることができることを証明するための許可をチェックする。更にコアは非安全モードで作動している場合、パーティションチェッカー２２２はステップ３５２にて非安全メモリ内に物理アドレスが存在するかどうかもチェックする。次にステップ３５４にて、違反があるかどうか、例えばアクセス許可処理が違反を明らかにしたか、すなわち非安全モードにおいてパーティションチェックプロセスが違反を識別したかどうかが判断される。これら違反のいずれかが生じた場合、プロセスはステップ３５６に進み、ここでＭＰＵ２２０によりアクセス許可フォールトアボートが発生される。所定の実施例では、２つのタイプのアボートには区別がないが、別の実施例ではアボート信号はこの信号がアクセス許可フォールトに関係するものであるのか、またはセキュリティフォールトに関係するものであるかどうかを表示できる。
ステップ３５４にて、違反が検出されない場合、プロセスはステップ３５８に進み、ここで物理アドレスによって識別されたロケーションへのメモリアクセスが行われる。
好ましい実施例では、モニタモードでしか物理アドレスを直接発生しないようになっているので、他のすべてのケースではＭＭＵ２００がアクティブとされ、上記のようにメモリアクセスリクエストの仮想アドレスから物理アドレスが発生される。
図３８はすべてのメモリアクセスリクエストが仮想アドレスを指定し、従って、いずれも作動モードでも直接物理アドレスが発生されない状況にあるメモリ管理ロジックの別の実施例を示す。このシナリオでは、別個のＭＰＵ２２０は必要ではなく、その代わりにＭＭＵ２００内にパーティションチェッカー２２２を組み込んでもよいと理解できよう。この変化を別にすれば、図３７および３９を参照して前に説明したのと全く同じように処理が進む。
その他の種々のオプションも可能であることが理解できよう。例えば仮想アドレスを指定する安全モードおよび非安全モードの双方でメモリアクセスリクエストを発生できると仮定すれば、２つのＭＭＵを設けることができる。１つは安全アクセスリクエスト用のものであり、１つは非安全アクセスリクエスト用のものである。すなわち図３７のＭＰＵ２２０は完全なＭＭＵに置換できる。これらケースでは、一方のＭＭＵがそのメインＴＬＢに非安全デスクリプタを記憶し、他方のＭＭＵがメインＴＬＢ内に安全デスクリプタを記憶するので、デスクリプタが安全または非安全のいずれであるかを定めるための各ＭＭＵのメインＴＬＢと共にフラグを使用する必要はない。当然ながら、コアが非安全ドメイン内にある間に安全メモリへのアクセスが試みられているかどうかをチェックするためのパーティションチェッカーがまだ必要である。
これとは異なり、すべてのメモリアクセスが直接指定された物理アドレスをリクエストする場合、別の実行例は２つのＭＰＵ（１つは安全アクセスリクエスト用であり、１つは非安全アクセスリクエスト用である）を使用すべきである。非安全アクセスリクエスト用に使用されるＭＰＵは安全メモリへのアクセスが非安全モードでは認められないことを保証するよう、パーティションチェッカーによって規制されるアクセスリクエストを有する。
図３７または図３８の構造のいずれかを設けることができる別の特徴として、変換テーブルウォークロジック２１０のアクティビティを規制するために、一部のパーティションチェッカー２２２が一部のパーティションチェックを実行するようにできる。特にコアがそのときに非安全ドメイン内で作動中の場合、変換テーブルウォークロジック２１０がページテーブルへのアクセスを求めていること、すなわち安全ページテーブルではなく、非安全ページテーブルにアクセスしていることをパーティションチェッカー２２２がチェックするようにできる。違反が検出された場合、アボート信号を発生することが好ましい。変換テーブルウォークロジック２１０はページテーブルベースアドレスとメモリアクセスリクエストが発生する仮想アドレスの所定のビットとを組み合わせることにより、ページテーブルルックアップを一般に実行するので、このパーティションチェックは例えば変換テーブルウォークロジック２１０が安全ページテーブルのベースアドレスではなく非安全ページテーブルのベースアドレスを使用していることをチェックできる。
図４１はコア１０が非安全モードで作動中にパーティションチェッカー２２２によって実行されるプロセスを略図で示す。正常に動作しているときは、非安全ページテーブルから得られるデスクリプタは非安全メモリだけでマッピングされたページを記述する。しかしながら、ソフトウェアのアタックがあった場合にデスクリプタはメモリの非安全領域および安全領域の双方を含む部分を記述するように不正操作できる。従って、図４１内の例を検討すると、不正操作された非安全デスクリプタは非安全領域３７０、３７２、３７４および安全領域３７６、３７８、３８０を含むページをカバーし得る。メモリアクセスリクエストの一部として発生された仮想アドレスが安全メモリ領域、例えば図４１に示されるような安全メモリ領域３７６内の物理アドレスに対応する場合、パーティションチェッカー２２２はアクセスが生じないようにアボートを発生するようになっている。従って、安全メモリへアクセスしようとする試みで非安全デスクリプタが不正に操作された場合でも、パーティションチェッカー２２２はアクセスの発生を防止する。これと対照的に、このデスクリプタを使って誘導される物理アドレスが非安全メモリ領域、例えば図４１に示されるような領域３７４に対応する場合、マイクロＴＬＢ２０６にロードされるアクセス制御情報はこの非安全領域３７４を識別するだけである。従って、非安全メモリ領域３７４内のアクセスが生じ得るが、安全領域３７６、３７８または３８０のいずれかへのアクセスは生じることができない。従って、メインＴＬＢ２７８が不正操作された非安全ページテーブルからのデスクリプタを含むことがあっても、マイクロＴＬＢは非安全メモリ領域へのアクセスを可能にする物理アドレス部分しか含まないことが理解できよう。
上記のように、非安全モードおよび安全モードが仮想アドレスを指定するメモリアクセスリクエストを発生し得る実施例では、メモリは非安全メモリ内に非安全ページテーブルを含み、安全メモリ内に安全ページテーブルを含むことが好ましい。非安全モードでは、変換テーブルウォークロジック２１０によって非安全ページテーブルが参照され、他方、安全モードでは変換テーブルウォークロジック２１０によって安全ページテーブルが参照される。図４２はこれら２つのページテーブルを示す。図４２に示されるように、例えば図１の外部メモリ５６０内にあり得る非安全メモリ３９０は、ベースアドレス３９７を参照することによってＣＰ１５レジスタ３４内に指定された非安全ページテーブル３９５を内部に含む。同様に、図１の外部メモリ５６内に再びあり得る安全メモリ４００内には、安全ページテーブルベースアドレス４０７により二重ＣＰ１５レジスタ３４内で指定される対応する安全ページテーブル４０５が設けられる。非安全ページテーブル３９５内の各デスクリプタは非安全メモリ３９０内の対応する非安全ページをポイントし、他方、安全ページテーブル４０５内の各デスクリプタは安全メモリ４００内に対応する安全ページを定める。更により詳細に後述するように、メモリの所定領域を非安全モードと安全モードの双方によってアクセスできる共用メモリ領域４１０とすることができる。
図４３は好ましい実施例に従ってメインＴＬＢ２０８内で実行されるルックアッププロセスをより詳細に示す。上記のように、メインＴＬＢ２０８は対応するデスクリプタ４３５が安全ページテーブルからのものか、または非安全ページテーブルからのものかのいずれかを識別するドメインフラグ４２５を含む。このことは、ルックアッププロセスを実行しているときはコア１０が作動中の特定のドメインに対応するデスクリプタしかチェックしないことを保証している。図４３は、安全ワールドとも称す安全ドメイン内でコアが作動中の一例を示す。図４３から判るように、メインＴＬＢ２０８のルックアップが実行されるとき、この結果、デスクリプタ４４０が無視され、デスクリプタ４４５だけがルックアッププロセス用の候補として識別される。
好ましい実施例によれば、本明細書でＡＳＩＤフラグとも称す別のプロセスＩＤフラグ４３０がプロセス固有のページテーブルからのデスクリプタを識別するように設けられる。従って、プロセスＰ１、Ｐ２およびＰ３の各々はメモリ内に設けられた対応するページテーブルを有し、更に非安全動作および安全動作のための異なるページテーブルを有することができる。更に、安全ドメイン内のプロセスＰ１、Ｐ２、Ｐ３は非安全ドメイン内のプロセスＰ１、Ｐ２、Ｐ３に対して完全に別個のプロセスとすることができると理解できよう。従って、図４３に示されるように、メインＴＬＢルックアップ２０８が必要とされるときのドメインのチェックのほかに、ＡＳＩＤフラグもチェックする。
従って、安全ドメインにおいてプロセスＰ１が実行中の図４３内の例では、このルックアッププロセスはメインＴＬＢ２０８内の２つのエントリー４５０を識別し、これら２つのデスクリプタ内の仮想アドレス部分がメモリアクセスリクエストによって発生される仮想アドレスの対応する部分と一致するかどうかに応じて、一致または不一致信号を発生する。一致した場合、対応するアクセス制御情報が抽出され、マイクロＴＬＢ２０６、アクセス許可ロジック２０２および領域属性ロジック２０４へ送られる。一致しない場合、すなわち不一致が生じた場合、変換テーブルウォークロジック２１０を使用し、安全プロセスＰ１に対して提供されるページテーブルからの必要なデスクリプタをメインＴＬＢ２０８内に検索する。当業者であれば理解できるように、ＴＬＢのコンテンツを管理する技術は多数あるので、メインＴＬＢ２０８内に記憶するように、新しいデスクリプタが検索される。メインＴＬＢが既に満杯である場合、多数の公知の技術のうちの１つを使用して新しいデスクリプタ例えば少なくとも最近使用されたアプローチのための余裕を設けるために、どのデスクリプタをメインＴＬＢから退却させるかを判断することができる。
安全作動モードで使用される安全カーネルは非安全オペレーティングシステムに対して完全に別個に開発できると理解できよう。しかしながら、所定の場合では安全カーネルと非安全オペレーティングシステムの開発は密接にリンクしており、かかる状況では安全アプリケーションは非安全デスクリプタを使用できるようにすることが適当であり得る。実際にこれによって仮想アドレスを知るだけで、安全アプリケーションが（共用のために）非安全データに直接アクセスできるようになる。当然ながらこのことは、特定のＡＳＩＤに対して安全仮想マッピングと非安全仮想マッピングとが排他的であることを仮定するものである。かかるシナリオでは、安全デスクリプタと非安全デスクリプタとを区別するように、前に導入されたタグ（すなわちドメインフラグ）が不要となる。代わりに、利用できるすべてのデスクリプタによるＴＬＢ内のルックアップを実行する。
好ましい実施例では、メインＴＬＢのこのコンフィギュレーションと、別個の安全デスクリプタおよび非安全デスクリプタを有する前に説明したコンフィギュレーションとの選択を、ＣＰ１５制御レジスタ内で提供される特定のビットによって設定できる。好ましい実施例では、このビットは安全カーネルによってしかセットされない。
安全アプリケーションが直接非安全仮想アドレスを使用することが認められる実施例では、非安全スタックポインタが安全ドメインから利用できるようにすることが可能である。このことは、ＣＰ１５レジスタ３４内の専用レジスタ内に非安全スタックポインタを識別する非安全レジスタ値をコピーすることによって行うことができる。このことは、安全アプリケーションによって理解される方式に従い、スタックを介してパラメータを非安全アプリケーションが送ることを可能にする。
上記のように、メモリは非安全部分と安全部分とに分割でき、このような分割はパーティションチェッカー２２２専用のＣＰ１５レジスタ３４を使って安全カーネルによって制御される。このような基本的なパーティション（分割）方法は、代表的なＭＰＵデバイス内で定義できるような領域アクセス許可に基づくものである。従って、メモリは複数の領域に分割され、各領域はそのベースアドレス、サイズ、メモリ属性およびアクセス許可によって定義することが好ましい。更に、オーバーラップする領域にプログラムを組むときには、上部領域の属性が最も高いプライオリティを有する。更に、本発明の好ましい実施例によれば、対応する領域が安全メモリ内にあるのか、または非安全メモリ内にあるのかを定めるための新しい領域属性が提供される。この新しい領域属性は安全カーネルによって使用され、安全メモリとして保護すべきメモリ部分を定める。
ブート段階では、図４４に示されるように、最初の分割が実行される。この最初の分割は非安全ワールド、非安全オペレーティングシステムおよび非安全アプリケーションに割り当てられるメモリ４６０の量を決定する。この量はこの分割で定められる非安全領域に対応する。次にこの情報はメモリ管理のために非安全オペレーティングシステムで使用される。安全として定められるメモリ４６２、４６４の残りの部分は非安全オペレーティングシステムにとっては未知である。非安全ワールドにおける完全性を保護するために、非安全メモリには安全特権モードだけのアクセス許可のプログラムを組むことができる。従って、安全アプリケーションは非安全アプリケーションを不正に改変しない。図４４から判るように、このようなブート段階の分割の後で、メモリ４６０が非安全オペレーティングシステムによる使用のために利用できるようになり、メモリ４６２は安全カーネルによる使用に利用できるようになり、メモリ４６４は安全アプリケーションによる使用に利用できるようになる。
一旦ブート段階の分割を実行すると、非安全メモリ４６０のメモリマッピングはＭＭＵ２００を使用する非安全オペレーティングシステムによって処理されるので、通常のように一連の非安全ページを定めることができる。これについては図４５に示されている。
安全アプリケーションが非安全アプリケーションとメモリを共用しなければならない場合、安全カーネルはあるドメインから別のドメインへデータを人工的に転送するためのメモリの一部の権利を変更できる。従って、図４６に示されるように、安全カーネルは非安全ページの完全性をチェックした後に、共用メモリとしてアクセスできる安全ページ４６６となるように、非安全ページの権利を変えることができる。
メモリのパーティションを変更するときに、マイクロＴＬＢ２０６をフラッシングする必要がある。従って、このシナリオでは、その後、非安全アクセスが行われるときにマイクロＴＬＢ２０６で不一致が生じるので、メインＴＬＢ２０８から新しいデスクリプタをロードしなければならない。この新しいデスクリプタはマイクロＴＬＢ２０６への検索を試みているものとしてＭＰＵのパーティションチェッカー２２２によりその後チェックされ、よってメモリの新しいパーティションと一致する。
好ましい実施例では、キャッシュ３８は仮想インデックスされ、物理的なタグがつけられるので、キャッシュ３８内でアクセスを実行するときには最初にマイクロＴＬＢ２０６では既にルックアップが実行されている。従って、アクセス許可、特に安全許可および非安全許可はチェック済みである。従って、非安全アプリケーションによりキャッシュ３８にはデータを記憶できない。キャッシュ３８へのアクセスはパーティションチェッカー２２２により実行されるパーティションチェックの制御下にあるので、非安全モードでは安全データへのアクセスを実行できない。
しかしながら、生じ得る１つの問題は非安全ドメイン内のアプリケーションがキャッシュ動作レジスタを使用し、キャッシュを無効にし、クリーンにし、またはフラッシュできることである。かかる動作はシステムのセキュリティに影響しないように保証する必要がある。例えば非安全オペレーティングシステムがキャッシュ３８をクリーンにすることなく、キャッシュ３８を無効にした場合、置き換え前に外部メモリへ安全ダーティデータを書き込まなければならない。キャッシュ内では安全データにタグを付け、よってこのデータを所望する場合、異なるように取り扱うことができるようにすることが好ましい。
好ましい実施例では、「アドレスによるラインの無効化」動作が非安全プログラムによって実行される場合、物理アドレスはパーティションチェッカー２２２によりチェックされ、キャッシュラインが安全キャッシュラインである場合、動作は「クリーンおよび無効化」動作となり、システムのセキュリティを維持することを保証する。更に好ましい実施例では、非安全プログラムによって実行されるすべての「インデックスによるライン無効化」動作は「インデックスによるクリーンおよび無効化」動作となる。同様に、非安全プログラムによって実行されるすべての「すべてを無効化する」動作のいずれも、「すべてをクリーンにし、無効化する」動作となる。
更に図１を参照すると、ＤＭＡ３２によるＴＣＭ３６へのアクセスはマイクロＴＬＢ２０６によって制御される。従って、ＤＭＡ３２がＴＬＢ内のルックアップを実行し、その仮想アドレスを物理アドレスに変換するときに、メインＴＬＢで追加された、前に説明したフラグにより、ちょうどコア１０によってアクセスリクエストが発生されたかのように、必要とされるセキュリティチェックが実行される。更に後述するように、好ましくはアービタ／デコーダブロック５４内に設けることが好ましい外部バス７０へレプリカパーティションチェッカーが結合されるので、ＤＭＡ３２が外部バスインデックス４２を介し、外部バス７０に結合されたメモリに直接アクセスした場合、その外部バスに接続されたレプリカパーティションチェッカーがアクセスの有効性をチェックする。更に所定の好ましい実施例では、非安全ドメイン内でＤＭＡコントローラ３２が使用されるかどうかを定めるためのビットをＣＰ１５レジスタ３４に追加することができる。このビットは特権モードで作動している時にしか安全カーネルによってセットされない。
次に、ＴＣＭ３６を検討する。安全データがＴＣＭ３６に置かれる場合、このデータは注意して取り扱われなければならない。一例として、ＴＣＭメモリ３６に対する物理アドレスレンジが外部安全メモリ部分にオーバーラップするように、非安全オペレーティングシステムがＴＣＭメモリ３６に対する物理アドレスレンジをプログラムしているようなシナリオをイメージできる。次に、作動モードが安全モードに変化した場合、安全カーネルはデータをそのオーバーラップした部分に記憶させることができ、ＴＣＭ３６は外部メモリよりも高いプライオリティを有するので、一般にＴＣＭ３６にデータが記憶されることになる。前の安全領域からメモリの非安全物理領域にマッピングされるよう、非安全オペレーティングシステムがＴＣＭ３６に対する物理アドレススペースの設定を変えたとした場合、パーティションチェッカーはこのエリアを非安全エリアと見なし、アボートをアサートしないので、非安全オペレーティングシステムは安全データにアクセスできることが理解できよう。従って、要約すれば、ＴＣＭがスマートキャッシュとしてではなく、通常のローカルＲＡＭとして作動するように構成されている場合において、非安全オペレーティングシステムがＴＣＭベースレジスタを非安全物理アドレスまで移動できれば、非安全オペレーティングシステムは安全ワールドデータを読み出すことが可能である。
この種のシナリオを防止するために、好ましい実施例では、安全特権作動モードでしかアクセスできないＣＰ１５レジスタ３４内に制御ビットが設けられ、この制御ビットは２つの可能なコンフィギュレーションを提供する。第１のコンフィギュレーションでは、この制御ビットは「１」にセットされ、この場合、ＴＣＭは安全特権モードによってしか制御できない。従って、ＣＰ１５ ３４内のＴＣＭ制御レジスタに試みられる非安全アクセスは無定義命令例外を入力させる。従って、この第１コンフィギュレーションでは、安全モードと非安全モードの双方がＴＣＭを利用できるが、ＴＣＭは安全特権モードによってしか制御できない。第２コンフィギュレーションでは、制御ビットは「０」にセットされ、この場合、ＴＣＭは非安全オペレーティングシステムによって制御できる。この場合、ＴＣＭは非安全アプリケーションによってしか使用されない。安全データはＴＣＭに記憶することもＴＣＭからロードすることもできない。従って、安全アクセスを実行するときに、アドレスがＴＣＭアドレスレンジに一致しているかどうかを見るために、ＴＣＭ内ではルックアップは実行されない。
デフォルトにより非安全オペレーティングシステムを変える必要がないこのようなシナリオのように、ＴＣＭを非安全オペレーティングシステムによってしか使用できないように考えつくことができる。
上記のように、ＭＰＵ２２０内にパーティションチェッカー２２２を設けるほかに、本発明の好ましい実施例は、外部バス７０に結合された類似するパーティションチェックブロックも提供している。この追加パーティションチェッカーは他のマスターデバイス、例えばデジタル信号プロセッサ（ＤＳＰ）５０、外部バスに直接結合されたＤＭＡコントローラ５２、外部バスインターフェース４２を介して外部バスに接続できるＤＭＡコントローラ３２などにより、メモリへのアクセスを規制するのに使用される。実際に一部の実施例では、後述するように外部（またはデバイス）バスにパーティションチェックブロックを結合するだけでよく、メモリ管理ロジック３０の一部としてパーティションチェッカーを設ける必要はない。かかる一部の実施例では、メモリ管理ロジック３０の一部としてパーティションチェッカーをオプションで設けることができ、かかる場合、このパーティションチェッカーはデバイスバスに結合されたチェッカーのほかに設けられた別のパーティションチェッカーと見なされる。
上記のように、メモリシステム全体はいくつかのメモリユニットから構成でき、これら種々のメモリユニット、例えば外部メモリ５６、ブートＲＯＭ４４またはスクリーンドライバ４６、Ｉ／Ｏインターフェース６０、キー記憶ユニット６４などのような周辺デバイスに設けられたバッファまたはレジスタ４８、６２、６６が外部バス７０に存在し得る。例えばメモリシステムの異なる部分を安全メモリとして定義する必要がある。例えばキー記憶ユニット６４内のキーバッファ６６を安全メモリとして取り扱わなければならないことが望まれる。かかる安全メモリへのアクセスが外部バスに結合されているデバイスによって試みられる場合、コア１０を含むチップ内に設けられた、前に説明したメモリ管理ロジック３０は、かかるアクセスを規制できないことは明らかである。
図４７は、本明細書でデバイスバスとも称す外部バスに結合された別のパーティションチェッカー４９２をどのように使用するかを示す。デバイス、例えばデバイス４７０、４７２によって外部バスにメモリアクセスリクエストが発生されるときは常に、そのメモリアクセスリクエストが作動モード、例えば特権モード、ユーザーモードなどを定める所定の信号も外部バスに含むように、外部バスを一般に構成する。本発明の好ましい実施例によれば、メモリアクセスリクエストはデバイスが安全モードで作動しているのか、または非安全モードで作動しているのかを識別するためのドメイン信号を外部バスに発生することも含む。このドメイン信号はハードウェアレベルで発生することが好ましく、好ましい実施例では安全ドメインまたは非安全ドメインで作動できるデバイスは外部バス内のパス４９０にドメイン信号を出力するための所定のピンを含む。図解のために、外部バス上の別の信号パス４８８とは別に、このパス４９０が示されている。
本明細書で「Ｓビット」とも称すこのドメイン信号は、メモリアクセスリクエストを発生したデバイスが安全ドメインで作動中か、または非安全ドメインで作動中かを識別し、この情報は外部バスに結合されたパーティションチェッカー４９２によって受信される。このパーティションチェッカー４９２はメモリのどの領域が安全であるか、または非安全であるかを識別するパーティション情報にもアクセスするので、Ｓビットが安全作動モードを識別するようにアサートされている場合にしかデバイスがメモリの安全部分にアクセスできないようにすることができる。
デフォルトによりＳビットをアンアサートし、よって図４７に示されているデバイス４７２のような、あらかじめ存在する非安全デバイスがアサートされたＳビットを出力せず、従って、メモリの安全部分がレジスタまたはバッファ４８２、４８６内、スクリーンドライバ４８０、Ｉ／Ｏインターフェース４８４内、または外部メモリ４７４内にあるかどうかに応じ、メモリの安全部分へのパーティションチェッカー４９２によるアクセス権が付与されることはない。
説明の都合から、マスターデバイス、例えば４７０、４７２が発生するメモリアクセスリクエスト間の仲裁をするのに使用されるアービタブロック４７６は、メモリアクセスリクエストのサービスをするための適当なメモリデバイスを決定するのに使用されるデコーダ４７８に対して別々に示されており、パーティションチェッカー４９２と別個となっている。しかしながら、これら部品の１つ以上は所望すれば同じユニット内に組み込むこともできることが理解できよう。
図４８は、パーティションチェッカー４９２が設けられず、その代わりに各メモリデバイス４７４、４８０、４８４がＳビットの値に応じて自己のメモリアクセスを規制するようになっている別の実施例を示す。従って、デバイス４７０が安全メモリとしてマークされたスクリーンドライバ４８０内のレジスタ４８２に対して、非安全モードでメモリアクセスリクエストをアサートすると仮定した場合、スクリーンドライバ４８０はＳビットがアサートされていないと判断し、メモリアクセスリクエストを処理しない。従って、種々のメモリデバイスを適当に設計することにより、外部バスと別個にパーティションチェッカー４９２を設けなくてもよいようにできる。
図４７および４８の上記説明では、「Ｓビット」はメモリアクセスリクエストを発生したデバイスは安全ドメインで作動中か、非安全ドメインで作動中かを識別すると述べられている。別の観点から見た場合、このＳビットはメモリアクセスリクエストが安全ドメインに関するものであるか、または非安全ドメインに関するものであるかのいずれかを表示すると見ることができる。
図３７および３８を参照して説明した実施例では、ページテーブルの単一のセットと共に単一のＭＭＵを使用して、仮想−物理アドレス変換を実行した。かかるアプローチでは、物理アドレス空間は図４９に示されるように簡単な態様で、非安全メモリと安全メモリとに一般にセグメント化される。ここで、物理アドレス空間２１００はメモリシステム内のメモリユニットのうちの１つ、例えば外部メモリ５６に対し、アドレスゼロからスタートし、アドレスＹまで拡張するアドレス空間を含む。各メモリユニットに対し、アドレス指定可能なメモリは一般に２つの部分、すなわち非安全メモリとして割り当てられた第１部分２１１０と安全メモリとして割り当てられた第２部分２１２０とに区分される。
かかるアプローチには特定のドメインにアクセスできない所定の物理アドレスが存在し、これらギャップはそれらドメインで使用されるオペレーティングシステムに対して明らかとなることが理解できよう。安全ドメイン内で使用されるオペレーティングシステムは非安全ドメインの知識を有するので、非安全ドメインに関係しないが、非安全ドメイン内のオペレーティングシステムは理想的には安全ドメインが存在することの知識を有しなくてもよく、代わりに安全ドメインがなかったかのように作動すべきである。
別の問題として、非安全オペレーティングシステムはアドレスゼロでスタートし、アドレスＸまで拡張する外部メモリに対するアドレス空間をみて、非安全オペレーティングシステムは安全カーネルに関して、特にアドレスＸ＋１からアドレスＹまで延びる安全メモリの存在を全く知る必要はないことが理解できよう。これと対照的に、安全カーネルはオペレーティングシステムが一般に期待するアドレスではないアドレスゼロでスタートするアドレス空間を見ない。
図５１には物理アドレス空間の非安全オペレーティングシステムのビューから安全メモリ領域を完全に隠すことができるようにし、安全ドメイン内の安全カーネルおよび非安全ドメイン内の非安全オペレーティングシステムの双方が、アドレスゼロでスタートする外部メモリに対するアドレス空間を見ることができるようにすることによって、上記問題を解決する一実施例が略図で示されている。ここで、物理アドレス空間２２００はページレベルにて安全セグメントまたは非安全セグメントのいずれかにセグメント化できる。図５１に示された例では、外部メモリのためのアドレス空間は２つの安全メモリ領域と２つの非安全メモリ領域とから成る４つの部分２２１０、２２２０、２２３０および２２４０にセグメント化されているように示されている。
単一ページテーブル変換により仮想アドレス空間と物理アドレス空間との間の切り換えを行うかわりに、第１ページテーブルおよび第２ページテーブルを参照し、２つの別個の層のアドレス変換を実行し、よってプロセッサが安全ドメインにあるのか、または非安全ドメインにあるのかに応じて異なるように配置できる中間アドレス空間の概念を導入することができる。より詳細には、図５１に示されるように、ページテーブル２２５０の組内の安全ページテーブル内に設けられたデスクリプタを使用することにより、安全ドメインに対する中間アドレス空間内の１つの領域２２６５に対し、物理アドレス空間内の２つの安全メモリ領域２２１０および２２３０をマッピングできる。プロセッサで作動中のオペレーティングシステムに関し、中間アドレス空間を物理アドレス空間として満てＭＭＵを使って仮想アドレスを中間アドレス空間内の中間アドレスに変換する。
同様に、非安全ドメインに対して中間アドレス空間２２７０を構成でき、この空間ではページテーブル２２５０のセット内の非安全ページテーブル内の対応するデスクリプタにより、非安全ドメインに対する中間アドレス空間内の非安全領域２２７５に対して物理アドレス空間内の２つの非安全メモリ領域２２２０および２２４０をマッピングする。
一実施例では、図５０Ａに示されるような２つの別個のＭＭＵを使って中間アドレスを介した仮想アドレスから物理アドレスへの変換が取り扱われる。図５０Ａ内のＭＭＵ２１５０および２１７０の各々は、図３７に示されたＭＭＵ２００と同じように構成されていると見なすことができるが、図解を容易にするために図５０Ａでは所定の細部が省略されている。
第１ＭＭＵ２１５０はマイクロＴＬＢ２１５５、メインＴＬＢ２１６０および変換テーブルウォークロジック２１６５を含み、同様に第２ＭＭＵ２１７０はマイクロＴＬＢ２１７５、メインＴＬＢ２１８０および変換テーブルウォークロジック２１８５を含む。第１ＭＭＵはプロセッサが非安全ドメイン内で作動中は非安全オペレーティングシステムによって制御でき、プロセッサが安全ドメイン内で作動中は安全カーネルによって制御できる。しかしながら、好ましい実施例では、第２ＭＭＵは安全カーネルまたはモニタプログラムによってしか制御できない。
プロセッサコアがメモリアクセスリクエストを発生するとき、このコアはパス２１５３を通してマイクロＴＬＢ２１５５へ仮想アドレスを発生する。マイクロＴＬＢ２１５５はメインＴＬＢ２１６０内に記憶されたデスクリプタから検索された対応する中間アドレス部分を多数の仮想アドレス部分に対して記憶する。メインＴＬＢ２１６０内のデスクリプタは第１ＭＭＵ２１５０に関連したページテーブルの第１のセット内のページテーブルから検索したものである。マイクロＴＬＢ２１５５内で一致が検出された場合、マイクロＴＬＢ２１５５はパス２１５３を通して受信された仮想アドレスに対応する中間アドレスをパス２１５７を通して発生できる。マイクロＴＬＢ２１５５内に一致がない場合、メインＴＬＢ内で一致が検出されたかどうかを見るためにメインＴＬＢ２１６０が参照され、一致が検出された場合、対応する仮想アドレス部分および対応する中間アドレス部分がマイクロＴＬＢ２１５５に検索され、その後、パス２１５７を通して中間アドレスを発生できる。
マイクロＴＬＢ２１５５およびメインＴＬＢ２１６０内で一致がなかった場合、第１ＭＭＵ２１５０によってアクセスできるページテーブルの第１のセット内の所定のページテーブルからの必要なデスクリプタに関するリクエストを発生するのに、変換テーブルウォークロジック２１６５を使用する。一般に、安全ドメインまたは非安全ドメインの双方のための個々のプロセスに関連したページテーブルがあり、変換テーブルウォークロジック２１６５により、例えばＣＰ１５レジスタ３４内の適当なレジスタからこれらページテーブルに対する中間ベースアドレスにアクセスできる。従って、変換テーブルウォークロジック２１６５は適当なページテーブルからデスクリプタをリクエストするよう、パス２１６７を通して中間アドレスを発生できる。
第２ＭＭＵ２１７０はパス２１５７を通してマイクロＴＬＢ２１５５により、またはパス２１６７を通して変換テーブルウォークロジック２１６５により出力される中間アドレスを受信するようになっており、マイクロＴＬＢ２１７５内で一致が検出された場合、マイクロＴＬＢはパス２１９２を通してメモリに必要な物理アドレスを発生し、データバス２１９０を通して必要なデータを検索させる。中間アドレスはパス２１５７を通して発生された場合、これによって必要なデータをコア１０に戻され、一方、パス２１６７を通して発生される中間アドレスに対し、メインＴＬＢ２１６０に記憶できるように、第１ＭＭＵ２１５０に対し、必要なデスクリプタがリターンされる。
マイクロＴＬＢ２１７５に不一致があった場合、メインＴＬＢ２１８０が参照され、メインＴＬＢ内に一致があった場合、必要な中間アドレス部分および対応する物理アドレス部分がマイクロＴＬＢ２１７５へ戻され、次にマイクロＴＬＢ２１７５がパス２１９２を通して必要な物理アドレスを発生できるようにする。しかしながら、マイクロＴＬＢ２１７５でもメインＴＬＢ２１８０でも一致がなかった場合、変換テーブルウォークロジック２１８５は第２ＭＭＵ２１７０に関連したページテーブルの第２のセット内の対応するページテーブルから、必要なデスクリプタに対してパス２１９４を通してリクエストを出力するようになっている。このページテーブルの第２のセットは中間アドレス部分と物理アドレス部分を関連付けるデスクリプタを含み、一般に安全ドメインのための少なくとも１つのページテーブルおよび非安全ドメインのための１つのページテーブルが設けられる。パス２１９４を通してリクエストが発生されると、この結果、ページテーブルの第２のセットからの対応するデスクリプタが第２ＭＭＵ２１７０へ戻され、メインＴＬＢ２１８０内に記憶できる。
次に、後述する特定の例により、更に図５０Ａに示されている実施例の作動について説明する。この例では、略語ＶＡは仮想アドレスを示し、ＩＡは中間アドレスを示し、ＰＡは物理アドレスを示す。
１）コアがＶＡ＝３０００を発生する ［ＩＡ＝５０００、ＰＡ＝７０００］
２）ＭＭＵ１のマイクロＴＬＢ内で不一致
３）ＭＭＵ１のメインＴＬＢ内で不一致
ページテーブル１のベースアドレス＝８０００ＩＡ［ＰＡ＝１００００］
４）ＭＭＵ１内の変換テーブルウォークロジックがページテーブルルックアップを実行し、
ＩＡ＝８００３を発生する。
５）ＭＭＵ２のマイクロＴＬＢ内で不一致
６）ＭＭＵ２のメインＴＬＢ内で不一致
ページテーブル２のベースアドレス＝１２０００ＰＡ
７）ＭＭＵ２内の変換テーブルウォークロジックがページテーブルルックアップを実行し、
ＰＡ＝１２００８を発生する。
「８０００ＩＡ＝１００００ＰＡ」がページテーブルデータとしてリターンされる。
８）ＭＭＵ２のメインＴＬＢ内に記憶される。
９）ＭＭＵ２のマイクロＴＬＢ内に記憶される。
１０）ＭＭＵ２内のマイクロＴＬＢが一致を有し、
ＰＡ＝１０００３を発生する。
「３０００ＶＡ＝５０００ＩＡ」がページテーブルデータとしてリターンされる。
１１）ＭＭＵ１のメインＴＬＢ内に記憶される。
１２）ＭＭＵ１のマイクロＴＬＢ内に記憶される。
１３）ＭＭＵ１内のマイクロＴＬＢが一致を有し、
ＩＡ＝５０００を発生しデータアクセスを実行する。
１４）ＭＭＵ２のマイクロＴＬＢ内で不一致
１５）ＭＭＵ２のメインＴＬＢ内で不一致
１６）ＭＭＵ２内の変換テーブルウォークロジックがページテーブルルックアップを実行し、
ＰＡ＝１２００５を発生する。
「５０００ＩＡ＝７０００ＰＡ」がページテーブルデータとしてリターンされる。
１７）ＭＭＵ２のメインＴＬＢ内に記憶される。
１８）ＭＭＵ２のマイクロＴＬＢ内に記憶される。
１９）ＭＭＵ２内のマイクロＴＬＢが一致を有し、
ＰＡ＝７０００を発生し、データアクセスを実行する。
２０）物理アドレス７０００におけるデータがコアにリターンされる。
次の時間コアがメモリアクセスリクエスト（例えばＶＡ３００１....）を発生する。
１）コアがＶＡ＝３００１を発生する。
２）ＭＭＵ１のマイクロＴＬＢ内で一致があり、ＭＭＵ２にリクエストＩＡ５００１が発生される。
３）ＭＭＵ２のマイクロＴＬＢ内で一致があり、メモリへＰＡ７００１のためのリクエストが発生される。
４）ＰＡ７００１におけるデータがコアにリターンされる。
上記例では、双方のＭＭＵ２のマイクロＴＬＢおよびメインＴＬＢの双方で一致が生じ、よってこの例は最悪ケースのシナリオを示していることが理解できよう。一般に、マイクロＴＬＢまたはメインＴＬＢの少なくとも１つで一致が観察され、従ってデータを検索するのにかかる時間が大幅に短縮されることが予想される。
図５１に戻ると、好ましい実施例の安全領域における物理アドレス空間の所定の領域内には一般にページテーブルの第２のセット２２５０が設けられる。このページテーブルの第１セットは２つのタイプ、すなわち安全ページテーブルと非安全ページテーブルとに分割できる。非安全中間アドレス空間２２７５内の非安全ページテーブルと同じように、中間アドレス空間２２６５内には安全ページテーブルが連続的に生じることが好ましい。しかしながら、安全ページテーブルは物理アドレス空間内に連続的に設置する必要はないので、例えば安全領域２２１０、２２３０全体にページテーブルの第１セットのための安全ページテーブルを広げることができ、同じように非安全ページテーブルも非安全メモリ領域２２２０および２２４０全体に広げてもよい。
上記のようにページテーブルの２つのセットの２レベルのアプローチを使用する主な利点の１つとして、安全ドメインのオペレーティングシステムおよび非安全ドメインのオペレーティングシステムの双方に対し、物理アドレス空間が一般にオペレーティングシステムによって予想されるゼロでスタートするようにできる。更にオペレーティングシステムは中間アドレスの連続シーケンスを有するように配列できる中間アドレス空間を物理アドレス空間として見るので、「物理アドレス」空間の非安全オペレーティングシステムのビューから安全メモリ領域を完全に隠すことができる。
更に、かかるアプローチを使用することにより、非安全メモリと安全メモリとの間のメモリの領域をスワッピングする方法をかなり簡略化できる。このことは、図５２を参照して略図で示されている。図５２から分かるように、例えばメモリの単一ページとすることができるメモリの領域２３００は非安全メモリ領域２２２０内に存在でき、同様にメモリ領域２３１０は安全メモリ領域２２１０内に存在できる。領域２３００が安全領域の中間アドレス空間内の領域２３０５にマッピングされた安全領域となり、他方、領域２３１０が非安全ドメインの中間アドレス空間内の領域２３１５にマッピングされた非安全領域となるように、ページテーブルの第２の組内の対応するデスクリプタを変えるだけで、これら２つのメモリ領域２３００と２３１０を容易にスワッピングできる。しかしながら、このことは安全ドメインおよび非安全ドメインの双方におけるオペレーティングシステムに対して完全にトランスペアレントに生じる。その理由は物理アドレス空間のビューは実際には安全ドメインまたは非安全ドメインの中間アドレス空間であるからである。従って、このアプローチは各オペレーティングシステム内の物理アドレス空間を再定義しなくてもよいようにできる。
次に、図５２を参照し、２つのＭＭＵも使用するが、図５０Ａの構造と別の構造となっている本発明の別の実施例について説明する。図５０Ｂと図５０Ａとを比較することから判るように、構造はほとんど同じであるが、この実施例では第１ＭＭＵ２１５０は仮想アドレスから物理アドレスへの変換を実行するようになっており、第２ＭＭＵは中間アドレスから物理アドレスへの変換を実行するようになっている。従って、図５０Ａで使用される第１ＭＭＵ２１５０内のマイクロＴＬＢ２１５５から、第２ＭＭＵ２１７０内のマイクロＴＬＢ２１７５へのパス２１５７の代わりに、第１ＭＭＵ内のマイクロＴＬＢ２１５５が図５０Ｂに示されるようにパス２１９２を通して直接物理アドレスを出力するようになっている。次に、図５０Ａの実施例に対してこれまで説明したように、同じコアメモリアクセスリクエストの処理を詳細に説明する下記のような特定の例により、図５０ｂに示された実施例の作動について説明する。
１）コアがＶＡ＝３０００を発生する。［ＩＡ＝５０００、ＰＡ＝７０００］
２）ＭＭＵ１のマイクロＴＬＢおよびメインＴＬＢ内で不一致。
ページテーブル１のベースアドレス＝８０００ＩＡ ［ＰＡ＝１００００］
３）ＭＭＵ１内の変換テーブルウォークロジックがページテーブルルックアップを実行し、
ＩＡ＝８００３を発生する。
４）ＭＭＵ２のマイクロＴＬＢおよびメインＴＬＢ内でＩＡ８００３が不一致。
ページテーブル２のベースアドレス＝１２０００ＰＡ
５）ＭＭＵ２内の変換テーブルウォークロジックがページテーブルルックアップを実行し、
ＰＡ＝１２００８を発生する。
「８０００ＩＡ＝１００００ＰＡ」がページテーブルデータとしてリターンされる。
６）ＭＭＵ２のメインおよびマイクロＴＬＢ内に「８０００ＩＡ＝１００００ＰＡ」のマッピングが記憶される。
７）ＭＭＵ２内のマイクロＴＬＢはステップ（３）カラＰＡ１０００３までリクエストを変換でき、フェッチを発生する。
ページテーブルデータとして「３０００ＶＡ＝５０００ＩＡ」がリターンされる。
注： この変換はＭＭＵ２によって一時記憶装置に保持されるが、ＴＬＢに直接記憶されることはない。
８）ＭＭＵ２の変換テーブルウォークロジックがＩＡ＝５０００に対するＭＭＵ２にリクエストを発生する。
９）ＭＭＵ２のマイクロＴＬＢおよびメインＴＬＢ内でＩＡ５０００が不一致。
１０）ＭＭＵ２内の変換テーブルウォークロジックがページテーブルルックアップを実行し、
ＰＡ＝１２００５を発生する。
ページテーブルデータとして「５０００ＩＡ＝７０００ＰＡ」がリターンされる。
１１）ＭＭＵ２がマイクロＴＬＢおよびメインＴＬＢ内に「５０００ＩＡ＝７０００ＰＡ」を記憶する。この変換はＭＭＵ１にも伝えられる。
１２ａ）ＭＭＵ２がメモリへＰＡ＝７０００アクセスを発生する。
１２ｂ）ＭＭＵ１が「３０００ＶＡ＝５０００ＩＡ」と「５０００ＩＡ＝７０００ＰＡ」デスクリプタを組み合わせ、「３０００ＶＡ＝７０００ＰＡ」デスクリプタを与え、このデスクリプタはｍＭＵ１のメインＴＬＢおよびマイクロＴＬＢに記憶される。
１３）ＰＡ７０００におけるデータはコアへリターンされる。
次の時間コアがメモリアクセスリクエスト（例えばＶＡ３００１....）を発生する。
１）コアがＶＡ＝３００１を発生する。
２）ＭＭＵ１のマイクロＴＬＢ内で一致があり、ＭＭＵ１がＰＡ７００１に対するリクエストを発生する。
４）ＰＡ７００１におけるデータがコアにリターンされる。
上記例と図５０Ａに対して提供された例との比較から判るように、主な差はＭＭＵ１が第１テーブルデスクリプタを直接記憶しないステップ７、およびＭＭＵ１がＩＡ−＞ＰＡ変換も受信し、これらの組み合わせを行い、組み合わされたデスクリプタをそのＴＬＢに記憶するステップ１２ｂ（１２ａと１２ｂとは同時に生じ得る）にある。
従って、この別の実施例は仮想アドレスから物理アドレスに変換するのにページテーブルの２つのセットを使用しているが、マイクロＴＬＢ２１５５とメインＴＬＢ２１６０とが直接の仮想アドレス−物理アドレス変換を記憶しているという事実により、マイクロＴＬＢ２１５５またはメインＴＬＢ２１６０のいずれかで一致が生じたときに、双方のＭＭＵでルックアップを実行しなくてもよいようになる。かかるケースでは、第１ＭＭＵは第２ＭＭＵを参照することなく、コアからのリクエストを直接取り扱いできる。
第２ＭＭＵ２１７０はマイクロＴＬＢ２１７５およびメインＴＬＢ２１８０を含まなくてもよいようにできることが理解できよう。この場合、第２ＭＭＵによる取り扱いを必要としたどのリクエストに対しても、ページテーブルウォークロジック２１８５が使用される。このことは、第２ＭＭＵの複雑さを下げ、コストを節約するので、第２ＭＭＵがあまり頻繁には必要とされないことを仮定すれば受け入れ可能である。どのリクエストに対しても第１ＭＭＵを使用しなければならないので、一般に第１ＭＭＵの動作速度を改善するのに第１ＭＭＵ２１５０内にマイクロＴＬＢ２１５５およびメインＴＬＢ２１６０を設けることは好都合となる。
ページテーブル内のページはサイズが変わり得るので、変換の半分の２つのためのデスクリプタが異なるサイズのページに関連できることに留意すべきである。一般にＭＭＵ１のページのほうがＭＭＵ２のページよりも小さくなるが、必ずしもこのような場合になるわけではない。例えば、
テーブル１は０ｘ４０００３０００における４Ｋｂを０ｘ０００８１０００にマッピングする。
テーブル２は０ｘ００００００００における１Ｍｂを０ｘ０２００００００にマッピングする。
ここで、組み合わせ変換を行うには２つのサイズのうちの小さい方を使用しなければならないので、組み合わせデスクリプタは次のようになる。
０ｘ０２０８１０００に対する０ｘ４０００３０００における４Ｋｂとなる。
しかしながら、（図５２を参照して前に説明したように）ワールド間でデータをスワップする場合、この逆も真となり得る。例えば、
テーブル１は０ｘｃ０００００００における１Ｍｂを０ｘ００００００００にマッピングする。
テーブル２は０ｘ０００４２０００における４Ｋｂを０ｘ０２０４２０００にマッピングする。
次にコアからのアドレス０ｘｃ００４２０１０におけるルックアップは次のマッピングを与える。
０ｘ０２０４２０００に対する０ｘｃ００４２０００における４Ｋｂ
すなわち組み合わせマッピングに対して常に２つのサイズのうちの小さい方を使用する。
第２のケースでは、プロセスはより効率が低い。その理由は、テーブル１における（１Ｍｂの）デスクリプタは繰り返しルックアップされ、異なる４Ｋｂのエリアにアクセスされる際に廃棄されるからである。しかしながら、代表的なシステムでは大部分の時間でテーブル２のデスクリプタのほうが（第１の例のように）大きく、この場合の方がより効率的である（ＩＡの空間の適当な部分をポイントする別の４Ｋｂのページに対しては２Ｍｂのマッピングをリサイクルできる）。
図５０Ａおよび５０Ｂに示されるように、２つの別個のＭＭＵを使用する別の例として、図５３に示されるように単一のＭＭＵを使用できる。メインＴＬＢ２４２０内で不一致が生じた場合、ＭＭＵによって例外が発生され、この例外はソフトウェアをコア１０内で作動させ、ページテーブルの２つの異なるセットからのデスクリプタの組み合わせに基づき、仮想−物理アドレス変換を生じさせる。より詳細には、図５３に示されるように、コア１０はＭＭＵ２４００に結合されており、このＭＭＵ２４００はマイクロＴＬＢ２４１０とメインＴＬＢ２４２０とを含む。コア１０がメモリアクセスリクエストを発生すると、パス２４３０を通して仮想アドレスが提供される。マイクロＴＬＢ内で一致が見いだされると、パス２４４０を通して対応する物理アドレスが直接出力され、データがパス２４５０を通してコア１０へリターンされる。しかしながら、マイクロＴＬＢ２４１０内で不一致があった場合、メインＴＬＢ２４２０が参照され、メインＴＬＢ内に対応するデスクリプタが含まれている場合には関連する仮想アドレス部分および対応する物理アドレス部分がマイクロＴＬＢ２４１０に検索され、その後、パス２４４０を通して物理アドレスを発生できる。しかしながら、メインＴＬＢが不一致も発生する場合、パス２４２２を通してコアに例外が発生される。次に、図５４を参照し、かかる例外の受信からコア内で実行されるプロセスについて更に説明する。
図５４に示されるように、ステップ２５００でコアによりＴＬＢ不一致例外が検出された場合、コアはステップ２５１０にてその例外に対する所定のベクトルでモニタモードに入る。このことによって、ページテーブルマージコードが作動され、図５４に示されたステップで他の部分を実行する。
より詳細には、ステップ２５２０にてパス２４３０を通して発生され、マイクロＴＬＢ２４１０およびメインＴＬＢ２４２０の双方での不一致を生じさせた仮想アドレス（以下、フォールト仮想アドレスと称す）が検索され、その後、ステップ２５３０にてテーブルの第１のセット内の適当なテーブルに対する中間ベースアドレスに応じて、必要な第１デスクリプタに対する中間アドレスが決定される。（一般に仮想アドレスと中間ベースアドレスとの所定の組み合わせにより）中間アドレスが一旦決定されると、テーブルの第２セット内の対応するテーブルが参照され、第１デスクリプタに対する対応する物理アドレスが得られる。その後、ステップ２５５０にてメモリから第１デスクリプタをフェッチし、フォールト仮想アドレスに対する中間アドレスを決定できる。
次にステップ２５６０にて再び第２テーブルを参照し、フォールト仮想アドレスの中間アドレスに対する物理アドレスを与える第２デスクリプタを探す。その後、ステップ２５７０にて第２デスクリプタをフェッチし、フォールト仮想テーブルに対する物理アドレスを得る。
一旦上記情報が得られると、プログラムは第１デスクリプタと第２デスクリプタとをマージし、必要な仮想アドレス−物理アドレス変換を与える新しいデスクリプタを発生する。このプロセスはステップ２５８０で実行される。図５０Ｂを参照して前に説明したのと同じように、ソフトウェアによって実行されるマージは再び組み合わされた変換に対する最小のページテーブルサイズを使用する。その後、ステップ２５９０にてメインＴＬＢ２４２０内に新しいデスクリプタが記憶され、その後、ステップ２５９０にて例外からプロセスがリターンされる。
その後、コア１０はパス２４３０を通してメモリアクセスリクエストに対する仮想アドレスを再発生するようになっており、この再発生の結果、マイクロＴＬＢ２４１０内で不一致が生じるが、メインＴＬＢ２４２０内では一致が生じる。従って、マイクロＴＬＢ２４１０内に仮想アドレス部分と対応する物理アドレス部分とを検索でき、その後、マイクロＴＬＢ２４１０はパス２４４０を通して物理アドレスを発生できるので、その結果、必要なデータがパス２４５０を通してコア１０にリターンされる。
図５０Ａおよび５０Ｂを参照してこれまで説明した実施例と別の実施例として、これら実施例における一方または双方のＭＭＵは図５３および５４を参照してこれまで説明した原理を使用するソフトウェアによって管理できることが理解できよう。
図５０Ａまたは５０Ｂに示されるように、２つのＭＭＵを使用するか、または図５３に示されるように、１つのＭＭＵを使用するかのいずれに拘わらず、モニタモード（またはこれとは異なり、特権安全モード）で作動しているときに、ページテーブルの第２セットをプロセッサで管理することにより、これらページテーブルが安全となることを保証できる。この結果、プロセッサが非安全ドメインにあるとき、プロセッサは非安全メモリしか見ることができない。その理由は、プロセッサが非安全ドメインにあるときに見ることができるのは、ページテーブルの第２のセットにより非安全ドメインに対して発生される中間アドレス空間に限られるからである。この結果、図１に示されるようなメモリ管理ロジック３０の一部としてパーティションチェッカーを設ける必要はない。しかしながら、システム内の他のバスマスターによってなされるアクセスをモニタするためのパーティションチェッカーが外部バスに設けられることになる。
図３７および３８を参照して前に説明した実施例では、ＭＭＵ２００に関連してパーティションチェッカー２２２が設けられていたので、キャッシュ３８ないでアクセスを実行すべきときには、まずマイクロＴＬＢ２０６内ですでにルックアップが実行されており、従って、アクセス許可、特に安全許可および非安全許可がチェックされていたはずである。従って、かかる実施例では非安全アプリケーションによりキャッシュ３８に安全データを記憶できない。キャッシュ３８へのアクセスはパーティションチェッカー２２２により行われるパーティションチェックの制御下にあるので、非安全モードでは安全データへのアクセスを行うことができない。
しかしながら、本発明の別の実施例では、システムバス４０を通してなされるアクセスをモニタするためのパーティションチェッカー２２２が設けられておらず、その代わりにデータ処理装置はその外部バスに接続されたメモリユニットへのアクセスをモニタするよう、外部バス７０に結合された単一のパーティションチェッカーを有するに過ぎない。かかる実施例では、このことは外部パーティションチェッカーによりこれらアクセスを規制することなく、システムバス４０に直接結合されたメモリユニット、例えばＴＣＭ３６およびキャッシュ３８にプロセッサコア１０がアクセスできることを意味する。従って、非安全モードで作動している間にキャッシュ３８内またはＴＣＭ３６内の安全データにプロセッサコア１０がアクセスしないように保証するためのある手順が必要である。
図５５は本発明の一実施例に拘わるデータ処理装置を示し、この実施例では、ＭＭＵ２００に関連してパーティションチェックロジックを設けなくても、キャッシュ３８および／またはＴＣＭ３６がこれらへのアクセスを制御できるようにするための手順が設けられる。図５５に示されるように、ＭＭＵ２００を介し、システムバス４０にコア１０が結合されており、キャッシュ３８およびＴＣＭ３６もシステムバス４０に結合されている。コア１０、キャッシュ３８およびＴＣＭ３６は外部バスインターフェース４２を介して外部バス７０に結合されており、外部バスは図５５に示されるように、アドレスバス２６２０、制御バス２６３０およびデータバス２６４０から成る。
コア１０、ＭＭＵ２００、キャッシュ３８、ＴＣＭ３６および外部バスインターフェース４２はデバイスバスとも称される外部バス７０に接続された単一デバイスを構成すると見なすことができ、このデバイスバスには他のデバイス、例えば安全周辺デバイス４７０または非安全周辺デバイス４７２も接続できる。更に、デバイスバス７０は１つ以上のメモリユニット、例えば外部メモリ５６も接続される。更に、デバイスバス７０にはバス制御ユニット２６５０が接続されており、この制御ユニットは一般にアービタ２６５２、デコーダ２６５４およびパーティションチェッカー２６５６を含む。デバイスバスに接続された構成部品の作動を一般に説明するには、前に説明した図４７を参照すべきである。前に説明した図４７では、アービタ２６５２とデコーダと、パーティションチェッカーは別個のブロックとして示されていたが、これら要素は単一制御ブロック２６５０に入れても同じように働く。
図５６に図５５のＭＭＵ２００をより詳細に示す。図５６と図３７とを比較することにより、ＭＭＵ２００は図３７のＭＭＵと全く同じように構成され、唯一の差異はメインＴＬＢ２０８とマイクロＴＬＢ２０６との間でパス２４２を通して送られるデータをモニタするためのパーティションチェッカー２２２が設けられていないことであるということが理解できよう。プロセッサコア１０が仮想アドレスを指定するメモリアクセスリクエストを発生した場合、このメモリアクセスリクエストはＭＭＵ２００を通過するようにルーティングされ、図３７を参照して前に説明したように処理され、この結果、マイクロＴＬＢ２０６からパス２３８を通してシステムバス４０に物理アドレスが出力される。これと対照的に、メモリアクセスリクエストが直接物理アドレスを指定する場合、このアドレスはＭＭＵ２００をバイパスし、代わりにパス２３６を介してシステムバス４０に直接ルーティングされる。一実施例では、プロセッサがモニタモードで作動しているときにしか、物理アドレスを直接指定するメモリアクセスリクエストを発生しない。
ＭＭＵ２００の前の説明、および特に図４３の説明から思い出されるように、メインＴＬＢ２０８は多数のデスクリプタ４３５を含み、各デスクリプタに対し、対応するデスクリプタが安全ページテーブルからのものであるか、または非安全ページテーブルからのものであるかを識別するためのドメインフラグ４２５が設けられる。図５５のＭＭＵ２００内にはこれらデスクリプタ４３５および関連するドメインフラグ４２５が略図で示されている。
コア１０がメモリアクセスリクエストを発生すると、この結果、システムバス４０にそのメモリアクセスリクエストのための物理アドレスが出力され、そのアドレスによって指定されるデータアイテムがキャッシュ内に記憶されているかどうかを判断するためのルックアッププロセスを一般に実行する。キャッシュ内に不一致が生じるときはいつも、すなわちアクセスリクエストを受けたデータアイテムがキャッシュ内に記憶されていなかったときはいつも、メモリアクセスリクエストの対象であるデータアイテムを含むデータのラインを外部メモリ４５から検索するためのラインフィル手順がキャッシュにより開始される。特にキャッシュはアドレスバス２６２０に出力されたスタートアドレスにより、デバイスバス７０の制御バス２６３０にＥＢＩ４２を介してラインフィルリクエストを出力する。更にバス２６３２を通してＨＰＲＯＴ信号が制御バス２６３０に出力され、このＨＰＲＯＴ信号はメモリアクセスリクエストが発生されたときに、コアの作動モードを指定するドメイン信号を含む。従って、ラインプロセスをキャッシュ３０に載る外部バスへの元のメモリアクセスリクエストの伝搬と見なすことができる。
このＨＰＲＯＴ信号はパーティションチェッカー２６５６によって受信されるので、外部メモリ５６から指定されたデータをリクエストするデバイス（この場合、デバイスはコア１０およびキャッシュ３８を実装している）が、メモリアクセスリクエストが発生されたときに安全ドメインで作動していたか、または非安全ドメインで作動していたかをパーティションチェッカーに対して識別する。パーティションチェッカー２６５６はメモリのどの領域が安全であるか、または非安全であるかを識別するパーティション情報にもアクセスするので、デバイスがリクエストしているデータにアクセスすることを許可されているかどうかを判断できる。従って、パーティションチェッカーはＨＰＲＯＴ信号内のドメイン信号（本書ではＳビットとも称す）が、安全作動モードで作動中のデバイスによって、このデータへのアクセスがリクエストされたことを識別するようにアサートされた場合にしか、デバイスがメモリの安全部分にアクセスできないようにすることができる。
コアが非安全モードで作動中であるが、メモリの安全領域内にある外部メモリからデータをラインフィルリクエストが検索しようとしていることを、例えばＨＰＲＯＴ信号が識別しているので、リクエストされたデータへのアクセスをすることが、コア１０には許可されていないとパーティションチェッカーが判断した場合、パーティションチェッカー２６５６は制御バス２６３０へアボート信号を発生し、この信号はパス２６３６を通してＥＢＩ４２へ、更にこれからキャッシュ３８へ送られ、この結果、パス２６７６を通してコア１０にアボート信号が発生される。しかしながら、アクセスが許可されていないとパーティションチェッカー２６５６が判断した場合、パーティションチェッカーは外部メモリから検索されたデータが安全データであるか、または非安全であるかであるかを識別するＳタグ信号を出力し、このＳタグ信号はパス２６４５を通してＥＢＩ４２に、更にこれからキャッシュ３８へ送られ、ラインフィルプロセスの対象であるキャッシュライン２６００に関連するフラグ２６０２の設定を可能にする。
同時に制御ロジック２６５０はリクエストされたラインフィルデータを出力するために外部メモリ５６を認証する。このデータはパス２６８０を通し、ＥＢＩ４２を介し、キャッシュ３８へ送られ、対応するキャッシュライン２６００へ記憶される。従って、このプロセスの結果としてキャッシュライン３８内の選択されたキャッシュラインには、外部メモリ５６からのデータアイテムが満たされ、これらデータアイテムはコア１０からの元のメモリアクセスリクエストの対象であるデータアイテムを含む。コアからのメモリアクセスリクエストの対象であるデータアイテムを次にキャッシュ３８からコアにリターンできるか、これとは異なり、パス２６６０を通してＥＢＩ４２からコア１０へ直接提供できる。
好ましい実施例では、上記ラインフィルプロセスの結果として、キャッシュラインでのデータの元の記憶が行われるので、そのキャッシュラインに関係するフラグ２６０２はパーティションチェッカー２６５６によって提供される値に基づきセットされ、次にそのフラグはそのキャッシュライン２６００内のデータアイテムへのその後のアクセスを直接制御するのに、キャッシュ３８によって使用できる。従って、コア１０がキャッシュ３８の特定のキャッシュライン２６００内で一致を生じさせるメモリアクセスリクエストをその後発生した場合、キャッシュ３８は関連するフラグ２６０２の値を検討し、その値とコア１０の現在の作動モードとを比較する。好ましい実施例では、コア１０のそのときの作動モードはＣＰ１５ドメインステータスレジスタ内のモニタモードによってセットされるドメインビットによって表示される。従って、プロセッサコア１０が安全作動モードで作動しているときにしか、対応するフラグ２６０２が安全データであると表示したキャッシュライン内のデータアイテムにプロセッサコアがアクセスできないように、キャッシュ３８を構成できる。コアが非安全モードで作動している間のキャッシュ３８内の安全データへのアクセスをする、コアによる試みがなされる結果、キャッシュ３８はパス２６７０を通してアボート信号を発生する。
ＴＣＭ３６は種々の方法で設定できる。一実施例では、キャッシュのように作動するよう、セットできる。この実施例では、ＴＣＭ３６は複数のライン２６１０を含むように構成され、ラインの各々はキャッシュ３８と同じようにラインに関連したフラグ２６１２を有する。キャッシュ３８を参照して前に説明したのと全く同じように、ＴＣＭ３６へのアクセスが管理され、ＴＣＭの不一致の結果、ラインフィルプロセスが実行され、この結果、データが特定のライン２６１０に検索され、パーティションチェッカー２６５６がそのライン２６１０に関連したフラグ２６１２に記憶するための必要なＳタグ値を発生する。
別の実施例では、外部メモリ５６の延長としてＴＣＭ３６を設定でき、プロセッサにより頻繁に使用されるデータを記憶するのにこのＴＣＭ３６を使用できる。その理由は、システムバスを介したＴＣＭのアクセスは、外部メモリのアクセスよりもかなり高速であるからである。かかる実施例では、ＴＣＭ３６はフラグ２６１２を使用せず、代わりにＴＣＭへのアクセスを制御するのに異なる手順が使用される。特に前に説明したように、かかる実施例では、密に結合されたメモリが特権安全作動モードで作動中にしかプロセッサによって制御できないのか、または少なくとも１つの非安全モードで実行中のプロセッサによって制御できるのかのいずれかを表示するよう、特権安全モードで作動中のプロセッサによって設定可能な制御フラグを設けることができる。この制御フラグは安全オペレーティングシステムによってセットでき、実際にＴＣＭが特権安全モードで制御するのか、または非安全モードで制御するのかを定める。従って、構成できる１つのコンフィギュレーションはプロセッサが特権安全作動モードで作動しているときにしか制御できないというコンフィギュレーションである。かかる実施例では、ＴＣＭ制御レジスタで試みられる非安全アクセスは、無定義命令例外に進入させる。
別のコンフィギュレーションでは、非安全作動モードで作動中のプロセッサによってＴＣＭを制御できる。かかる実施例では、ＴＣＭは非安全アプリケーションによってしか使用されない。ＴＣＭへ安全データを記憶したり、ＴＣＭから安全データをロードしたりすることはできない。従って、安全アクセスを実行するときには、アドレスがＴＣＭアドレスレンジに一致しているかどうかを見るためのルックアップはＴＣＭ内では実行されない。
図５７はプロセッサコア１０で作動中の非安全プログラムが仮想アドレスを発生したとき（ステップ２７００）に、図５５の装置によって実行されるプロセスを示すフローチャートである。最初に、ステップ２７０５においてマイクロＴＬＢ２０６内でルックアップが実行され、この結果、一致が生じた場合、マイクロＴＬＢはステップ２７３０でアクセス許可をチェックする。図５６を参照すると、このプロセスはアクセス許可ロジック２０２によって実行されているものと見なすことができる。
ステップ２７０５において、マイクロＴＬＢのルックアップ内で不一致が生じた場合、内部に記憶された非安全デスクリプタの間のルックアップがメインＴＬＢ２０８内で実行される（ステップ２７１０）。この結果不一致が生じた場合、ステップ２７１５へページテーブルウォークプロセス（これについては図３７を参照して前に詳細に説明してある）が実行され、ここでステップ２７２０の後でメインＴＬＢが有効なタグ付き非安全デスクリプタを含むと判断される。ステップ２７１０におけるルックアップが一致を生じさせた場合、プロセスは直接ステップ２７２０に進む。
その後、ステップ２７２５において、物理アドレスを含むデスクリプタ部分がマイクロＴＬＢにロードされ、その後、ステップ２７３０にてマイクロＴＬＢがアクセス許可をチェックする。
ステップ２７３０にて、アクセス許可の違反があったと判断された場合、プロセスはステップ２７４０に進み、ここでパス２３０（図５５に示されたパス２６７０に類似する）を通してプロセッサコアにアボート信号が発生される。しかしながら、違反が検出されないと仮定した場合、ステップ３７４５において、アクセスがキャッシュ可能なデータアイテムに関係しているかどうかが判断される。関係していなければ、ステップ２７９０にて外部メモリ５６からデータアイテムを検索するための外部アクセスが開始される。ステップ２７９５にて、パーティションチェッカー２６５６は安全パーティション違反があるかどうか、例えば非安全モードで作動中にプロセッサコア１０が安全メモリ内のデータアイテムにアクセスしようとしているかどうかを判断する。違反が検出された場合、２７７５にてパーティションチェッカー２６５６はアボート信号を発生する。しかしながら、非安全パーティション違反がない場合、プロセスはステップ２７８５に進み、ここでデータアクセスが生じる。
ステップ２７４５にて、リクエストされているデータアイテムがキャッシュ可能であると判断された場合、ステップ２７５０にてキャッシュ内でキャッシュのルックアップが実行され、一致が検出されれば、キャッシュはステップ２７５５にて安全ラインタグ違反があるかどうかを判断する。従って、この段階でキャッシュはデータアイテムを含むキャッシュラインに関連したフラグ２６０２の値を検討し、そのフラグの値とコア１０の作動モードとを比較し、リクエストされたデータアイテムへアクセスする権利がコアに与えられているかを判断する。安全ラインタグ違反が検出された場合、プロセスはステップ２７６０に進み、ここでキャッシュ３８により安全違反フォールトアボート信号が発生され、パス２６７０を通してコア１０へこの信号が送られる。しかしながら、ステップ２７５５にて非安全ラインタグ違反が検出されなかった場合、ステップ２７８５にてデータアクセスが実行される。
ステップ２７５０にてキャッシュのルックアップが実行されたときに、キャッシュの不一致が生じた場合、ステップ２７６５にてキャッシュのラインフィルが開始される。ステップ２７７０にてパーティションチェッカー２６５６は安全パーティションチェッカー違反があるかどうかを検出し、違反が検出されれば、ステップ２７７５にてアボート信号を発生する。しかしながら、非安全パーティション違反が検出されなかった場合、ステップ２７８０にてキャッシュラインフィルが進み、その結果、ステップ２７８５にてデータアクセスが完了する。
図５７に示されるように、ステップ２７０５、２７１０、２７１５、２７２０、２７２５、２７３０および２７３５はＭＭＵ内で実行され、ステップ２７４５、２７５０、２７５５、２７６５、２７８０および２７９０はキャッシュによって実行され、ステップ２７７０およびステップ２７９５はパーティションチェッカーによって実行される。
図５８はコアで実行中の安全プログラムが仮想アドレスを発生した場合（ステップ２８００）に実行される類似のプロセスを示すフローチャートである。図５８と図５７とを比較すると、ＭＭＵ内で実行されるステップ２８０５〜２８３５は、図５７を参照して前に説明したステップ２７０５〜２７３５に類似していることが理解できよう。これらの違いはステップ２８１０にあり、メインＴＬＢ内に記憶された安全デスクリプタに関連してメインＴＬＢ内で実行されるルックアップが実行され、この結果、ステップ２８２０にてメインＴＬＢは有効なタグの付いた安全デスクリプタを含む。
図５８を参照した実施例では、安全プログラムは安全データと非安全データの双方にアクセスできると仮定しているので、キャッシュ内ではキャッシュは安全ラインタグ違反を探す必要はない。従って、ステップ２８５０にてキャッシュのルックアップ中に一致が生じた場合、プログラムは直接データアクセスステップ２８８５に進む。
同様に、（例えばステップ２８６５または２８９０にて）外部メモリへの外部アクセスが必要とされた場合、安全プログラムは安全データまたは非安全データのいずれにもアクセスできると仮定されているので、パーティションチェッカーはパーティションチェックを実行しなくてもよい。
キャッシュ内で実行されるステップ２８４５、２８５０、２８６５、２８８０および２８９０は、図５７を参照して前に説明したステップ２７４５、２７５０、２７６５、２７８０および２７９０に類似している。
図５７はプロセッサで作動する異なるモードおよびアプリケーションを示す。点線は本発明の実施例に従い、プロセッサのモニタ中に異なるモードおよび／またはアプリケーションを互いにどのように分離し、アイソレートできるかを示している。
生じ得る障害を発見し、なぜアプリケーションが期待するように作動しないかを発見するために、プロセッサをモニタする能力は極めて有効であり、多くのプロセッサはかかる機能を提供している。デバッグ機能およびトレース機能を含む種々の方法でモニタを行うことができる。
本技術に係わるプロセッサでは、フォールトデバッグモードおよびモニタデバッグモードを含むいくつかのモードでデバッグが作動できる。これらモードは侵襲的であり、このときに実行中のプログラムを停止させる。フォールトデバッグモードにおいて、ブレークポイントまたはウォッチポイントが発生すると、コアが停止され、システムの他の部分からアイソレートされ、コアはデバッグステートに入る。デバッグステートに入るときにコアはホールト（ｈａｌｔ）されパイプラインがフラッシングされるが、命令はプリフェッチされない。ＰＣはフリーズされ、どのインターラプト（ＩＲＱおよびＦＩＱ）も無視される。（ＪＴＡＧシリアルインターフェースを介し）コアの内部ステートだけでなくメモリシステムのステートも検査できる。そのときのモードを改善し、レジスタコンテンツなどを変更できるので、このステートはプログラムの実行に対して侵襲的である。デバッグが一旦終了すると、コアはデバッグＴＡＰ（テストアクセスポート）を通して再スタート命令でスキャンすることにより、デバッグステートから出ることができる。
モニタデバッグモードではブレークポイントまたはウォッチポイントはコアがアボートモードに入るようにさせ、それぞれプリフェッチまたはデータアボートベクトルを取り込む。この場合、コアはまだ機能モードにありホールトデバッグモードとなっているので、まだ停止されていない。アボートハンドラーはデバッグアプリケーションと通信し、プロセッサおよびコプロセッサのステートまたはダンプメモリにアクセスする。デバッグハードウェアとソフトウェアデバッガーとの間をデバッグモニタプログラムがインターフェースする。デバッグステートのビット１１および制御レジスタＤＳＣＲがセット（後に参照）された場合、インターラプト（ＦＩＱおよびＩＲＱ）を禁止できる。モニタデバッグモードではデータアボートおよびプリフェッチアボートでベクトルキャッチがディスエーブルされ、モニタデバッグモードに対して発生されたアボートの結果として、プロセッサが強制的にリカバー不能ステートされるのを防止する。モニタデバッグモードはある種のデバッグモードであり、安全ワールドと非安全ワールドとの間の切り換えをスーパーバイズ（監督）するモードであるプロセッサのモニタモードには関連していないことに留意すべきである。
デバッグはある瞬間においてプロセッサのステートのスナップショットを提供できる。デバッグはデバッグの開始リクエストが受信された瞬間における種々のレジスタ内の値に注目することによってこれを行う。これら値はスキャンチェーン（図６７の５４１、５４４）に記録され、次にＪＴＡＧコントローラ（図１の１８）を使ってシリアルに出力される。
コアをモニタする別の方法は、トレースすることである。このトレースは侵襲的ではなく、コアが作動し続ける際にその後のステートを記録する。トレースは図１の埋め込み型トレースマイクロセル（ＥＴＭ）２２、２６で作動する。ＥＴＭはトレースポートを有し、このトレースポートを介してトレース情報がイクスポートされ、この情報は外部トレースポートアナライザによって分析される。
本技術の実施例のプロセッサは２つの別個のドメインで作動する。上記実施例では、これらドメインは安全ドメインと非安全ドメインとを含む。しかしながら、モニタ機能の目的のために、当業者であれば、これらドメインは両者の間でデータをリークしてはならない２つのドメインとなり得ることが明らかとなろう。本技術の実施例は２つのドメイン間でのデータのリークを防止することに関係するものであり、従来システム全体にアクセスが認められていたデバッグおよびトレースのようなモニタ機能はドメイン間でデータがリークする潜在的なソースである。
安全および非安全ドメインまたはワールドの上記例では、安全データは非安全ワールドに利用できるものであってはならない。更に、安全ワールドにおいてデバッグが許可された場合、安全ワールド内のデータの一部を制限したり、隠したりすることが有利となり得る。図５９における点線はデータのアクセスをセグメント化し、異なるレベルの粒度を提供するために可能な方法のいくつかの例を示す。図５９において、モニタモードがブロック５００で示されており、すべてのモードのうちで最も安全なモードであり、安全ワールドと非安全ワールドとの切り換えを制御するものである。モニタモード５００の下方にはスーパーバイザーモードが設けられており、このスーパーバイザーモードは安全スーパーバイザーモード５１０と非安全スーパーバイザーモード５２０とを含む。次に、アプリケーション５２２および５２４を有する非安全ユーザーモードおよびアプリケーション５１２、５１４および５１６を有する安全ユーザーモードがある。モニタモード（デバッグおよびトレース）は（点線５０１の左側までの）非安全モードをモニタするためにしか制御できない。これとは異なり、非安全ドメインまたはワールドおよび安全ユーザーモードはモニタすることが認められる（５０１の左および５０２の下方の５０１の右）。別の実施例では、非安全ワールドおよび安全ユーザードメインで作動する所定のアプリケーションが認められる。この場合、点線５０３による更なるセグメント化が行われる。かかる分割は異なるアプリケーションを作動させる可能性のある異なるユーザー間で安全データがリークすることを防止することを助ける。一部の制御されたケースでは、システム全体のモニタが認められる。必要な粒度によりコアの次の部分はモニタ機能中にアクセスを制御する必要がある。
デバッグイベントでセットできるレジスタは４つある。すなわち命令フォールトステータスレジスタ（ＩＦＳＲ）、データフォールトステータスレジスタ（ＤＦＳＲ）、フォールトアドレスレジスタ（ＦＡＲ）および命令フォールトアドレスレジスタ（ＩＦＡＲ）である。安全ワールドから非安全ワールドに移る際に、一部の実施例ではデータのリークを防止するためにこれらレジスタをフラッシングしなければならない。
ＰＣサンプラーレジスタ：デバッグＴＡＰはスキャンチェーン７を通してＰＣにアクセスできる。安全ワールドでデバッギング中に、安全ワールドで選択されたデバッグ粒度に応じてその値をマスクできる。コアが安全ワールドで作動している間、非安全ワールドまたは非安全ワールド＋安全ユーザーアプリケーションがＰＣのどの値も入手できないことが重要である。
ＴＬＢエントリー：ＣＰ１５を使用することによりマイクロＴＬＢのエントリーを読み出し、メインＴＬＢエントリーを読み出し、かつ書き込むことができる。メインＴＬＢおよびマイクロＴＬＢへのロードおよびマッチングを制御することもできる。特に安全スレッドが知っているデバッグがＭＭＵ／ＭＰＵのアシスタンスを必要とする場合、この種の作動を厳密に制御しなければならない。
性能モニタ制御レジスタ：性能制御レジスタはキャッシュの不一致、マイクロＴＬＢの不一致、外部メモリのリクエスト、実行された分布命令などに関する情報を与える。デバッグステートであっても、非安全ワールドはこのデータにアクセスすべきではない。安全ワールドでデバッグがディスエーブルされた場合でも、カウンターは安全ワールドで作動できなければならない。
キャッシュシステムにおけるデバッギング：キャッシュ化されたシステムではデバッグは非侵襲的にしなければならない。キャッシュと外部メモリとの間のコヒーレンスを維持することが重要である。キャッシュがＣＰ１５を使って無効にでき、キャッシュはすべての領域で強制的に書き込みスルーとすることができる。いずれのケースにおいても、デバッグにおけるキャッシュの挙動の変更を認めることはセキュリティに対して弱くなり、このことは制御されるべきである。
エンディアンネス：デバッグにアクセスできる非安全ワールドまたは安全ユーザーアプリケーションは、エンディアンネスの変更を認めるべきではない。エンディアンネスを変えることによって安全カーネルが誤作動する可能性があり、粒度に従ってデバッグにおいてエンディアンネスのアクセスを禁止する。
モニタ機能の開始時にはコアの一部にたいするモニタ機能のアクセスを制御できるデバッグおよびトレースは種々の方法で初期化される。本技術の実施例は、所定の条件での初期化を認めるだけで、コアの所定の安全部分に対するモニタ機能のアクセスを制御する。
本技術の実施例は次の粒度、すなわち
侵襲的、かつ観測可能な（トレース）デバッグを別々に制御することにより；
安全ワールドのみ、または安全ワールド全体においてデバッグが安全ユーザーモードに入ることを認めることにより；
安全ユーザーモードにおけるデバッグだけを認め、更にスレッドＩＤ（アプリケーション実行中）を考慮することにより、モニタ機能に入ることを制限せんとするものである。
モニタ機能の開始を制御するには、機能をどのように開始できるかを知ることが重要である。図６０はモニタ機能を開始する可能な方法、開始されるモニタ機能のタイプおよびかかる開始命令をプログラムできる方法を示す表である。
一般に、ソフトウェアまたはハードウェアにより、例えばＪＴＡＧコントローラにより、これらモニタ命令に入ることができる。モニタ機能の開始を制御するには制御値を使用する。これらの値は条件に依存するイネーブルビットを含むので、特定の条件が存在する場合、イネーブルビットをセットする場合にしかモニタのスタートが認められない。これらビットはＩＣＥ３５０（図６７参照）内にある安全レジスタＣＰ１４、デバッグおよびステータス制御レジスタ（ＤＳＣＲ）に記憶される。
好ましい実施例では、侵襲的かつ観察可能なデバッグをイネーブル／ディスエーブルする４つのビットがある。これらビットは安全デバッグイネーブルビットと、安全トレースイネーブルビットと、安全ユーザーモードイネーブルビットと、安全スレッドアウェアイネーブルビットとを含む。これらの制御値はモニタ機能のためのある程度の制御可能な粒度を提供するように働き、特定のドメインからのデータのリークを停止させることに役立つことができる。図６１はこれらビットの概要およびこれらビットにどのようにアクセスできるかを示している。
これら制御ビットは安全ドメイン内のレジスタに記憶され、このレジスタへのアクセスは３つの可能な例に制限される。ＡＲＭコプロセッサのＭＲＣ／ＭＣＲ命令を介してソフトウェアアクセスが行われ、これら命令には安全スーパーバイザーモードしか認められない。これとは異なり、認証コードを使用することにより、他のどのモードからもソフトウェアアクセスを行うことができる。更に別の例は、ハードウェアアクセスに関係するものであり、ＪＴＡＧ上の入力ポートを介して書き込まれる命令を呼び出す。モニタ機能の利用可能性に関係する制御値を入力するのに使用される他に、この入力ポートはプロセッサの他の機能に関係する制御値を入力するのにも使用できる。
スキャンチェーンおよびＪＴＡＧに関する更なる細部を下記に示す。
レジスタロジックセル
どの集積回路（ＩＣ）も２つの種類のロジックから成る。
・ＡＮＤ、ＯＲ、ＩＮＶゲートのような、組み合わせロジックセル。かかるゲートまたはかかるゲートの組み合わせは１つまたは数個の入力信号に従ってブール式を計算するのに使用される。
・ＬＡＴＣＨ、ＦＬＩＰ−ＦＬＯＰのようなレジスタロジックセル。かかるセルは任意の信号値を記憶するのに使用される。図６２は正のエッジでトリガーされるＦＬＩＰ−ＦＬＯＰの図を示す。
クロック信号（ＣＫ）で正のエッジが生じると、出力（Ｑ）は入力（Ｄ）の値を受信する。そうでない場合、出力（Ｑ）はメモリにその値を保持する。
スキャンチェーンセル
テストまたはデバッグ目的のためには、レジスタロジックセルの機能アクセスをバイパスさせ、レジスタロジックセルのコンテンツに直接アクセスすることが必要である。従って、図６３に示されるように、レジスタセルはスキャンチェーンセル内に集積化されている。
機能モードでは、ＳＥ（スキャンイネーブル）はクリアであり、レジスタセルは単一レジスタセルとして働く。テストまたはデバッグモードでは、ＳＥがセットされ、Ｄ入力の代わりにＳＩ入力（スキャンＩｎ）から入力データがくることができる。
スキャンチェーン
図６４に示されるように、スキャンチェーンにはすべてのスキャンチェーンセルがチェーン状となっている。
機能モードではＳＥはクリアされ、通常どおりすべてのレジスタセルにアクセスでき、レジスタセルは回路の他のロジックと相互作用できる。テストまたはデバッグモードではＳＥはセットされ、スキャンチェーン内ですべてのレジスタは互いにチェーン状となっている。第１スキャンチェーンセルからデータがくることができ、各クロックサイクルのカデンスにおいて、他のスキャンチェーンセルを通してデータをシフトできる。レジスタのコンテンツを見るためにデータをシフトすることもできる。
ＴＡＰコントローラ
いくつかのスキャンチェーンを取り扱うのにＴＡＰコントローラが使用される。このＴＡＰコントローラは特定のスキャンチェーンを選択でき、「スキャンイン」および「スキャンアウト」信号を特定のスキャンチェーンに接続する。次に、データをチェーンへスキャン入力し、シフトし、スキャンアウトすることができる。ＴＡＰコントローラはＪＴＡＧオートインターフェースにより外部から制御できる。図６５はＴＡＰコントローラを略図で示す。
ＪＴＡＧ選択的ディスエーブルチェーンセル
セキュリティの理由から、デバッグまたはテストモードでの一部のレジスタに対してスキャンチェーンによりアクセスできない場合がある。ＪＡＤＩ（ＪＴＡＧアクセスディスエーブル）と称される新しい入力信号は、集積回路におけるスキャンチェーンの構造を変えることなく、全スキャンチェーンから１つのスキャンチェーンセルをダイナミックまたはスタティックに除くことを認めることができる。図６６ＡおよびＢはこの入力信号を略図で示す。
ＪＡＤＩが非アクティブ（ＪＡＤＩ＝０）である場合、機能モードまたはテストもしくはデバッグモードに拘わらず、スキャンチェーンは通常どおり作動する。ＪＡＤＩがアクティブ（ＪＡＤＩ＝１）であり、テストまたはデバッグモードとなっている場合、スキャンチェーン構造から（設計者によって選択した）あるスキャンチェーンセルを除くことができる。同じ数のスキャンチェーンセルを維持するためにＪＴＡＧ選択的ディスエーブルスキャンチェーンセルは１つのバイパスレジスタを使用する。この場合、スキャンアウト（ＳＯ）およびスキャンチェーンセル出力（Ｑ）は異なっていることに留意されたい。
図６７はＪＴＡＧの部品を含むプロセッサを略図で示す。通常の作動では、メモリセル５５０はコアと通信し、所定の状況ではレジスタＣＰ１４とも通信でき、制御値をリセットできる。このことは一般に、安全スーパーバイザーモードからしか認められない。
デバッグが開始されると、デバッグＴＡＰ５８０を介して命令が入力され、コアを制御するのはこれら命令である。デバッグ中のコアはステップバイステップモードで作動する。デバッグＴＡＰは（ＪＡＤＩピンとして示されたＪＳＤＡＥＮピン上のアクセス制御信号入力、図４５におけるＪＴＡＧ ＡＣＣＥＳＳ ＤＩＳＡＢＬＥ ＩＮＰＵＴに応じて）コアを介しＣＰＵ１４にアクセスし、この方法で制御値をリセットすることもできる。
デバッグＴＡＰ５８０を介したＣＰ１４レジスタへのアクセスはアクセス制御信号ＪＳＤＡＥＮによって制御される。この信号はアクセスするための順序に特に許可すべき書き込みアクセスための順序にＪＳＤＡＥＮをハイにセットしなければならないようになっている。プロセッサ全体が検証中のボードステージの間では、ＪＳＤＡＥＮがハイにセットされ、デバッグは全システムでイネーブルされる。システムが一旦チェックされると、ＪＳＤＡＥＮピンをアースに結ぶことができる。このことは、安全モードでデバッグをイネーブルする制御値へのアクセスはデバッグＴＡＰ５８０を介しては利用できないことを意味する。一般に製造モードのプロセッサはアースに接続されたＪＳＤＡＥＮを有する。従って、制御値へのアクセスは命令メモリ５５０を介したソフトウェアルートを通してしか利用できない。このルートを介した安全スーパーバイザーモードまたは認証コードが与えられることを条件にする別のモードに制限される（図６８参照）。
デフォルトによりデバッグ（侵襲的かつ観測可能−トレース）は、非安全ワールドでしか利用できないことに留意すべきである。これらデバッグを安全ワールドで利用できるようにするには、制御値イネーブルビットをセットしなければならない。
この利点は非安全ワールドにおいて作動させるためにユーザーによって常にデバッグを開始できるということである。従って、デバッグではユーザーには一般に安全ワールドへのアクセスは利用できないが、この安全ワールドへのアクセスは制限されており、安全ワールドは利用できるようになる前にボード段階で完全に検証済みであるので、多くのケースではこのことは問題にならない。従って、多くのケースでは安全ワールドのデバッグは不要となることが予想される。必要であれば、ＣＰ１４を書き込むソフトウェアルートによりデバッグを開始できる。
図６８はデバッグ初期化の制御を略図で示している。この図では、コア６００の一部は記憶素子６０１（この素子は前に説明したようなＣＰ１５レジスタでよい）を含み、この阻止にはシステムが安全ワールド内にあるかないかを表示する安全ステータスビットＳが記憶される。コア６００はプロセッサが作動しているモード、例えばユーザーモードを表示するビットを含むレジスタ６０２と、コアでそのときに作動中のアプリケーションまたはスレッドを識別するコンテクスト識別子を提供するレジスタ６０３も含む。
ブレークポイントに達すると、レジスタ６１１上に記憶されているブレークポイントと、レジスタ６１２に記憶されているコアのアドレスとを比較するコンパレータ６１０は制御ロジック６２０に信号を送る。制御ロジック６２０は安全ステートＳ、モード６０２およびスレッド（コンテクスト識別子）６０３を見て、これと制御値およびレジスタＣＰ１４に記憶されている条件インジケータとを比較する。システムが安全ワールドで作動中でなければ、６３０にて「デバッグ進入」信号が出力される。しかしながら、システムが安全ワールドで作動中であれば、制御ロジック６２０はモード６０２を見る。ユーザーモードであればユーザーモードイネーブルビットおよびデバッグイネーブルビットがセットされているかをチェックする。そうであれば、スレッドアウェアビットが初期化されていないことを条件にデバッグが初期化される。上記の説明は制御値の階層的性質を示すものである。
図６８には、安全スーパーバイザーモード（この実施例ではプロセッサは製造段階にあり、ＪＳＤＡＥＮはアースに接続されている）のみからどのようにレジスタＣＰ１４に記憶されている制御値を制御するのか、ということと共に、モニタ制御のスレッドアウェア部分も略図で示されている。安全ユーザーモードからは認証コードを使って安全スーパーバイザーモードに入ることができ、ＣＰ１４内で制御値をセットできる。
デバッグがスレッドに対して可能であることをスレッドコンパレータ６４０が示していることを条件に、ブレークポイントに達したことをアドレスコンパレータ６１０が表示したときに、制御ロジック６２０は「デバッグ進入」信号を出力する。このことは、ＣＰ１５でスレッドアウェア初期化ビットがセットされることを仮定している。ブレークポイントの後でスレッドアウェア初期化ビットがセットされた場合、アドレスおよびコンテクストが、ブレークポイントおよび許可されたスレッドインジケータで表示されたそれぞれと一致した場合にしか、デバッグまたはトレースに入ることはできない。モニタ機能の開始後はコンテクスト識別子がコンパレータ６４０によって、許可されたスレッドとして検出されている間にしか、診断データの捕捉は続かない。実行中のアプリケーションが許可されているアプリケーションでないことをコンテクスト識別子が示した場合、診断データの捕捉は抑制される。
好ましい実施例では、粒度内にはある階層が存在することに留意すべきである。実際には安全デバッグまたはトレースイネーブルビットは頂部にあり、次に安全ユーザーモードイネーブルビットが続き、最後に安全スレッドアウェアイネーブルビットが入る。これについては図６９Ａおよび６９Ｂに示されている（以下参照）。
「デバッグおよびステータス制御」レジスタ（ＣＰ１４）内に保持された制御値はドメイン、モードおよび実行中のスレッドに従って安全デバッグの粒度を制御する。この安全デバッグ粒度は安全スーパーバイザーモードの頂部にあり、（デバッグおよびステータス制御）レジスタＣＰ１４が一旦構成されると、この安全デバッグ粒度はコアを「デバッグ進入」ステートにするよう、対応するブレークポイント、ウォッチポイントをプログラムするための安全スーパーバイザーモードまでである。
図６９Ａは侵襲的デバッグのための安全デバッグの粒度の概要を示す。リセット時のデフォルト値はグレー色で表示されている。
観測可能なデバッグに関するデバッグ粒度に対しては同じである。図６９Ｂはこの場合における安全デバッグ粒度の概要を示し、ここでもリセット時のデフォルト値はグレー色で表示されている。
侵襲的かつ観測可能なデバッグに対しては安全ユーザーモードデバッグイネーブルビットと安全スレッドアウェアデバッグイネーブルビットとを共通に使用することに留意されたい。
レジスタＣＰ１４にはスレッドアウェア初期化ビットが記憶され、このビットはアプリケーションによる粒度が必要であるかどうかを表示する。スレッドアウェアビットが初期化されている場合、アプリケーション識別子またはスレッド６０３がスレッドアウェア制御値内で表示されたものであるかどうかを制御ロジックが更にチェックする。そうである場合、デバッグが初期化される。ユーザーモードまたはデバッグイネーブルビットのいずれかがセットされていないか、またはスレッドアウェアビットがセットされており、実行中のアプリケーションがスレッドアウェア制御値で表示されたものではない場合、ブレークポイントは無視され、コアは行ってきたことを続行し、デバッグは初期化されない。
モニタ機能の初期化を制御するほかに、モニタ機能中の診断データの捕捉も同じ制御できる。これを行うために、コアは双方の制御値、すなわちレジスタＣＰ１４に記憶されたイネーブルビット、およびモニタ機能の実行中にこれらイネーブルビットが関係する条件を検討し続けなければならない。
図７０は実行中のモニタ機能の粒度を略図で示す。この場合、領域Ａは診断データを捕捉することが許可されている領域に関係し、領域Ｂは診断データを捕捉することができないことをＣＰ１４に記憶されている制御値が表示する領域に関係している。
従って、デバッグが作動中であり、プログラムが領域Ａで作動中であるとき、デバッグ中に診断データがステップバイステップの状態で出力される。作動が領域Ｂに切り換わり、この領域で診断データの捕捉が認められていないときは、デバッグはステップバイステップの状態では進行せず、むしろ自律的に進行し、データは捕捉されない。このことは、プログラムの動作が領域Ａに再び入り、この領域で診断データの捕捉が再びスタートし、デバッグがステップバイステップの状態で続行するまで続く。
上記実施例では、安全ドメインがイネーブルされない場合、ＳＭＩ命令は常にオートミックイベントとして見られ、診断データの捕捉が抑制される。
更にスレッドアウェア初期化ビットがセットされる場合、アプリケーションに対する作動中のモニタ機能の粒度を生じる。
観測可能なデバッグまたはトレースに関し、これはＥＴＭによって行われ、デバッグとは完全に独立している。トレースがイネーブルされると、ＥＴＭは通常どおり作動し、ディスエーブルされる、ＥＴＭは安全ワールド内のトレースまたは選択された粒度によっては安全ワールドの一部を隠す。ＥＴＭの捕捉およびトレースがイネーブルされたかったときの安全ドメインにおける診断データの捕捉を防止する１つの方法は、ＳビットがハイのときにＥＴＭを止めることである。このことは、ＳビットとＥＴＭＰＷＲＤＯＷＮ信号とを組み合わせることによって行うことができるので、コアが安全ワールドに入ったときに最後の値にＥＴＭ値を保持される。従って、ＥＴＭはＳＭＩ命令をトレースしなければならないので、コアが非安全ワールドにリターンするまでストールしなければならない。従って、ＥＴＭが非安全アクティビティを見るだけである。
次に、異なるモニタ機能の一部およびそれらの粒度の概要を示す。
ボードステージでの侵襲的デバッグ
ＪＳＤＡＥＮピンが接続されていないときのボードステージでは、ブートセッションをスタートさせる前のどの場所でも、デバッグをイネーブルする能力がある。同様に、安全スーパーバイザーモードにある場合、同様の権利を有する。
ホールトデバッグモードでデバッグを初期化する場合、すべてのレジスタにアクセス可能であり（非安全および安全レジスタバンク）、制御デバッグ専用ビットを除き、全メモリをダンプできる。
どのモードからも、かつどのドメインからも、デバッグホールトモードに入ることができる。ブレークポイントおよびウォッチポイントは安全メモリまたは非安全メモリでセットできる。デバッグステートではＭＣＲ命令を介してＳビットを変えるだけで安全ワールドに入ることができる。
安全例外が生じたときにデバッグモードに入ることができるので、次の新しいビットと共にベクトルトラップレジスタを拡張する。
ＳＭＩベクトルトラッピングイネーブル
安全データアボートベクトルトラッピングイネーブル
安全プリフェッチアボートベクトルトラッピングイネーブル
安全無定義ベクトルトラッピングイネーブル
モニタデバッグモードにおいて、どこをデバッグしてもよいと許可した場合、非安全ワールドでＳＭＩがコールされても、ステップバイステップのデバッグで安全ワールドに入ることができる。安全ドメインでブレークポイントが生じると、安全アボートハンドラーは安全レジスタバンクおよび安全メモリをダンプするように作動できる。
安全ワールドおよび非安全ワールドにおける２つのアボートハンドラーは、それらの情報をデバッガーアプリケーションに与え、（ＰＣを制御する関連するデバッグでの）デバッガーウィンドーは安全ワールドおよび非安全ワールドの双方におけるレジスタのステートを示すことができる。
図７１Ａはコアがモニタデバッグモードに構成されており、安全ワールドでデバッグがイネーブルされたときに何が生じるかを示している。図７１Ｂはコアがモニタデバッグモードに構成され、安全ワールドでデバッグがディスエーブルされたときに何が生じるかを示している。この後者のプロセスについては後述する。
製造ステージにおける侵襲的デバッグ
ＪＳＤＡＥＮが接続され、デバッグが非安全ワールドに制限されている製造ステージでは、安全スーパーバイザーが判断しないかぎり、図７１Ｂに示されたテーブルは何が生じるかを示す。この場合、ＳＭＩは常に自律命令と見なすべきであるので、デバッグステートに入る前に安全機能は常に終了される。
デバッグホールトモードに入ることは次の制限を受ける。
非安全ワールドだけでは外部デバッグリクエストまたは内部デバッグリクエストが考慮される。安全ワールドにある間にＥＤＢＧＲＱ（外部デバッグリクエスト）がアサートされた場合、安全機能が一旦終了すれば、コアはデバッグホールトモードに入り、非安全ワールドでコアがリターンされる。
安全メモリにブレークポイントまたはウォッチポイントをプログラムすることは効力がなく、プログラムされたアドレスが一致したときにコアは停止される。
ベクトルトラップレジスタ（このレジスタの細部については下記に示す）は、非安全例外にしか関係しておらず、効力を生じる前のすべての拡張トラッピングイネーブルビットについて説明する。
一旦ホールトデバッグモードになると、次の制限が適用される。
安全デバッグがイネーブルされなければ、安全ワールドに入るのにＳビットを変えることはできない。
デバッグが安全スーパーバイザーモードでしか許可されていない場合、モードビットを変えることはできない。
安全デバッグを制御する専用ビットを変えることはできない。
（システム速度アクセスが）ＳＭＩにロードされ、ＳＭＩが実行された場合、安全機能が完全に実行されたときにしか、コアはデバッグステートに再進入できない。
モニタデバッグモードでは、安全ワールドでモニタを行うことはできないので、安全アボートハンドラーはデバッグモニタプログラムをサポートしなくてもよい。非安全ワールドでは、ステップバイステップが可能であるが、ＳＭＩが実行されているときはいつも安全機能が完全に実行される。換言すれば、ＸＷＳＩの「ステップオーバー」しか認められないが、他のすべての命令では、「ステップイン」および「ステップオーバー」が可能である。従って、ＸＷＳＩは自律命令と見なされる。
一旦安全デバッグがディスエーブルされた場合、次の制限を有する。
モニタモードに入る前に：
非安全ワールドに限りブレークポイントおよびウォッチポイントを考慮する。ビットＳがセットされれば、ブレークポイント／ウォッチポイントをバイパスする。ブレークポイント／ウォッチポイントは安全メモリでは効果がないので、セキュリティの問題がないＭＣＲ／ＭＲＣ（ＣＰ１４）によってウォッチポイントユニットにもアクセスできることに留意されたい。
ＢＫＰＴは通常、ブレークポイントがセットされた命令を置き換えるのに使用される。このことは非安全モードに限り可能なＢＫＰＴ命令により、メモリにこの命令をオーバーライトすると仮定している。
ベクトルトラップレジスタは非安全例外にしか関係していない。前に説明したすべての拡張トラップイネーブルビットは効果がない。プロセッサが強制的にアンリカバブルステートにされるのを防止するには、データアボートおよびプリフェッチアボートイネーブルビットをディスエーブルすべきである。
ＪＴＡＧを介し、ホールトモードに関して同じ制限を有する（Ｓビットは変更できないなど）。
一旦モニタモード（非安全アボートモード）となると、
非安全アボートハンドラーは非安全ワールドをダンプでき、安全バンク状レジスタだけでなく安全メモリでビジビリティを有しない。
アトミックＳＭＩ命令により安全機能を実行する。
安全ワールドへの進入を強制するためにＳビットを変更できない。
安全スーパーバイザーモードでしかデバッグが許可されていない場合、モードビットを変更できない。
外部デバッグリクエスト（ＥＤＢＧＲＱ）が生じた場合、次のことに留意されたい。
非安全ワールドではコアはそのときの命令を終了し、即座に（ホールトモードで）デバッグステートに入る。
安全ワールドではコアはそのときの機能を終了し、コアが非安全ワールドに戻ったときにデバッグステートに入る。
新しいデバッグ条件とは、コアハードウェアにおけるある変更を意味する。Ｓビットは注意深く制御しなければならず、セキュリティ上の理由からスキャンチェーンに安全ビットを挿入してはならない。
要約すれば、デバッグにおいて、デバッグが安全スーパーバイザーモードでイネーブルされた場合に限りモードビットを変更できる。このことはデバッグにアクセスするものが安全ドメインにおいてシステムを変更することによって（ＴＢＬエントリーなどを変えることにより）すべての安全ワールドへアクセスすることを防止するものである。このように、各スレッドは自己のコードしかデバッグできない。安全カーネルはセーフ状態を維持すべきである。従って、コアが非安全ワールドで作動している場合にデバッグに入る際にモードビットは、前と同じように変更できるだけである。
本技術の実施例は新しいベクトルトラップレジスタを使用するものである。このレジスタ内のビットの１つはハイにセットされており、対応するベクトルがトリガーした場合、モニタはブレークポイントがあたかも対応する例外ベクトルからの命令フェッチでセットされたかのようにデバッグステートに入る。これらビットの挙動はデバッグ制御レジスタ内の「安全ワールド内のデバッグイネーブル」ビットの値に従って異なることがある。
この新しいベクトルトラップレジスタは次のビット：すなわちＤ＿ｓ＿アボート、Ｐ＿Ｓ＿アボート、Ｓ＿ｕｎｄｅｆ、ＳＭＩ、ＦＩＱ、ＩＲＱ、Ｕｎａｌｉｇｎｅｄ、Ｄ＿アボート、Ｐ＿アボート、ＳＷＩおよびＵｎｄｅｆを含む。
・Ｄ＿ｓ＿アボートビットはデバッグが安全ワールドでイネーブルされたとき、およびデバッグがホールトデバッグモードで構成されたときに限りセットすべきである。モニタデバッグモードではこのビットをセットしてはならない。安全ワールドにおけるデバッグがディスエーブルされると、このビットはどんな値であっても効果がない。
・Ｐ＿ｓ＿アボートビットはＤ＿ｓ＿アボートビットと同じである。
・Ｓ＿ｕｎｄｅｆビットはデバッグが安全ワールドでイネーブルされているときに限りセットすべきである。安全ワールドにおけるデバッグがディスエーブルされている場合、このビットはどんな値であっても効果がない。
・ＳＭＩビットは安全ワールドにおいてデバッグがイネーブルされているときに限りセットすべきである。安全ワールドにおけるデバッグがディスエーブルされている場合、このビットはどんな値であっても効果がない。
・ＦＩＱ、ＩＲＱ、Ｄ＿アボート、Ｐ＿アボート、ＳＷＩ、ｕｎｄｅｆビットは非安全例外に対応するので、これらビットは安全ワールドにおけるデバッグがディスエーブルされても有効である。モニタモードではＤ＿アボートおよびＰ＿アボートはハイにアサートすべきでない。
・リセットビット：リセットが生じたときに安全ワールドが入るので、このビットは安全ワールドにおけるデバッグがイネーブルされたときにしか有効でなく、そうでない場合は効果がない。
以上で本発明の特定の実施例について説明したが、本発明はこれら実施例だけに限定されるものでなく、本発明の範囲内で多数の変形および追加を行うことができることが明らかとなろう。例えば本発明の範囲から逸脱することなく、次の従属請求項の特徴事項と独立請求項の特徴事項とを種々組み合わせできる。
本発明の好ましい実施例に係わるデータ処理装置を略図で示すブロック図である。 非安全ドメインおよび安全ドメインで作動する異なるプログラムを略図で示す。 異なるセキュリティドメインに関連した処理モードを略図で示す。 処理モードとセキュリティドメインとの間の異なる関係を略図で示す。 処理モードとセキュリティドメインとの間の異なる関係を略図で示す。 処理モードに応じたプロセッサのレジスタバンクのプログラマーのモデルを示す。 安全ドメインおよび非安全ドメインのために別個のレジスタバンクを提供する一例を示す。 別個のモニタモードを介して行われるセキュリティドメイン間の切り換えと共に、複数の処理モードを略図で示す。 モード切り換えソフトウェアインターラプト命令を使用するセキュリティドメインの切り換えのためのシナリオを略図で示す。 非安全インターラプトリクエストおよび安全インターラプトリクエストをどのようにシステムで処理できるかの一例を略図で示す。 図１０に従った非安全インターラプトリクエスト処理の一例および安全インターラプトリクエスト処理の一例を略図で示す。 図１０に従った非安全インターラプトリクエスト処理の一例および安全インターラプトリクエスト処理の一例を略図で示す。 図１０に示された方式と比較された非安全インターラプトリクエスト信号および安全インターラプトリクエスト信号を取り扱うための別の方式を示す。 図１２に示された方式に従った非安全インターラプトリクエストおよび安全インターラプトリクエストを取り扱うためのシナリオ例を示す。 図１２に示された方式に従った非安全インターラプトリクエストおよび安全インターラプトリクエストを取り扱うためのシナリオ例を示す。 ベクトルインターラプトテーブルの一例である。 異なるセキュリティドメインに関連した多数のベクトルインターラプトテーブルを略図で示す。 例外制御レジスタを略図で示す。 セキュリティドメインの設定を変更するように処理ステータスレジスタを変更しようと試みる命令がどのように別個のモード変更例外を生じさせ、次にこの例外がモニタモードへの進入およびモニタプログラムの実行をトリガーするかを示すフローチャートである。 モニタモードにおけるタスクがインターラプトされる複数のモードで作動するプロセッサの制御スレッドを略図で示す。 複数のモードで作動中のプロセッサの制御の異なるスレッドを略図で示す。 インターラプトがモニタモードでイネーブルされる複数のモードで作動中のプロセッサの制御の別のスレッドを略図で示す。 別の実施例に従って安全ドメインと非安全ドメインとを切り換えるための異なる処理モードおよびシナリオの図を示す。 別の実施例に従って安全ドメインと非安全ドメインとを切り換えるための異なる処理モードおよびシナリオの図を示す。 別の実施例に従って安全ドメインと非安全ドメインとを切り換えるための異なる処理モードおよびシナリオの図を示す。 従来のＡＲＭコアに安全処理オプションを追加する原理を略図で示す。 安全および非安全ドメイン、およびリセットを有するプロセッサを略図で示す。 ソフトウェア疑似インターラプトを使用する、サスペンドされたオペレーティングシステムへ処理リクエストを送ることを略図で示す。 ソフトウェア疑似インターラプトを使用する、サスペンドされたオペレーティングシステムへ処理リクエストを送る別の例を略図で示す。 図２６および２７で発生されたタイプのソフトウェア疑似インターラプトの受信時に実行される処理を略図で示すフローチャートである。 非安全オペレーティングシステムによって行われる、可能なタスクの切り換えをトラックするために、安全オペレーティングシステムによるタスクのフォローを略図で示す。 非安全オペレーティングシステムによって行われる、可能なタスクの切り換えをトラックするために、安全オペレーティングシステムによるタスクのフォローを略図で示す。 図２９および３０の安全オペレーティングシステムでコールを受信した際に実行される処理を略図で示すフローチャートである。 異なるインターラプトを異なるオペレーティングシステムによって取り扱うことができる多数のオペレーティングシステムを有するシステムで生じ得る、インターラプトプライオリティの反転の問題を示す略図である。 図３２に示された問題を防止するためのスタブインターラプトハンドラーの使用を示す略図である。 異なるオペレーティングシステムを使ってサービスされるインターラプトにより、インターラプトできるか否かに応じて、異なるタイプおよびプライオリティのインターラプトをどのように取り扱うことができるかを略図で示す。 プロセッサがモニタモードで作動しているときに、モニタモード固有のプロセッサコンフィギュレーションデータにより、どのようにプロセッサコンフィギュレーションデータが無効にされるかを示す。 本発明の一実施例に従って安全ドメインと非安全ドメインとを切り換える際に、プロセッサコンフィギュレーションデータをどのように切り換えるかを示すフローチャートである。 メモリへのアクセスを制御するために本発明の一実施例で使用されるメモリ管理ロジックを示す図である。 メモリへのアクセスを制御するために使用される本発明の第２実施例のメモリ管理ロジックを示すブロック図である。 仮想アドレスを指定するメモリアクセスリクエストを処理するためのメモリ管理ロジック内で、本発明の実施例で実行されるプロセスを示すフローチャートである。 物理アドレスを指定するメモリアクセスリクエストを処理するためのメモリ管理ロジック内で、本発明の実施例で実行されるプロセスを示すフローチャートである。 メモリアクセスリクエストを発生するデバイスが非安全モードで作動中に、安全メモリ内の物理アドレスへのアクセスを、好ましい実施例のパーティションチェッカーがどのように防止するかを略図で示す。 本発明の好ましい実施例における非安全ページテーブルおよび安全ページテーブルの双方の使用を示す図である。 好ましい実施例のメイン変換ルックアサイドバッファ（ＴＬＢ）内で使用されるフラグの２つのフォームを示す図である。 本発明の一実施例におけるブートステージ後にメモリをどのように分割できるかを示す。 本発明の一実施例に係わるブート分割の実行後の、メモリ管理ユニットによる非安全メモリのマッピングを示す。 本発明の一実施例に従って安全アプリケーションが非安全アプリケーションとメモリを共用できるように、どのようにメモリの一部の権利を変更できるかを示す。 本発明の一実施例に係わるデータ処理装置の外部バスにデバイスをどのように接続できるかを示す。 本発明の第２実施例に従ってデバイスをどのように外部バスに結合できるかを示すブロック図である。 ページテーブルの単一のセットを使用する実施例における物理メモリの構造を示す。 中間アドレスを介して仮想−物理アドレス変換を実行するのに２つのＭＭＵを使用する構造を示す。 中間アドレスを介して仮想−物理アドレス変換を実行するのに２つのＭＭＵを使用する別の構造を示す。 安全ドメインおよび非安全ドメインの双方のための物理アドレス空間と中間アドレス空間との間の対応を例で示す。 第２ＭＭＵに関連したページテーブルの操作により、安全どのようにと非安全ドメインとの間のメモリ領域のスワッピングを示す。 仮想−物理アドレス変換を決定するためにメインＴＬＢにおける不一致が例外を呼び出す、単一のＭＭＵを使用した実行例を示す一実施例である。 図５３のＭＭＵのメインＴＬＢ内での不一致の発生時に発生される例外に作用するよう、プロセッサコアによって実行されるプロセスを示すフローチャートである。 個々のキャッシュラインに記憶されるデータが安全データであるか、または非安全であるかのいずれかに関する情報をキャッシュに提供する一実施例の、データ処理装置内に設けられた部品を示すブロック図である。 図５５に示されたメモリ管理ユニットの構造を示す。 非安全メモリアクセスリクエストを処理するための、図５５のデータ処理装置内で実行される処理を示すフローチャートである。 安全メモリアクセスリクエストを処理するための、図５５のデータ処理装置内で実行される処理を示すフローチャートである。 プロセッサで作動するアプリケーションおよび異なるモードに対するモニタ機能の可能な粒度を略図で示す。 異なるモニタ機能を開始する可能な方法を示す。 異なるモニタ機能の利用可能性を制御するための制御値の表を示す。 正のエッジでトリガーされるフリップフロップの図を示す。 スキャンチェーンセルを示す。 スキャンチェーンにおける複数のスキャンチェーンセルを示す。 デバッグＴＡＰコントローラを示す。 ＪＡＤＩ入力を有するデバッグＴＡＰコントローラを示す。 バイパスレジスタを有するスキャンチェーンセルを示す。 コア、スキャンチェーンおよびデバッグステータスおよび制御レジスタを含むプロセッサを略図で示す。 デバッグまたはトレースの初期化を制御する要素を略図で示す。 デバッグの粒度の概要を示す。 デバッグの粒度の概要を示す。 作動中のデバッグの粒度を略図で示す。 デバッグが安全ワールドでイネーブルされたときのモニタデバッグを示す。 デバッグが安全ワールドでイネーブルされていないときのモニタデバッグを示す。

Claims (47)

  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. 必要なときにトリガーされるドメインの変化により、非安全モードで作動する非安全例外ハンドラーまたは安全モードで作動する安全例外ハンドラーのいずれかをトリガーするように、前記１つ以上の例外条件をプログラム可能に構成できる請求項２４記載の方法。
  27. 専用安全例外信号入力および非安全例外信号入力を有する、請求項２４、２５および２６記載の方法。
  28. 安全例外と非安全例外との間で共用される例外信号入力と、安全例外ハンドラーまたは非安全例外ハンドラーとをトリガーするかどうかを制御するよう、前記例外信号入力と協働する別の入力信号とを有する、請求項２４、２５および２６記載の方法。
  29. 前記安全例外ハンドラーが前記安全モードで作動する安全オペレーティングシステムの一部である、請求項２４および２８のいずれかに記載の方法。
  30. 前記非安全例外ハンドラーが前記非安全モードで作動する非安全オペレーティングシステムの一部である、請求項２４〜２９のいずれかに記載の方法。
  31. 前記プロセッサがモニタモードでも作動でき、例外を取り扱うのに必要とされる安全モードと非安全モードとの間の切り替えが前記モニタモードを介して行われ、前記安全モードと前記非安全モードとの間の切り替えを管理するよう、前記プロセッサがモニタプログラムを実行するための前記モニタモードで少なくとも部分的に作動できる請求項２４〜３０のいずれかに記載の方法。
  32. 例外を取り扱うための安全モードと非安全モードとを切り替えるときに、前記モニタプログラムがプロセッサのステータスを定めるコンテクストデータをセーブし、レストアするように作動する請求項３１記載の方法。
  33. 前記プロセッサがレジスタバンクを含み、前記安全モードから前記非安全モードに切り替えるときに前記モニタプログラムが前記安全モードと前記非安全モードとの間で共用される前記レジスタバンクのうちの少なくとも一部をフラッシュするように作動し、よって前記レジスタバンク内に保持されていた非安全データが前記安全モードから前記モニタプログラムによって許可されるモード以外の前記非安全モードに移行できるようになっている請求項３１および３２のいずれかに記載の方法。
  34. 前記例外条件が、
    安全インターラプト信号例外、
    モード切り替えソフトウェアインターラプト信号、
    リセット例外、
    インターラプト信号例外、
    ソフトウェアインターラプト信号、
    無定義命令例外、
    プリフェッチアボート例外、
    データアボート例外、
    高速インターラプト信号例外
    のうちの１つ以上を含む、請求項２４〜３３のいずれかに記載の方法。
  35. 前記プロセッサが前記例外条件に関連し、前記例外条件のためのアクティーブ例外ベクトルテーブル内に記憶された例外ベクトル値に応じ、例外ハンドラーを選択するための例外条件に応答自在であり、
    前記アクティーブ例外ベクトルテーブルが複数の例外ベクトルテーブルのうちの１つである請求項２４記載の方法。
  36. 前記複数の例外ベクトルテーブルが前記安全モードで選択可能な安全例外ベクトルテーブルと、前記非安全モードで選択可能な非安全例外ベクトルとを含む請求項３５記載の方法。
  37. 前記プロセッサがモニタモードでも作動でき、前記複数の例外ベクトルの安全モードと非安全モードとの切り替えが前記モニタモードを介して実行される請求項３５および３６のいずれかに記載の方法。
  38. 前記複数の例外ベクトルテーブルがモニタモードの例外ベクトルテーブルを含む請求項３７記載の方法。
  39. 前記モニタモード例外ベクトルテーブルにより前記例外のうちのどの例外を取り扱うべきかを指定する１つ以上のパラメータに前記プロセッサが応答自在である請求項３７記載の方法。
  40. 前記モニタモードのベクトルテーブルが前記例外条件の前記アクティーブベクトルテーブルであることを前記１つ以上のパラメータが指定しない場合、前記安全ベクトルテーブルが前記安全モードにおける前記アクティーブベクトルテーブルであり、前記非安全ベクトルテーブルが前記非安全モードにおける前記アクティーブベクトルテーブルである請求項３６および３９のいずれかに記載の方法。
  41. 前記パラメータのうちの少なくとも１つが例外トラップマスク内に記憶されている請求項３９記載の方法。
  42. 前記プロセッサが前記モニタモードであるときに前記例外制御レジスタが書き込み自在であり、前記プロセッサが前記非安全ドメイン内にない場合、前記例外トラップマスクレジスタが書き込み不能である請求項４１記載の方法。
  43. 前記プロセッサが安全モードであるときに前記安全例外ベクトルテーブルが書き込み自在であり、前記プロセッサが非安全モードとなっているときに前記安全例外ベクトルテーブルが書き込み不能である請求項３６記載の方法。
  44. 安全オペレーティングシステムの一部である安全例外ハンドラーが前記安全モード使用される請求項３６記載の方法。
  45. 非安全オペレーティングシステムの一部である非安全例外ハンドラーが前記非安全モード使用される請求項３６記載の方法。
  46. 複数のベクトルテーブルベースアドレスポインタレジスタを備え、各レジスタが前記複数の例外ベクトルテーブルのうちの対応する１つのためのそれぞれのベースアドレス値を記憶する請求項３５〜４５のうちのいずれかに記載の方法。
  47. 請求項２４〜４６のいずれかに記載の方法に従いデータ処理装置を制御するようになっているコンピュータプログラムを有するコンピュータプログラム製品。
JP2004570294A 2002-11-18 2003-10-27 安全処理システムにおける例外タイプ Expired - Lifetime JP4447471B2 (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GB0226905A GB0226905D0 (en) 2002-11-18 2002-11-18 Exception tyres within a secure processing system
GB0226902A GB0226902D0 (en) 2002-11-18 2002-11-18 Exception vector tables in a secure system
GB0303449A GB0303449D0 (en) 2002-11-18 2003-02-14 Task following between multiple operating systems
PCT/GB2003/004621 WO2004046916A2 (en) 2002-11-18 2003-10-27 Exception types within a secure processing system

Publications (2)

Publication Number Publication Date
JP2006506752A true JP2006506752A (ja) 2006-02-23
JP4447471B2 JP4447471B2 (ja) 2010-04-07

Family

ID=32329548

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004570294A Expired - Lifetime JP4447471B2 (ja) 2002-11-18 2003-10-27 安全処理システムにおける例外タイプ

Country Status (8)

Country Link
US (2) US7661105B2 (ja)
EP (1) EP1563376B1 (ja)
JP (1) JP4447471B2 (ja)
KR (1) KR100941104B1 (ja)
AU (1) AU2003278347A1 (ja)
DE (1) DE60304602T2 (ja)
GB (1) GB2410348B (ja)
WO (1) WO2004046916A2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015530672A (ja) * 2012-10-01 2015-10-15 エイアールエム リミテッド 安全なドメイン及びより安全性の低いドメインを有するデータ処理装置における例外処理

Families Citing this family (62)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2005115083A (ru) * 2002-11-18 2006-01-20 Арм Лимитед (Gb) Переключение процессора между защищенным и незащищенным режимами
US7383587B2 (en) * 2002-11-18 2008-06-03 Arm Limited Exception handling control in a secure processing system
GB2410348B (en) * 2002-11-18 2005-12-07 Advanced Risc Mach Ltd Exception types within a secure processing system
CN1886712B (zh) * 2003-11-28 2010-09-08 松下电器产业株式会社 数据处理装置
JP4447977B2 (ja) * 2004-06-30 2010-04-07 富士通マイクロエレクトロニクス株式会社 セキュアプロセッサ、およびセキュアプロセッサ用プログラム。
KR100664922B1 (ko) * 2004-08-21 2007-01-04 삼성전자주식회사 자바 보안 기능 개선 방법
US7480755B2 (en) * 2004-12-08 2009-01-20 Hewlett-Packard Development Company, L.P. Trap mode register
CN101233525A (zh) * 2005-05-26 2008-07-30 松下电器产业株式会社 数据处理装置
CN101189586B (zh) * 2005-06-01 2011-06-15 松下电器产业株式会社 计算机系统及程序生成装置
FR2907930B1 (fr) * 2006-10-27 2009-02-13 Viaccess Sa Procede de detection d'une utilisation anormale d'un processeur de securite.
GB2448149B (en) * 2007-04-03 2011-05-18 Advanced Risc Mach Ltd Protected function calling
GB2448151B (en) * 2007-04-03 2011-05-04 Advanced Risc Mach Ltd Memory domain based security control within data processing systems
JP5049185B2 (ja) * 2007-04-19 2012-10-17 パナソニック株式会社 情報セキュリティ装置、セキュリティシステム及び入力情報漏洩防止方法
US8209550B2 (en) * 2007-04-20 2012-06-26 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for protecting SIMLock information in an electronic device
US7865675B2 (en) 2007-12-06 2011-01-04 Arm Limited Controlling cleaning of data values within a hardware accelerator
US8775824B2 (en) 2008-01-02 2014-07-08 Arm Limited Protecting the security of secure data sent from a central processor for processing by a further processing device
US8332660B2 (en) 2008-01-02 2012-12-11 Arm Limited Providing secure services to a non-secure application
US8127131B2 (en) * 2008-04-10 2012-02-28 Telefonaktiebolaget Lm Ericsson (Publ) System and method for efficient security domain translation and data transfer
US8555015B2 (en) * 2008-10-23 2013-10-08 Maxim Integrated Products, Inc. Multi-layer content protecting microcontroller
US8321926B1 (en) * 2008-12-02 2012-11-27 Lockheed Martin Corporation System and method of protecting a system that includes unprotected computer devices
KR100897930B1 (ko) * 2009-02-05 2009-05-14 주식회사 피앤피시큐어 보안장치 장애로부터 네트워크의 안정된 통신상태를 보장하는 통신시스템
JP5414057B2 (ja) * 2009-05-22 2014-02-12 ルネサスエレクトロニクス株式会社 マイクロコンピュータ
US8789153B2 (en) * 2010-01-27 2014-07-22 Authentify, Inc. Method for secure user and transaction authentication and risk management
US8789189B2 (en) * 2010-06-24 2014-07-22 NeurallQ, Inc. System and method for sampling forensic data of unauthorized activities using executability states
US9746519B2 (en) * 2011-03-25 2017-08-29 Nxp B.V. Circuit for securing scan chain data
WO2012160760A1 (ja) 2011-05-25 2012-11-29 パナソニック株式会社 情報処理装置および情報処理方法
US9262340B1 (en) 2011-12-29 2016-02-16 Cypress Semiconductor Corporation Privileged mode methods and circuits for processor systems
US20130305388A1 (en) * 2012-05-10 2013-11-14 Qualcomm Incorporated Link status based content protection buffers
US8910307B2 (en) 2012-05-10 2014-12-09 Qualcomm Incorporated Hardware enforced output security settings
US8938796B2 (en) 2012-09-20 2015-01-20 Paul Case, SR. Case secure computer architecture
US9886595B2 (en) 2012-12-07 2018-02-06 Samsung Electronics Co., Ltd. Priority-based application execution method and apparatus of data processing device
US9183161B2 (en) * 2012-12-28 2015-11-10 Intel Corporation Apparatus and method for page walk extension for enhanced security checks
CN104813279B (zh) 2012-12-28 2018-12-18 英特尔公司 用于减少具有步幅式访问模式的向量寄存器中的元素的指令
US8613090B1 (en) * 2013-02-21 2013-12-17 Atheer, Inc. Method for processing a secure system manager
US8990921B2 (en) 2013-02-21 2015-03-24 Atheer, Inc. Apparatus for processing with a secure system manager
US9330035B2 (en) * 2013-05-23 2016-05-03 Arm Limited Method and apparatus for interrupt handling
US10061940B2 (en) 2013-07-09 2018-08-28 Andes Technology Corporation Secure protection processor and method including comparing an instruction security attribute of an instruction and a security attribute of an operational event
US20150052616A1 (en) * 2013-08-14 2015-02-19 L-3 Communications Corporation Protected mode for securing computing devices
US9594704B1 (en) 2013-12-17 2017-03-14 Google Inc. User mode interrupts
US9495311B1 (en) * 2013-12-17 2016-11-15 Google Inc. Red zone avoidance for user mode interrupts
US9225897B1 (en) 2014-07-07 2015-12-29 Snapchat, Inc. Apparatus and method for supplying content aware photo filters
GB2530050B (en) * 2014-09-10 2021-07-21 Advanced Risc Mach Ltd Debugging in a data processing apparatus
US10496410B2 (en) * 2014-12-23 2019-12-03 Intel Corporation Instruction and logic for suppression of hardware prefetchers
GB2540937B (en) * 2015-07-30 2019-04-03 Advanced Risc Mach Ltd Graphics processing systems
US10083134B2 (en) 2015-11-28 2018-09-25 International Business Machines Corporation Configurable processor interrupts for allowing an application to independently handle interrupts
US20170185400A1 (en) * 2015-12-23 2017-06-29 Intel Corporation Mode-specific endbranch for control flow termination
KR20170105353A (ko) * 2016-03-09 2017-09-19 삼성전자주식회사 전자장치 및 그 제어방법
CN105825128B (zh) * 2016-03-15 2020-05-19 华为技术有限公司 一种数据输入方法、装置及用户设备
US20180275731A1 (en) * 2017-03-21 2018-09-27 Hewlett Packard Enterprise Development Lp Processor reset vectors
DE102018212686A1 (de) * 2018-07-30 2020-01-30 Siemens Aktiengesellschaft Verfahren zum Betreiben einer Rechenanlage
US10915457B2 (en) 2018-08-30 2021-02-09 Micron Technology, Inc. Memory access control through permissions specified in page table entries for execution domains
US11500665B2 (en) 2018-08-30 2022-11-15 Micron Technology, Inc. Dynamic configuration of a computer processor based on the presence of a hypervisor
US10942863B2 (en) 2018-08-30 2021-03-09 Micron Technology, Inc. Security configurations in page table entries for execution domains using a sandbox application operation
US11481241B2 (en) * 2018-08-30 2022-10-25 Micron Technology, Inc. Virtual machine register in a computer processor
US11914726B2 (en) 2018-08-30 2024-02-27 Micron Technology, Inc. Access control for processor registers based on execution domains
US10915465B2 (en) 2018-08-30 2021-02-09 Micron Technology, Inc. Memory configured to store predefined set of domain registers for instructions being executed in computer processors
US11182507B2 (en) * 2018-08-30 2021-11-23 Micron Technology, Inc. Domain crossing in executing instructions in computer processors
GB2577878B (en) * 2018-10-08 2020-11-11 Advanced Risc Mach Ltd Transition disable indicator
US11392698B2 (en) * 2019-03-15 2022-07-19 Intel Corporation Active side-channel attack prevention
TWI751962B (zh) * 2019-04-07 2022-01-01 新唐科技股份有限公司 安全裝置、安全方法、安全系統以及安全設備
CN113486355B (zh) * 2021-06-29 2023-03-14 北京紫光展锐通信技术有限公司 一种信息保存装置、方法、通信装置、芯片及其模组设备
GB2622801A (en) * 2022-09-28 2024-04-03 Advanced Risc Mach Ltd Exception control

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS60225943A (ja) * 1984-04-25 1985-11-11 Hitachi Ltd 例外割込み処理方式
JPH0193830A (ja) * 1987-10-05 1989-04-12 Nec Corp 仮想計算機システムにおける割り込み制御方式
JPH1069393A (ja) * 1996-06-19 1998-03-10 Hokkaido Nippon Denki Software Kk 仮想計算機エミュレータ、仮想計算機エミュレート方法 および仮想計算機エミュレートプログラムを記録した記録 媒体
JP2001175486A (ja) * 1999-12-21 2001-06-29 Hitachi Ltd 計算機システム
JP2002501248A (ja) * 1998-01-21 2002-01-15 ノキア モービル フォーンズ リミティド 埋込みシステム
JP2002182560A (ja) * 2000-12-12 2002-06-26 Hitachi Ltd 暗号処理機能を備えた情報サーバ装置
JP2004531788A (ja) * 2000-12-21 2004-10-14 コネクティクス コーポレイション エミュレートされるコンピューティング環境におけるプロセッサ制御の論理的置換のためのシステムおよび方法

Family Cites Families (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5027273A (en) * 1985-04-10 1991-06-25 Microsoft Corporation Method and operating system for executing programs in a multi-mode microprocessor
US4825358A (en) * 1985-04-10 1989-04-25 Microsoft Corporation Method and operating system for executing programs in a multi-mode microprocessor
ATE134779T1 (de) * 1987-06-12 1996-03-15 Bmc Software Inc Supervisorverfahren für ein rechnerbetriebssystem
US5122470A (en) 1988-07-05 1992-06-16 Banes Albert J Floating cell culture device and method
US5237700A (en) * 1990-03-21 1993-08-17 Advanced Micro Devices, Inc. Exception handling processor for handling first and second level exceptions with reduced exception latency
JPH06236284A (ja) * 1991-10-21 1994-08-23 Intel Corp コンピュータシステム処理状態を保存及び復元する方法及びコンピュータシステム
US5479616A (en) 1992-04-03 1995-12-26 Cyrix Corporation Exception handling for prefetched instruction bytes using valid bits to identify instructions that will cause an exception
US5745770A (en) * 1993-12-27 1998-04-28 Intel Corporation Method and apparatus for servicing simultaneous I/O trap and debug traps in a microprocessor
US5815701A (en) 1995-06-29 1998-09-29 Philips Electronics North America Corporation Computer method and apparatus which maintains context switching speed with a large number of registers and which improves interrupt processing time
US5684948A (en) * 1995-09-01 1997-11-04 National Semiconductor Corporation Memory management circuit which provides simulated privilege levels
US5974440A (en) * 1996-03-25 1999-10-26 Texas Instruments Incorporated Microprocessor with circuits, systems, and methods for interrupt handling during virtual task operation
US5778070A (en) * 1996-06-28 1998-07-07 Intel Corporation Method and apparatus for protecting flash memory
US5881282A (en) * 1996-12-10 1999-03-09 Intel Corporation Controlling ill-behaved computer add-on device through a virtual execution mode
US5826084A (en) * 1997-03-25 1998-10-20 Texas Instruments Incorporated Microprocessor with circuits, systems, and methods for selectively bypassing external interrupts past the monitor program during virtual program operation
US6557104B2 (en) * 1997-05-02 2003-04-29 Phoenix Technologies Ltd. Method and apparatus for secure processing of cryptographic keys
US6604123B1 (en) 1999-02-23 2003-08-05 Lucent Technologies Inc. Operating system transfer of control and parameter manipulation using portals
JP3659062B2 (ja) 1999-05-21 2005-06-15 株式会社日立製作所 計算機システム
KR100317237B1 (ko) * 1999-10-01 2001-12-22 윤종용 유사 벡터 방식의 인터럽트 컨트롤러 및 그것의 인터럽트 처리 방법
EP1162536A1 (en) 2000-06-09 2001-12-12 Hitachi, Ltd. Multiple operating system control method
US20030031235A1 (en) * 2001-07-18 2003-02-13 Cyberlane Inc. PCMCIA CDMA data modem with test code selection switch
US7487339B2 (en) * 2001-10-12 2009-02-03 Mips Technologies, Inc. Method and apparatus for binding shadow registers to vectored interrupts
US20030126520A1 (en) * 2001-12-31 2003-07-03 Globespanvirata System and method for separating exception vectors in a multiprocessor data processing system
EP1331539B1 (en) * 2002-01-16 2016-09-28 Texas Instruments France Secure mode for processors supporting MMU and interrupts
US7165135B1 (en) * 2002-04-18 2007-01-16 Advanced Micro Devices, Inc. Method and apparatus for controlling interrupts in a secure execution mode-capable processor
US7370193B2 (en) * 2002-04-27 2008-05-06 Tong Shao Computing system being able to quickly switch between an internal and an external networks and a method thereof
US7171539B2 (en) * 2002-11-18 2007-01-30 Arm Limited Apparatus and method for controlling access to a memory
US7117284B2 (en) * 2002-11-18 2006-10-03 Arm Limited Vectored interrupt control within a system having a secure domain and a non-secure domain
JP4302641B2 (ja) * 2002-11-18 2009-07-29 エイアールエム リミテッド デバイスによるメモリへのアクセスの制御
WO2004046925A1 (en) * 2002-11-18 2004-06-03 Arm Limited Security mode switching via an exception vector
GB2410348B (en) * 2002-11-18 2005-12-07 Advanced Risc Mach Ltd Exception types within a secure processing system
US7383587B2 (en) * 2002-11-18 2008-06-03 Arm Limited Exception handling control in a secure processing system
US7539853B2 (en) * 2002-11-18 2009-05-26 Arm Limited Handling interrupts in data processing of data in which only a portion of a function has been processed
EP1563380B1 (en) * 2002-11-18 2006-07-19 ARM Limited Virtual to physical memory address mapping within a system having a secure domain and a non-secure domain
RU2005115083A (ru) * 2002-11-18 2006-01-20 Арм Лимитед (Gb) Переключение процессора между защищенным и незащищенным режимами
US7322042B2 (en) * 2003-02-07 2008-01-22 Broadon Communications Corp. Secure and backward-compatible processor and secure software execution thereon

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS60225943A (ja) * 1984-04-25 1985-11-11 Hitachi Ltd 例外割込み処理方式
JPH0193830A (ja) * 1987-10-05 1989-04-12 Nec Corp 仮想計算機システムにおける割り込み制御方式
JPH1069393A (ja) * 1996-06-19 1998-03-10 Hokkaido Nippon Denki Software Kk 仮想計算機エミュレータ、仮想計算機エミュレート方法 および仮想計算機エミュレートプログラムを記録した記録 媒体
JP2002501248A (ja) * 1998-01-21 2002-01-15 ノキア モービル フォーンズ リミティド 埋込みシステム
JP2001175486A (ja) * 1999-12-21 2001-06-29 Hitachi Ltd 計算機システム
JP2002182560A (ja) * 2000-12-12 2002-06-26 Hitachi Ltd 暗号処理機能を備えた情報サーバ装置
JP2004531788A (ja) * 2000-12-21 2004-10-14 コネクティクス コーポレイション エミュレートされるコンピューティング環境におけるプロセッサ制御の論理的置換のためのシステムおよび方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015530672A (ja) * 2012-10-01 2015-10-15 エイアールエム リミテッド 安全なドメイン及びより安全性の低いドメインを有するデータ処理装置における例外処理

Also Published As

Publication number Publication date
EP1563376A2 (en) 2005-08-17
US7949866B2 (en) 2011-05-24
GB0504192D0 (en) 2005-04-06
US20040158736A1 (en) 2004-08-12
GB2410348B (en) 2005-12-07
US20090259846A1 (en) 2009-10-15
EP1563376B1 (en) 2006-04-12
AU2003278347A1 (en) 2004-06-15
DE60304602T2 (de) 2006-12-28
WO2004046916A3 (en) 2004-10-21
KR20050085014A (ko) 2005-08-29
KR100941104B1 (ko) 2010-02-10
WO2004046916A2 (en) 2004-06-03
AU2003278347A8 (en) 2004-06-15
GB2410348A (en) 2005-07-27
US7661105B2 (en) 2010-02-09
JP4447471B2 (ja) 2010-04-07
DE60304602D1 (de) 2006-05-24

Similar Documents

Publication Publication Date Title
JP4447471B2 (ja) 安全処理システムにおける例外タイプ
JP4302641B2 (ja) デバイスによるメモリへのアクセスの制御
JP4220476B2 (ja) 安全ドメインおよび非安全ドメインを有するシステム内での仮想−物理メモリアドレスマッピング
JP4423206B2 (ja) 安全モードと非安全モードとを切り換えるプロセッサ
JP4302493B2 (ja) データ処理装置内のメモリへアクセスするための技術
JP4302492B2 (ja) メモリへのアクセスを管理するための装置および方法
JP4424973B2 (ja) マルチドメインプロセッサのためのモニタ制御
JP4302494B2 (ja) データ処理装置内のメモリへアクセスするための技術
JP4423012B2 (ja) マルチドメインプロセッサのための診断データ捕捉制御
JP4299107B2 (ja) サスペンドされたオペレーティングシステムへデータ処理リクエストを送る方法
US7117284B2 (en) Vectored interrupt control within a system having a secure domain and a non-secure domain
US7171539B2 (en) Apparatus and method for controlling access to a memory
US7305712B2 (en) Security mode switching via an exception vector
IL167597A (en) Virtual to physical memory address mapping within a system having a secure domain and a non-secure domain
JP2004171568A (ja) 多数のオペレーティングシステムを使用するデータ処理システムにおける多数の割り込みの取り扱い
IL168336A (en) Control of access to a memory by a device
JP4299108B2 (ja) 多数のオペレーティングシステムの間のタスクの追従
IL167188A (en) Exception types within a secure processing system

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060124

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080722

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20081022

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20081029

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20081125

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20090403

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090803

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20090903

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100112

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100120

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130129

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4447471

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130129

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term