(57)【要約】【課題】セキュアなエラーハンドリングを提供すること。【解決手段】いくつかの実施形態が、オペレーティングシステムとプラットフォームとを含む。上記プラットフォームは、エラーレジスタを有するプロセッサを含む。上記オペレーティングシステムは、上記エラーレジスタに、上記プラットフォームを介してのみ、セキュアな方式で（例えば、プラットフォームファームウェアを用いて）書き込むことができる。他の実施形態が説明され、請求される。【選択図】図１
2015195065.tif 000002
【特許請求の範囲】
【請求項１】
オペレーティングシステムと、
プロセッサを含むプラットフォームであり、前記プロセッサはエラーレジスタを含む、プラットフォームと、を備え、
前記オペレーティングシステムは、前記プラットフォームを介して前記エラーレジスタにセキュアな方式でのみ書き込むことができ、前記エラーレジスタは、前記プラットフォームを介して有効にされる及び／又は無効にされる、装置。
【請求項２】
前記プラットフォームはさらに、システム管理モード機能を含み、前記オペレーティングシステムは、前記システム管理モード機能を介して前記エラーレジスタにセキュアな方式でのみ書き込むことができる、請求項１に記載の装置。
【請求項３】
前記システム管理モード機能は、基本入出力システムに含まれる、請求項２に記載の装置。
【請求項４】
前記オペレーティングシステムは、プラットフォームファームウェアを介して前記エラーレジスタにセキュアな方式でのみ書き込むことができる、請求項１に記載の装置。
【請求項５】
前記エラーレジスタは、マシンチェックアーキテクチャレジスタ及びエラーシグナル送信レジスタのうち少なくとも１つを含む、請求項１に記載の装置。
【請求項６】
前記エラーレジスタは、前記プラットフォームによってのみ有効にされる及び／又は無効にされるマシンチェックアーキテクチャレジスタである、請求項１に記載の装置。
【請求項７】
前記プラットフォームは、前記オペレーティングシステムと前記プロセッサとの間のエラーシグナル送信を制御する、請求項１に記載の装置。
【請求項８】
前記プラットフォームは、前記オペレーティングシステムと前記プロセッサとの間のエラーシグナル送信を有効にする及び／又は無効にする、請求項１に記載の装置。
【請求項９】
前記エラーレジスタは、前記プラットフォームにより制御されるマシンチェックアーキテクチャレジスタであり、前記プロセッサはさらに、前記プラットフォームにより制御されるエラーシグナル送信レジスタを含む、請求項１に記載の装置。
【請求項１０】
前記オペレーティングシステムは、前記プラットフォームを介して前記エラーレジスタに書き込む、請求項１に記載の装置。
【請求項１１】
エラー注入が、前記プラットフォームを介して実施される、請求項１に記載の装置。
【請求項１２】
オペレーティングシステムから、プロセッサに含まれるエラーレジスタに、プラットフォームを介してセキュアな方式で書き込むステップと、
前記プラットフォームを介して前記エラーレジスタを有効にする及び／又は無効にするステップと、
を含む方法。
【請求項１３】
前記オペレーティングシステムから、前記プロセッサに含まれる前記エラーレジスタに、前記プラットフォームに含まれるシステム管理モード機能を介してセキュアな方式で書き込むステップ、をさらに含む請求項１２に記載の方法。
【請求項１４】
前記システム管理モード機能は、前記プラットフォームの基本入出力システムに含まれる、請求項１３に記載の方法。
【請求項１５】
前記オペレーティングシステムから、前記エラーレジスタに、プラットフォームファームウェアを介してセキュアな方式で書き込むステップ、をさらに含む請求項１２に記載の方法。
【請求項１６】
前記エラーレジスタは、マシンチェックアーキテクチャレジスタ及びエラーシグナル送信レジスタのうち少なくとも１つを含む、請求項１２に記載の方法。
【請求項１７】
前記エラーレジスタはマシンチェックアーキテクチャレジスタであり、前記プラットフォームのみが前記マシンチェックアーキテクチャレジスタを有効にする及び／又は無効にするステップ、をさらに含む請求項１２に記載の方法。
【請求項１８】
前記プラットフォームを介して、前記オペレーティングシステムと前記プロセッサとの間のエラーシグナル送信を制御するステップ、をさらに含む請求項１２に記載の方法。
【請求項１９】
前記プラットフォームを介して、前記オペレーティングシステムと前記プロセッサとの間のエラーシグナル送信を有効にする及び／又は無効にするステップ、をさらに含む請求項１２に記載の方法。
【請求項２０】
前記エラーレジスタはマシンチェックアーキテクチャレジスタであり、前記プラットフォームが前記マシンチェックアーキテクチャレジスタと前記プロセッサ内のエラーシグナル送信レジスタとを制御するステップ、をさらに含む請求項１２に記載の方法。
【請求項２１】
前記オペレーティングシステムから、前記エラーレジスタに、前記プラットフォームを介して書き込むステップ、をさらに含む請求項１２に記載の方法。
【請求項２２】
前記プラットフォームを介して１又は複数のエラーを注入するステップ、をさらに含む請求項１２に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は概してセキュアなエラーハンドリングに関する。
【背景技術】
【０００２】
サーバシステム（特に、拡張可能な、スケーラブルな、ミッションクリティカルなシステム）は、より良好な信頼性（Reliability）、可用性（Availability）及び保守性（Serviceability）（ＲＡＳ）のエクスペリエンスのためのエラー検出、エラー訂正、エラーリカバリ及びエラーロギングの能力を備えている。
【０００３】
マシンチェックアーキテクチャ（ＭＣＡ）が、インテルＸｅｏｎ（登録商標）プロセッサにおいて用いられて、プロセッサ関連のエラーを上位レイヤソフトウェアにレポートする。マシンチェックアーキテクチャは、典型的には、コア、キャッシュなどのプロセッサコンポーネント関連のエラーに限定される。しかしながら、メモリコントローラ、ＰＣＩｅルートコンプレックスの、Ｘｅｏｎ（登録商標）プロセッサソケットへの統合とともに、マシンチェックアーキテクチャのスコープは、すべてのこれらのコンポーネントからのエラーハンドリング及びＲＡＳイベントを包含するようにレポートされている。マシンチェックアーキテクチャにおける別の進化が、エラーリカバリであり、これにおいて、プロセッサ／プラットフォームの観点から訂正できないエラーが、リカバリのため、オペレーティングシステム（ＯＳ）又は仮想マシンモニタ（ＶＭＭ）に提供される。
【０００４】
上記のイノベーションを考慮すると、プラットフォーム上のエラーハンドリング、エラーレポーティング及びエラーリカバリがオペレーティングシステム（ＯＳ）及び／又は仮想マシンモニタ（ＶＭＭ）によって予期されるとおりに動作することを、オペレーティングシステムベンダ（ＯＳＶ）及び／又は仮想マシンベンダ（ＶＭＶ）において包括的に検証することが重要である。これは、ＲＡＳ／エラーハンドリングコードカバレッジと呼ばれる。上記コードカバレッジにより、ＯＳ及び／又はＶＭＭは、エラーハンドリング、リカバリ及びＲＡＳ機構がエンドツーエンドで実際に動作していることを保証することが可能となる。これには、種々のプロセッサコア、プロセッサキャッシュ、メモリ、入出力装置、システム相互接続などにおけるエラーなどの、種々のタイプのエラーを生成することを含む。エラーハンドリング能力を検証するために、エラー注入能力を、製造プラットフォーム上での実行時にＯＳ及び／又はＶＭＭが利用可能であることが必要となる。ハードウェアにおいて、種々のエラーサブシステム上にすべてのエラーケースについての実際のエラー注入メカニズムを実装することは、非常に複雑となり、非常に高価となる。さらに、エラー注入メカニズム自体は、システムのセキュリティに対するリスクをもたらすべきではない。
【０００５】
エラーハンドリングコードは、現状、限定されたセットの実際のエラー注入を用いて検証されている。実施のエラー注入メカニズムは、１回に１つだけのエラーを注入することを可能にする。したがって、エラーハンドリングコードは、限定されたエラーコード実行カバレッジしか得られない。ひいては、多くの手作業のコードレビューを行ってさらなるコードカバレッジパスを決定することが必要となる。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
いくつかの従前の実装は、リング０コードからＭＣＡバンクに書き込むことを、別のリング０コードアクセス可能レジスタに書き込むことによって、可能にしている。これは、セキュリティホールである。ＭＣＡバンク書き込み有効化レジスタがリング０ドメイン内にあるため、任意のリング０コードが、ＭＣＡバンク書き込み能力を有効にしに行き、ＭＣＡバンクに書き込み、無用のエラーケースを引き起こす可能性がある。さらに、従前の実装は、マシンチェックアーキテクチャ（ＭＣＡ）及び訂正マシンチェックエラー割り込み（Corrected  Machine  Check  Error  Interrupt）（ＣＭＣＩ）などのエラーのシグナル送信を提供せず、上記実装の機構の有用性を限定している。
【０００７】
本願発明者らはさらに、現在の解決法がＭＣＡバンク書き込み有効化／無効化能力の保護又はエラーシグナル送信（ＭＣＡ／ＣＭＣＩ）生成有効化／無効化の保護を提供しないことを、識別している。
【課題を解決するための手段】
【０００８】
いくつかの実施形態が、オペレーティングシステムと、プロセッサを含むプラットフォームとを含む。プロセッサは、エラーレジスタを含む。オペレーティングシステムは、プラットフォームを介してセキュアな方式でのみエラーレジスタに書き込むことができる。
【図面の簡単な説明】
【０００９】
本発明は、以下に与えられる詳細説明と本発明のいくつかの実施形態の添付図面とからさらに十分に理解されるものである。しかしながら、上記詳細説明及び添付図面は、説明される特定の実施形態に本発明を限定するものと解されるべきではなく、単に説明及び理解のためのものである。
【図１】本発明のいくつかの実施形態に従うシステムを示す。
【図２】本発明のいくつかの実施形態に従うフローを示す。
【図３】本発明のいくつかの実施形態に従うフローを示す。
【図４】本発明のいくつかの実施形態に従うフローを示す。
【発明を実施するための形態】
【００１０】
本発明のいくつかの実施形態は、セキュアなエラーハンドリングに関する。
【００１１】
いくつかの実施形態において、マシンチェックエラーコードカバレッジのためのエラー注入が、実施するのにセキュアかつ効率的である（例えば、インテルサーバプロセッサ及び／又はインテルＸｅｏｎ（登録商標）プロセッサのためのいくつかの実施形態において）。
【００１２】
いくつかの実施形態は、オペレーティングシステムと、システム管理モード（System  Management  Mode）（ＳＭＭ）制御（例えば、及び／又はＳＭＭ機能及び／又はＳＭＭファームウェア）を含む基本入出力システムと、エラーレジスタを含むプロセッサとを含む。オペレーティングシステムは、システム管理モード制御、機能、ファームウェアなどを介してのみエラーレジスタに書き込むことができる。
【００１３】
いくつかの実施形態は、オペレーティングシステムと、プロセッサを含むプラットフォームとを含む。プロセッサは、エラーレジスタを含む。オペレーティングシステムは、プラットフォームを介してセキュアな方式でのみエラーレジスタに書き込むことができる。いくつかの実施形態において、オペレーティングシステムは、プラットフォームファームウェアを介してセキュアな方式でのみエラーレジスタに書き込むことができる。
【００１４】
図１は、いくつかの実施形態に従うシステム１００を示す。いくつかの実施形態において、システム１００は、プラットフォーム１０２と、オペレーティングシステム／仮想マシンモニタ（又はリング０コード）１０４と、エラーハンドラ１０６と、アプリケーション／ゲストオペレーティングシステム１０８と、アプリケーション／ゲストオペレーティングシステム１１０とを含む。いくつかの実施形態において、プラットフォーム１０２は、プロセッサ（及び／又はプロセッサハードウェア）１２２と、システム基本入出力システム（ＢＩＯＳ）１２４と、エラー注入ソフトウェア抽象化１２６とを含む。いくつかの実施形態において、システムＢＩＯＳ１２４は、システム管理モード（ＳＭＭ）コード／データ１２８（及び／又はＳＭＭ制御、ＳＭＭ機能、ＳＭＭコントローラなど）を含む。いくつかの実施形態において、ＳＭＭコード／データは、ファームウェアで実装される。いくつかの実施形態において、プロセッサ１２２は、マシンチェックアーキテクチャ（ＭＣＡ）バンク書き込み能力有効／無効レジスタ１３２と、エラーシグナル送信（error  signaling）マシンチェックアーキテクチャ（ＭＣＡ）／訂正マシンチェックエラー割り込み（ＣＭＣＩ）有効／無効レジスタ１３４とを含む。
【００１５】
いくつかの実施形態において、プロセッサ１２２は、ＭＣＡメモリバンクへの書き込みを有効にする又は無効にすることができる。いくつかの実施形態において、プロセッサ１２２は、モデル固有レジスタ（Model  Specific  Register）（ＭＳＲ）又はコンフィギュレーション空間レジスタ（Configuration  Space  Register）（ＣＳＲ）としてエラーをシグナル送信することができる。いくつかの実施形態に従い、プロセッサ１２２内の有効／無効レジスタ１３２及び１３４は、システム管理モード（ＳＭＭ）からのみアクセス可能である。このことは、オペレーティングシステム（ＯＳ）コードが、信頼されたＳＭＭコードを直接経由することなしに、上記機構を有効にすることは決してできないことを、確かにする。
【００１６】
いくつかの実施形態において、ＭＣＡバンクへの書き込みは、リング０コード１０４から実施される。いくつかの実施形態において、リング０コード１０４は、ＭＣＡ／ＣＭＣＩをシグナル送信することができる。いくつかの実施形態において、ＭＣＡバンク書き込み能力は、システム管理モード（ＳＭＭ）からのみ有効にされ及び／又は無効にされ、上記機構の利用についてのセキュリティを提供する。いくつかの実施形態において、エラーシグナル送信（ＭＣＡ／ＣＭＣＩ）は、ＳＭＭからのみ有効にされ及び／又は無効にされ、上記機構の利用についてのセキュリティを提供する。いくつかの実施形態において、オペレーティングシステム（ＯＳ）は、コードカバレッジのためのセキュアなエラー注入の可用性を検出する。いくつかの実施形態において、ＢＩＯＳ／ＯＳインタフェースとして、ＯＳに対するエラー注入機能のソフトウェア抽象化が実装される。
【００１７】
図２は、いくつかの実施形態に従うフロー２００を示す。いくつかの実施形態において、フロー２００は、ＢＩＯＳ／ＯＳインタフェースを公開するＢＩＯＳフローを示す。いくつかの実施形態において、フロー２００は、ブート処理中のＢＩＯＳフローコードを示し、ここでは、プラットフォーム及び／又はプロセッサ内で利用可能な機構が識別され、ＢＩＯＳ／ＯＳインタフェース（ＡＣＰＩテーブル／メソッド、すなわち、アドバンスド・コンフィグレーション・アンド・パワー・インターフェイス・テーブル／メソッド）が公開される。いくつかの実施形態において、フローは、２０２において始まり、ここでは、ＢＩＯＳセットアップオプションがエラー注入について有効にされているかどうかに関して、決定が行われる。ＢＩＯＳセットアップオプションがエラー注入について有効にされていないことが２０２において決定された場合、２０４において、エラー注入のためのＢＩＯＳ／ＯＳインタフェースは公開されず、フローは２０６に移動してＯＳブート処理を継続する。ＢＩＯＳセットアップオプションがエラー注入について有効にされていることが２０２において決定された場合、２０８において、プロセッサがコードカバレッジエラー注入能力をサポートするかどうかに関して、決定が行われる。プロセッサがコードカバレッジエラー注入能力をサポートしないことが２０８において決定された場合、フローは２０６に移動してＯＳブート処理を継続する。プロセッサがコードカバレッジエラー注入能力をサポートすることが２０８において決定された場合、２１０において、ＳＭＭインフラストラクチャが、エラーハンドリングコードカバレッジエラー注入インタフェース（Error  Handling  Code  Coverage  Error  Injection  Interface）を処理するようにセットアップされる。次いで２１２において、エラー注入のためのＢＩＯＳ／ＯＳインタフェースが公開され、次いで、フローは２０６に移動してＯＳブート処理を継続する。
【００１８】
図３は、いくつかの実施形態に従うフロー３００を示す。いくつかの実施形態において、フロー３００は、エラーログ／エラーシグナル送信ハードウェアの書き込みを有効化／無効化するシステム管理モード（ＳＭＭ）コードフローを示す。いくつかの実施形態において、フロー３００は、ＯＳがＢＩＯＳ／ＯＳインタフェースを呼び出してＭＣＡバンク書き込み能力及びエラーシグナル送信能力を有効／無効にするときに、ＳＭＭコードにより行われる動作を示す。
【００１９】
いくつかの実施形態において、フロー３００は、３０２においてシステム管理割り込み（System  Management  Interrupt）（ＳＭＩ）モジュールにおいて始まる。３０４において、上記ＳＭＩがエラーハンドリングコードカバレッジをもたらすＳＭＩであるかどうかに関して、決定が行われる。上記ＳＭＩがエラーハンドリングコードカバレッジをもたらすＳＭＩではないことが３０４において決定された場合、３０６において、通常のＳＭＩフローが継続される。上記ＳＭＩがエラーハンドリングコードカバレッジをもたらすＳＭＩであることが３０４において決定された場合、３０８において、エラーログハードウェア有効化及び／又は無効化が所望されるかどうかに関して、決定が行われる。エラーログハードウェア有効化及び／又は無効化が３０８において所望されない場合、フローは３１０に移動し、ここでは、エラーシグナル送信有効化／無効化を決定するように、決定がなされる。エラーログハードウェア有効化／無効化が３０８において所望される場合、３１２において、エラーログハードウェア（ＭＣＡバンク）書き込み能力の有効化／無効化が行われ、フローが、要求された動作を３１０に移動する前に設定することができない場合、エラーで応答する。エラーシグナル送信有効化／無効化が３１０においてまったく決定されない場合、３０６において通常のＳＭＩフローが継続される。エラーシグナル送信有効化／無効化が３１０において決定された場合、３１４において、エラーシグナル送信能力の有効化／無効化が行われ、３０６において通常のＳＭＩフローが継続される。
【００２０】
図４は、いくつかの実施形態に従うフロー４００を示す。いくつかの実施形態において、フロー４００は、エラーを注入するためのＯＳフローを示す。いくつかの実施形態において、フロー４００は、ＯＳがどのようにＢＩＯＳ／ＯＳインタフェースを実行し（consumes）、いくつかの実施形態に従うシステムにエラーを注入するのかを示す。
【００２１】
フロー４００は、４０２において始まり、ここでは、ＢＩＯＳ／ＯＳインタフェースがエラーハンドリングコードカバレッジエラー注入に利用可能であるのかどうかに関して、決定が行われる。４０２においてＢＩＯＳ／ＯＳインタフェースがエラーハンドリングコードカバレッジエラー注入に利用可能でない場合、４０４において、プラットフォームがエラー注入能力をサポートしない（例えば、ＭＣＡバンクエラー注入能力をサポートしない）という決定が行われる。４０２においてＢＩＯＳ／ＯＳインタフェースがエラーハンドリングコードカバレッジエラー注入に利用可能である場合、４０６において、注入すべきエラーが決定される（例えば、エラーログリストを構築することによる）。次いで４０８において、ＭＣＡバンク書き込み能力が、ＢＩＯＳインタフェース（及び／又はＡＣＰＩインタフェース）を呼び出すことによって有効にされる。４１０において、ＭＣＡバンク書き込み能力が成功したかどうかに関して、決定が行われる。成功しなかった場合、４１２においてエラー注入は失敗する。成功した場合、４１４において、エラーがリストから選択される。４１６において、エラーを設定すべきスレッドが選択され、エラーを設定すべきＭＣＡバンクが選択される。４１８において、エラーログデータが書き込まれる。４２０において、現在のＭＣＡバンクが読み出され、読み出されたものが書き込まれた値に一致するかどうかに関して、決定が行われる。一致しなかった場合、フローが４１８に戻される前に、４２２において、現在のＭＣＡバンクがクリアされ、別のＭＣＡバンクが選択され、すべてのバンクが使い尽くされている場合はエラーが生じる。４２０において読み出されたものが書き込まれた値に一致する場合、４２４において、エラーリスト内のすべてのエラーが設定されたかどうかに関して、決定が行われる。設定されていない場合、フローは４１４に戻される。設定されている場合、４２６において、ＭＣＡバンクの非ゼロの書き込み能力が、ＢＩＯＳインタフェース（及び／又はＡＣＰＩインタフェース）を呼び出すことによって無効にされる。これは、成功したエラー登録セットアップを示し、４２８において、エラーがシグナル送信される。次いで４３０において、ＭＣＡ／ＣＭＣＩシグナル送信能力が、ＢＩＯＳインタフェース（及び／又はＡＣＰＩインタフェース）を呼び出すことによって有効にされる。次いで４３２において、ＣＭＣＩがシグナル送信されるべきである場合、要求されたスレッドが選択される。次いで４３４において、ＭＣＡ又はＣＭＣＩがシグナル送信される（例えば、ＢＩＯＳインタフェース動作シーケンスを呼び出すことによる）。次いで４３６において、ＭＣＡ／ＣＭＣＩシグナル送信能力が無効にされる。
【００２２】
基本入出力システム（ＢＩＯＳ）の実行時コンテキストが、システム管理割り込み（ＳＭＩ）であり、この実行コンテキストの下で、ＢＩＯＳはＭＣＡをシグナル送信することができない場合がある。この実装は、ＭＣＡバンク書き込み（エラーレジスタ書き込み）及びＭＣＡ／ＣＭＣＩシグナル送信制御レジスタがＳＭＩ制御下にあることを可能にすることを備える。上記実装はさらに、いったんＭＣＡ／ＣＭＣＩシグナル送信が有効にされると、ＯＳ／ＶＭＭが書き込みをしてＭＣＡ又はＣＭＣＩのシグナル送信を引き起こすことを可能にする。これらの詳細はＢＩＯＳインタフェースによって抽象化され、したがってＯＳ／ＶＭＭは実装詳細を知る必要がなくなる。
【００２３】
いくつかの実施形態において、信頼されたプラットフォーム実行（ＴＸＴ）が有効にされる場合、ＳＭＩ自体が信頼された計算境界（trusted  compute  boundary）（ＴＣＢ）の範囲内に入るまで、ＭＣＡバンクレジスタに書き込むための制御レジスタとＭＣＡ／ＣＭＣＩシグナル送信を有効にするための制御レジスタとが無効にされる。これは、上記のような信頼された環境で実施される他の実施形態を可能にする。
【００２４】
いくつかの実施形態において、ＯＳ／ドライバが、コードカバレッジのためのエラー注入を行う準備ができていることを決定する。次いで、ＯＳ／ドライバは、ＢＩＯＳインタフェースを呼び出してＭＣＡバンク書き込み能力を有効にする。この時点で、ＯＳ／ドライバ（リング０コード）は、ＭＣＡバンクに書き込む。エラーハンドリングコードカバレッジ検証ドライバが、検証において関心のあるエラーを決定し、種々のＭＣＡバンク及びスレッドのためのエラーログ値を構築する。検証ドライバは、選択されたＭＣＡバンク及びスレッドにエラーログを書き込む。次いで、エラータイプに基づいて、検証ドライバは、例えば、ＣＭＣＩ又はＭＣＡをシグナル送信する。いったんエラーがシグナル送信されると、割り込みがエラーハンドラを起動させ、エラーハンドラは、実際のエラーを受信したのかを考え、標準的にエラーを処理する。エラーハンドリングコードパスを検証するためにエラーハンドラコードを変更する必要はない。いくつかの実施形態に従うエラー注入が、１のエラーをシグナル送信する前に複数のＭＣＡバンク及びスレッド上のエラーが作成される方式で、実施される。この方式において、同時的なエラーシナリオを作成することができる。
【００２５】
いくつかの実施形態に従い、ＭＣＡバンク有効化及び／又は無効化とエラーシグナル送信制御とはシステム管理モード（ＳＭＭ）の範囲内にあり、エラー注入中にデータがまったく公開されないため、セキュリティホールはまったく公開されない。
【００２６】
いくつかの実施形態において、種々のタイプのエラーが、エラーをシグナル送信する前に、種々のＭＣＡバンク、種々の中央処理ユニット（ＣＰＵ）若しくはプロセッサスレッド、及び／又は種々のＣＰＵ若しくはプロセッサソケット上に設定される。このことは、種々のエラーハンドラコードフローの実行を可能にし、従前には可能ではなかった種々のエラーシナリオを作成する。これらのタイプのシナリオの作成は、エラーハンドリングフローにおける様々なコーナーケースの検証を可能にする。
【００２７】
いくつかの実施形態において、ＭＣＡバンク書き込み及びエラーシグナル送信の機構は、システム管理モード（ＳＭＭ）からのみ許容される。ＳＭＭアーキテクチャは、ＳＭＭコード又はデータにＳＭＭの外部からアクセスすることができなくなるため、プラットフォームに対してセキュリティを提供する。このことは、マルウェア又は信頼されていないコードがＳＭＭに入り込み、上記の機構を有効にすることが、決してないことを確かにする。
【００２８】
いくつかの従前の実装は、リング０コードからＭＣＡバンクを書き込むことを、別のリング０コードアクセス可能レジスタに書き込むことによって、許容する。これは、セキュリティホールである。ＭＣＡバンク書き込み有効化レジスタがリング０ドメイン内にあるため、任意のリング０コードが、ＭＣＡバンク書き込み能力を有効にしに行き、ＭＣＡバンクに書き込み、無用のエラーケースを引き起こす可能性がある。さらに、従前の実装は、ＭＣＡ及びＣＭＣＩなどのエラーのシグナル送信を提供せず、上記実装の機構の有用性を限定している。
【００２９】
現在の解決法は、ＭＣＡバンク書き込み有効化／無効化能力の保護又はエラーシグナル送信（ＭＣＡ／ＣＭＣＩ）生成有効化／無効化の保護を提供していない。いくつかの実施形態に従い、保護が、ＭＣＡバンク書き込み能力及びエラーシグナル送信能力の有効化について提供される。いくつかの実施形態において、ＭＣＡバンク書き込み能力及びエラーシグナル送信能力の有効化／無効化についてのソフトウェア抽象化が実装される。いくつかの実施形態において、ハードウェアが変化した場合、エラーハンドリングコードカバレッジエラー注入は変更する必要がない。
【００３０】
いくつかの実施形態において、ＭＣＡバンク書き込みの有効化及び／又は無効化が実装される（エラーロギングハードウェア書き込み）。いくつかの実施形態において、エラーシグナル送信ハードウェアの利用が保護される。いくつかの実施形態において、ソフトウェアに対するハードウェア実装の抽象化が実装され、したがってハードウェア実装レジスタ又は配置が変化した場合にソフトウェアの変更は必要なくなる。
【００３１】
いくつかの実施形態において、オペレーティングシステムベンダ（ＯＳＶ）がエラーハンドリングフローを検証することができ、プロセッサ上のＲＡＳのＯＳ実装（例えば、サーバプロセッサ及び／又はインテルＸｅｏｎ（登録商標）プロセッサ）がより良好な品質を有することになる。このことは、ＲＡＳ／エラーハンドリングを有効化するコストを削減する。いくつかの実施形態に従い、任意のエラーの組み合わせを、ＭＣＡバンクに投入する（populated）ことができ、ＯＳは、シリコンが利用可能となる前でさえ、セキュアな方式で将来の機構のエラーハンドリングを検証することが可能となる。
【００３２】
本明細書において、いくつかの実施形態を、特定の方式で実装されるものとして説明してきたが、いくつかの実施形態では、上記の特定の実装は、必要とされるものではない。例えば、本明細書において、いくつかの実施形態を、システム管理モード（ＳＭＭ）コード／データ、ＳＭＭ機能、ＳＭＭ制御、ＳＭＭコントローラなどを含むものとして説明してきた。しかしながら、他の実施形態は、ＳＭＭを実装することを必要としない。さらに、いくつかの実施形態において、ＳＭＭ、ＢＩＯＳなどのいくつかの機能を、ファームウェア、ソフトウェア及び／又はハードウェアで実装することができる。いくつかの実施形態において、エラーレジスタを有効化／無効化するため、及び／又はエラーを検出、訂正、リカバリ、ロギングなどするためのプラットフォーム制御が、例えばオペレーティングシステム（ＯＳ）及び／又は仮想マシンモニタ（ＶＭＭ）を用いて上記の機能を制御するよりはセキュアな方式で実施される。
【００３３】
いくつかの実施形態が特定の実装を参照して説明されたが、他の実装がいくつかの実施形態に従って可能である。さらに、図面に示された及び／又は本明細書に記載された回路素子又は他の機構の配置及び／又は順序は、図示及び記載された特定の方法で配置される必要はない。多くの他の配置がいくつかの実施形態に従って可能である。
【００３４】
図に示される各システムにおいて、いくつかの場合の要素が、同一の参照番号又は異なる参照番号を各々有して、表された要素が異なる及び／又は類似するであろうことを示唆し得る。しかしながら、要素は、種々の実装を有し、本明細書に図示又は記載されたシステムのうち一部又はすべてと共に動作するほど十分な適応性を有し得る。図面に示される種々の要素は、同一である又は異なる可能性がある。どの要素が第１の要素として参照され、どれが第２の要素と呼ばれるのかは、任意である。
【００３５】
本願説明と特許請求の範囲とにおいて、用語「結合される」及び「接続される」とその派生語とが用いられる場合がある。上記の用語は互いに対して同義語である意図はないことを、理解されたい。むしろ、特定の実施形態において、「接続される」を用いて複数の要素が直接的な物理的又は電気的接触を有することを示す場合がある。「結合される」は、複数の要素が直接的な物理的又は電気的接触を有することを、意味する場合がある。しかしながら、「結合される」はさらに、複数の要素が互いに直接的な接触を有さず、しかしながらなお互いに協働又は相互作用することを意味する場合がある。
【００３６】
本説明において、また一般的に、アルゴリズムは、所望の結果につながる動作又は操作についての自己矛盾のないシーケンスと見なされる。上記には、物理量の物理的な操作を含む。一般に、必ずしも必要ないが、上記の量は、保存され、転送され、組み合わせされ、比較され、及びその他の操作をされることが可能な、電気的又は磁気的な信号の形式をとる。主に一般的な用法の理由で、こうした信号をビット、値、要素、シンボル、文字、用語、数字又は類似のものと呼ぶことは、時に便利であることが証明されている。しかしながら、上記及び類似の用語のすべてが、適切な物理量に関連付けられるべきであり、単に上記の量に適用される便利なラベルであることを、理解されたい。
【００３７】
いくつかの実施形態は、ハードウェア、ファームウェア及びソフトウェアのうちの１つ又はそれらの組み合わせで実装することができる。いくつかの実施形態は、さらに、機械読み取り可能媒体に記憶された命令として実装することができ、上記機械読み取り可能媒体は、コンピューティングプラットフォームによって読み出され、実行されて、本明細書に記載の動作を実行することができる。機械読み取り可能媒体には、機械（例えば、コンピュータ）により読取可能な形式の情報を記憶する又は送信する任意のメカニズムを含むことができる。例えば、機械読み取り可能媒体には、読取専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリ装置、電気的、光学的、音響的又は他の形式の伝播信号（例えば、搬送波、赤外線信号、デジタル信号、信号を送受信するインタフェースなど）及びその他を含むことができる。
【００３８】
実施形態は、本発明の実装又は例示である。本明細書における「ある実施形態」「１つの実施形態」「いくつかの実施形態」又は「他の実施形態」という言葉は、その実施形態と関連して説明された特定の機構、構造又は特徴が、本発明の少なくともいくつかの実施形態に含まれ、しかしながら必ずしもすべての実施形態には含まれないことを、意味する。「ある実施形態」「１つの実施形態」又は「いくつかの実施形態」の種々の出現は、必ずしもすべて同一の実施形態を参照するものではない。
【００３９】
本願において記載及び図示されたすべてのコンポーネント、機構、構造、特徴などが、特定の１又は複数の実施形態に含まれる必要はない。例えば、あるコンポーネント、機構、構造又は特徴が含まれる「場合がある」「可能性がある」「ことができる」又は「であろう」ことを本明細書が述べる場合、上記の特定のコンポーネント、機構、構造又は特徴が含まれることは必要とはされない。本明細書又は請求項が「１の（“a”又は“an”）」要素に言及する場合、上記は、要素が１つしか存在しないことを意味するものではない。本明細書又は請求項が「１のさらなる（“an  additional”）」要素に言及する場合、上記は、１より多くのさらなる要素が存在することを除外しない。
【００４０】
本願においてフロー図及び／又は状態図を用いて実施形態を説明している場合があるが、本発明は、本願におけるこうした図、又は対応する記載に限定されない。例えば、フローは、本願において図示及び記載されたとおりの、各々の図示されたボックス若しくは状態を通って、又は正確に同一の順序で、移動する必要はない。
【００４１】
本発明は、本明細書に列挙された特定の詳細に限定されない。実際に、本開示の便益を有する当業者は、前述の説明及び図面から多くの他の変形を本発明の範囲内で行うことができることを、十分理解するであろう。したがって、本発明の範囲を定義するものは、いかなる補正をも含む別記の特許請求の範囲である。
【００４２】
[関連出願]
本出願は、“INJECTING  ERROR  AND/OR  MIGRATING  MEMORY  IN  A  COMPUTING  SYSTEM”と題され、２０１０年１２月１７日に申請された米国特許出願番号第１２／９７１８６８号に関連する。この出願は、実際のエラー注入の実施を説明する。
【図１】
2015195065.tif 000003
【図２】
2015195065.tif 000004
【図３】
2015195065.tif 000005
【図４】
2015195065.tif 000006
【外国語明細書】
2015195065000001.pdf