JP7306964B2 - 仮想化システムおよび動作管理方法 - Google Patents

Description

本発明は、高い堅牢性を必要とするネットワーク対応車載システム、自動運転、及びＡＤＡＳ（Advanced Driver Assistance System：先進運転支援システム）等の車載システムに適用される仮想化システムに関する。

仮想化技術とは、コンピュータシステムを構成する様々なリソース（ＣＰＵ、メモリ、ストレージ、ＯＳ等）を物理的な構成とは独立に論理的な単位に編成する技術であって、複数のリソースを統合して一つに見せたり、一つのリソースを分割して複数に見せかけたりすることが可能になる。このような仮想化技術を用いたシステム環境下では、ハードウェア上にソフトウェアで構築された仮想マシンが起動し、その中でゲストＯＳが動作する。仮想マシンを構築する方式として、コンピュータ上でハイパーバイザと呼ばれる専用のソフトウェアを起動し、ハイパーバイザにより構築された仮想マシン上でＯＳを起動する方式がある。ハイパーバイザはコンピュータのハードウェア・リソース（以下、リソース）の割り当てを示す割当情報を管理し、仮想的な物理環境を創出する。仮想化システムはＳｏＣ（System on Chip）上で実現される。

仮想環境下で動作するゲストＯＳに対してリソースを割り当て管理するために、各ゲストＯＳには識別のためのＯＳＩＤが付与される。ＯＳＩＤを固定せずに柔軟にソフトウェアで設定可能とした場合、ソフトウェアが攻撃を受けてＯＳＩＤが勝手に書き換えられる可能性があり、このような攻撃からＯＳＩＤを防ぐ方法としてハードウェアでＯＳＩＤを隠蔽する方法がある。

図８は、仮想化システムにおけるソフトウェア攻撃からＯＳＩＤを隠蔽するためのシステム構成を示した図である。セキュアＣＰＵで稼働するハイパーバイザ（８ｃ）、非セキュアＣＰＵで稼働するゲストＯＳ１（８ａ）とゲストＯＳ２（８ｄ）、ゲストＯＳ１（８ａ）のＯＳＩＤが格納されるレジスタ（８ｂ）、ゲストＯＳ２（８ｄ）のＯＳＩＤが格納されるレジスタ（８ｅ）、ゲートウェイ（８ｆ）、リソースにアクセスするＩＰ０（Intellectual Property）（８ｉ）、ＩＰ１（８ｊ）、ＩＰ０（８ｉ）及びＩＰ１（８ｊ）を使用するゲストＯＳのＯＳＩＤを管理するレジスタ（８ｇ、８ｈ）、ＩＰ０（８ｉ）及びＩＰ１（８ｊ）が管理するリソース（メモリ等）（不図示）で構成されている。

図９を用いて、ソフトウェア攻撃からＯＳＩＤを隠蔽するための動作フローを説明する。ゲストＯＳ１（８ａ）に割り当てられるＯＳＩＤ（＝Ａ）は、仮想化システムを実現するＳｏＣの起動直後にハイパーバイザ８ｃがリソースマップ等を基にして生成して、スーパー特権を持つゲートウェイ（８ｆ）に保持させる（Ｓ９０１）。次に、ゲストＯＳ１（８ａ）を稼働させるＣＰＵ０のレジスタ（８ｂ）（他のゲストＯＳが直接参照できないレジスタとする）に、該当ＯＳＩＤをスーパー特権で書き込みを行う。ゲストＯＳ１（８ａ）は非セキュアＣＰＵで稼働する（Ｓ９０２）。ゲストＯＳ１（８ａ）が割り当てられたＯＳＩＤを使用してゲートウェイ（８ｆ）を介して、リソースへアクセスする（Ｓ９０３）。ゲートウェイ（８ｆ）はリソースにアクセス許可されているＯＳＩＤを格納しているレジスタ（８ｇ、８ｈ）により、アクセス要求のあったＯＳＩＤとレジスタに格納されたＯＳＩＤを比較して、一致している場合はアクセスを許可する。不一致の場合はアクセスを許可しない（Ｓ９０４）。もしゲストＯＳ１（８ａ）がリソースを使用しなくなった場合やアクセスするリソースを変更したい場合はハイパーバイザ（８ｃ）へ申請して、リソースの開放や再割り当てをしてもらうようにする（Ｓ９０５）。

以上のような動作により、ＯＳＩＤはスーパー特権を有するゲートウェイ（８ｆ）のレジスタ（８ｇ、８ｈ）と、他のゲストＯＳより参照ができないゲストＯＳ側のレジスタ（８ｂ、８ｅ）に保持することにより、ハードウェアとしてＯＳＩＤを隠蔽し、仮想化システムにおいて高いセキュリティ環境を実現している。

しかしながら、従来技術には以下のような問題点があった。一旦ＯＳＩＤが割り当てられると、生成されたＯＳＩＤは変更されることなくシステムの稼働中使用し続けられる。このような場合、例えば悪意のあるゲストＯＳが割り当てられていないリソースにアクセスしようとして、ＯＳＩＤを順次変更しながら総当たり的にアクセスすることでアクセスに成功する可能性がある。この課題を解決するためには、定期的にＯＳＩＤを変更することが考えられるが、ＯＳＩＤの変更はシステム停止中に行う必要があるため、一度停止して、再設定した後再開するという手順を踏むことになる。しかしながらこの方法では、短時間で頻繁にＯＳＩＤを変更するようなことは実質的には不可能である。さらに、変更期間を長く確保するようにしたとしても、ソフトウェアの介在が必要となり、性能の低下につながってしまうことが懸念される。

本発明の課題は、仮想化システムにおいて、非セキュアＣＰＵにおいて稼働するゲストＯＳからリソースへのアクセスを制限する機能について、ソフトウェア処理の負荷を軽減しながら、高いセキュリティを実現できるようにすることである。

複数のＯＳとリソースとの紐づけを行うＯＳＩＤ管理を行うハイパーバイザと、ハイパーバイザから初期値を受け取り、紐づけを行うＯＳＩＤを設定するＯＳＩＤマネージャをゲストＯＳ及びリソースの各々に有する仮想化システムにおいて、初期値の設定後一定時間経過した後にＯＳＩＤマネージャにより作成された新しいＯＳＩＤをゲストＯＳとリソースに更新するように要求する。これにより、ゲストＯＳとリソースのＯＳＩＤを同時に更新することが可能になる。

一実施の形態に係る仮想化システムでは、ＯＳＩＤマネージャが定期的にＯＳＩＤを作成し、ゲストＯＳとリソースとに作成したＯＳＩＤを再設定することにより、従来固定値で運用していたＯＳＩＤをシステムが動作中に更新することが可能になる。また、ＯＳＩＤマネージャ内の更新制御部７によって同時に更新することで、更新のずれにより発生するミスマッチを防止しながら確実にＯＳＩＤを更新することが可能となる。これにより，悪意あるＯＳによる総当たり的な攻撃を受けた場合に仮にＯＳＩＤが盗まれた場合であっても、ＯＳＩＤはすぐに更新されるため、盗まれたＯＳＩＤは無効となり、堅牢性の高いシステムを実現できる。

図１は、第一の実施の形態に係る仮想化システムの構成図である。 図２は、第一の実施の形態に係る仮想化システムにおけるＯＳＩＤの更新フローである。 図３は、第二の実施の形態に係る仮想化システムの構成図である。 図４は、第二の実施の形態に係る仮想化システムにおけるＯＳＩＤの更新フローである。 図５は、第三の実施の形態に係る仮想化システムの構成図である。 図６は、第三の実施の形態に係る仮想化システムにおけるＯＳＩＤの更新フローである。 図７は、変形例２に係るＯＳＩＤの構成図である。 図８は、従来の仮想化システム構成図である。 図９は、従来の仮想化システムにおけるＯＳＩＤの管理フローである。

（第一の実施形態）
以下、第一の実施形態に係る仮想化システムについて、図面を参照して詳細に説明する。なお、明細書及び図面において、同一の構成要件または対応する構成要件には、同一の符号を付し、重複する説明は省略する。また、図面では、説明の便宜上、構成を省略または簡略化している場合もある。また、実施の形態と各変形例との少なくとも一部は、互いに任意に組み合わされてもよい。

（仮想化システムの全体構成）
図１は、第一の実施形態に係る仮想化システムの全体構成を示すブロックである。仮想化システムは複数のゲストＯＳを仮想環境上で動作させる。仮想化システムは、セキュアＣＰＵ（中央処理装置）で稼働するハイパーバイザ（１ｃ）、非セキュアＣＰＵで稼働するゲストＯＳ1（１ａ）とゲストＯＳ２（１ｄ）、ゲストＯＳ１（１ａ）のＯＳＩＤを格納したレジスタ（１ｂ）、ゲストＯＳ２（１ｄ）のＯＳＩＤを格納したレジスタ（１ｅ）、ＯＳＩＤマネージャ（１ｆ）、ＩＰ０（Intellectual Property）（１ｉ）、ＩＰ１（１ｊ）、ＩＰ０（１ｉ）が使用するレジスタ（１ｋ）、ＩＰ１（１ｊ）が使用するレジスタ（１ｌ）、ＩＰ０が管理するリソース（メモリ等）（不図示）で構成されている。ハイパーバイザ（１ｃ）はゲストＯＳ１およびゲストＯＳ２の仮想環境上の動作を制御し、ゲストＯＳ１およびゲストＯＳ２に対する仮想化システムのリソースの割り当てを示す割当情報であるＯＳＩＤを管理する。ＩＰ０（１ｉ）およびＩＰ１（１ｊ）は割当情報に基づいてリソースへのアクセスを管理する。

第一の実施形態において、図８の従来技術におけるゲートウェイ（８ｆ）に相当する制御部としてのＯＳＩＤマネージャ（１ｆ）が存在し、ＯＳＩＤマネージャ（１ｆ）はＯＳＩＤを生成する更新制御部（１ｇ）とＯＳＩＤ生成部（１ｈ）とを有している。ＯＳＩＤ生成部（１ｈ）はゲストＯＳ１（１ａ）及びゲストＯＳ２（１ｄ）に割り当てられるＯＳＩＤを生成する。更新制御部（１ｇ）はゲストＯＳ１（１ａ）、ゲストＯＳ２（１ｄ）、ＩＰ０（１ｉ）、ＩＰ１（１ｊ）に対して、更新用ＯＳＩＤを新たなＯＳＩＤとして使用するように指示を行う。

（ＯＳＩＤの更新フロー）
具体的に図２を用いて、本実施の形態におけるＯＳＩＤの更新フローについて説明する。非セキュアＣＰＵ０で稼働するゲストＯＳ１（１ａ）からハイパーバイザ（１ｃ）に対してリソースを管理するＩＰ０（１ｉ）へのアクセス申請を行う（Ｓ２０１）。ハイパーバイザ（１ｃ）は各ＩＰにアクセスするゲストＯＳのＯＳＩＤを生成し、生成したＯＳＩＤを初期値として設定する（Ｓ２０２）。一例として、ハイパーバイザ（１ｃ）はゲストＯＳ１（１ａ）に対してＯＳＩＤ＝Ａを割り当てる。ＯＳＩＤマネージャ（１ｆ）はハイパーバイザ（１ｃ）が設定したＯＳＩＤ初期値（ＯＳＩＤ＝Ａ）をＩＰ０（１ｉ）に設定すると共に、ＯＳＩＤ生成部（１ｈ）が新たなＯＳＩＤ（ＯＳＩＤ＝Ａ’）を生成する（Ｓ２０３）。ＯＳＩＤマネージャ（１ｆ）はＩＰ０（１ｉ）に設定したＯＳＩＤをＣＰＵ０に設定し、ＣＰＵ０が稼働可能な状態にする（Ｓ２０４）。

ゲストＯＳ１（１ａ）はＣＰＵ０に設定されたＯＳＩＤ（ＯＳＩＤ＝Ａ）を使用して、ＩＰ０（１ｉ）の管理するリソースに対してアクセス要求を行う（Ｓ２０５）。ＩＰ０（１ｉ）はゲストＯＳ１（１ａ）からのリソースへのアクセス要求に対して、ＯＳＩＤマネージャ（１ｆ）により設定されたＯＳＩＤと一致している場合は、リソースへのアクセスを許可する（Ｓ２０６）。ＯＳＩＤが一致しない場合はリソースへのアクセスを拒否する。本例では、ゲストＯＳ１（１ａ）のＯＳＩＤ＝Ａに対し、ＩＰ０（１ｉ）のレジスタにはＯＳＩＤ＝Ａが設定されているため、アクセスを受け付ける。一方、ＯＳＩＤマネージャ（１ｆ）は、あらかじめ設定された更新タイミング（所定のタイミング）がきたら、生成しておいたＯＳＩＤ＝Ａ’をＩＰ０（１ｉ）及びＣＰＵ０に送信する。また、送信したＯＳＩＤに切り替える指示をＩＰ０（１ｉ）及びＣＰＵ０に対して行なう（Ｓ２０７）。

（効果）
ＯＳＩＤをシステム動作中であっても頻繁に変更することが可能となり、悪意あるゲストＯＳがＯＳＩＤを偽造して許可されていないリソースにアクセス可能となったとしても、ＯＳＩＤは定期的に更新されるため、アクセスに成功したＯＳＩＤはすぐに無効になってしまう。つまり，仮想化システムでのゲストＯＳの稼働にあたり、重要な要素の一つである高い堅牢性を実現することが可能となる。また、ＯＳＩＤを頻繁に更新した場合であってもソフトウェアで実現されるハイパーバイザはＯＳＩＤの初期設定に関与するだけであり、ＯＳＩＤの更新管理はＯＳＩＤマネージャが実施するため、システムの性能劣化が発生しない。

（第二の実施形態）
図３は、第二の実施形態に係る仮想化システムの全体構成を示すブロックである。セキュアＣＰＵで稼働するハイパーバイザ（３ｃ）、非セキュアＣＰＵで稼働するゲストＯＳ１（３ａ）、ゲストＯＳ２（３ｄ）、ＯＳＩＤマネージャ（３ｆ）、更新制御部（３ｇ）、ゲストＯＳ１（３ａ）及びゲストＯＳ２（３ｄ）の内部にそれぞれ設けられたＯＳＩＤ生成部（３ｂ）、ＯＳＩＤ生成部（３ｅ）、ＩＰ０（Intellectual Property）（３ｈ）、ＩＰ１（３ｉ）、ＩＰ０（３ｈ）及びＩＰ１（３ｉ）の内部にそれぞれ設けられたＯＳＩＤ生成部（３ｊ）、ＯＳＩＤ生成部（３ｋ）が管理するリソース（メモリ等）（不図示）で構成されている。第一の実施形態とは、ＯＳＩＤ生成部が配置される場所が異なる構成となっている。

第二の実施形態においては、第一の実施形態と比較して、ＯＳＩＤ生成部がゲストＯＳ及びＩＰの内部に配置されている。また、ＯＳＩＤ生成部はＯＳＩＤから受け取るシード（変数）や算出関数等のパラメータを基にＯＳＩＤを生成して使用するため、ＯＳＩＤ自体を内部に保持しない。

（ＯＳＩＤの更新フロー）
具体的に図４を用いて、本実施の形態におけるＯＳＩＤの更新フローについて説明する。非セキュアＣＰＵ０で稼働するゲストＯＳ１（３ａ）は、新たにリソースが必要になった場合やＯＳＩＤの数を使い切った場合に、セキュアＣＰＵで稼働するハイパーバイザ（３ｃ）に対して、シード更新を申請する（Ｓ４０１）。シードはＯＳＩＤ生成に使用される変数である。ハイパーバイザ（３ｃ）は、ＯＳＩＤマネージャ（３ｆ）に対して、ＯＳＩＤ生成パラメータ（シード、算出関数、生成個数等）をゲストＯＳ１（３ａ）が稼働するＣＰＵ０に対して送信するように指示する（Ｓ４０２）。ＯＳＩＤマネージャ（３ｆ）は、ＯＳＩＤ生成パラメータをＣＰＵ０及びＩＰ０（３ｈ）に対して送信する（Ｓ４０３）。ゲストＯＳ１（３ａ）とＩＰ０（３ｈ）は、内部に配置されたＯＳＩＤ生成部（３ｂ）とＯＳＩＤ生成部（３ｊ）によりＯＳＩＤ生成パラメータと前のＯＳＩＤから新たにＯＳＩＤを生成する（Ｓ４０４）。言い換えると、ゲストＯＳ１（３ａ）及びＩＰ０（３ｈ）は、ＯＳＩＤマネージャ（３ｆ）からの指示に基づいて、パラメータ（例えばＯＳＩＤ生成パラメータのシード）と直前に使用していたＯＳＩＤに基づいて、新たに使用するＯＳＩＤを所定の関数（例えばＯＳＩＤ生成パラメータの算出関数）により算出する。ＯＳＩＤマネージャ（３ｆ）はＣＰＵ０が稼働可能な状態にする（Ｓ４０５）。

ゲストＯＳ１（３ａ）は生成したＯＳＩＤを使用して、ＩＰ０（３ｈ）に対してリソースへのアクセス要求を行う（Ｓ４０６）。ＩＰ０（３ｈ）は、生成したＯＳＩＤを使用してリソースへのアクセス管理を行う（Ｓ４０７）。アクセス要求のＯＳＩＤと、生成したＯＳＩＤとを比較して、一致している場合はアクセス要求を受け付ける。更新制御部（３ｇ）はゲストＯＳ１（３ａ）及びＩＰ０（３ｈ）に対して定期的に（所定のタイミングで）ＯＳＩＤの更新を指示する。配置されたＯＳＩＤ生成部（３ｂ）、ＯＳＩＤ生成部（３ｊ）では、ＯＳＩＤを定期的に生成して、更新制御部（３ｇ）からの指示により使用するＯＳＩＤを生成しておいたＯＳＩＤに更新する。更新した場合は古くなったＯＳＩＤを消去し無効にする（Ｓ４０８）。なお、ＣＰＵ０が何らかの処理によりロックされている期間はＯＳＩＤを更新しないようにする。ゲストＯＳ１（３ａ）はＩＰ０（３ｈ）へのリソース要求が完了した時に、ハイパーバイザ（３ｃ）に完了を通知する（Ｓ４０９）。

（効果）
第二の実施の形態では、ゲストＯＳ及びＩＰ（リソース）共に、保持するＯＳＩＤはその都度ＯＳＩＤ生成部により生成されるため、ＯＳＩＤ自体を保持する必要がなくなり、ＯＳＩＤを完全に隠蔽可能になる。また、ゲストＯＳ及びＩＰ（リソース）が保持するデータはあくまでＯＳＩＤ生成用のパラメータであるため、仮にパラメータを盗まれた場合であっても、ＯＳＩＤの生成アルゴリズムが解明されない限り、ＯＳＩＤを生成することが不可能であり、高い堅牢性を実現できる。

（第三の実施形態）
図５は、第三の実施形態に係る仮想化システムの全体構成を示すブロックである。セキュアＣＰＵで稼働するハイパーバイザ（５ｃ）、非セキュアＣＰＵで稼働するゲストＯＳ１（５ａ）、ゲストＯＳ２（５ｄ）、ゲストＯＳ１（５ａ）及びゲストＯＳ２（５ｄ）の内部に設けられたＯＳＩＤ生成部（５ｂ）、ＯＳＩＤ生成部（５ｅ）、ＯＳＩＤマネージャ（５ｆ）、ＩＰ０（Intellectual Property）（５ｇ）、ＩＰ１（５ｉ）、ＩＰ０（５ｇ）及びＩＰ１（５ｉ）の内部にそれぞれ設けられたＯＳＩＤ生成部（５ｈ）、ＯＳＩＤ生成部（５ｊ）、ＩＰ０（５ｇ）が管理するリソース（メモリ等）（不図示）で構成されている。第一の実施形態とは、ＯＳＩＤ生成部が配置される場所が異なる構成となっている。また、第二の実施形態とは、更新制御部がない点が異なっている。

第三の実施形態においては、ＯＳＩＤマネージャによる更新指示が不要となる構成である。第二の実施形態と同様に、ＯＳＩＤ生成部はゲストＯＳ及びリソース内部に配置され、ＯＳＩＤマネージャからのパラメータに従ってＯＳＩＤを生成する。ゲストＯＳは、例えば１回のアクセス毎や１０回のアクセス毎等の予め決められた間隔（所定のタイミング）でＯＳＩＤを更新してリソースにアクセスする。リソースも同様にアクセス回数をカウントしてあらかじめ決められた更新タイミングになったら同様にＯＳＩＤを更新する。更新間隔はＯＳＩＤマネージャがあらかじめ設定しておく。

（ＯＳＩＤの更新フロー）
具体的に図６を用いて、本実施に形態におけるＯＳＩＤの更新フローについて説明する。非セキュアＣＰＵ０で稼働するゲストＯＳ１（５ａ）は、新たにリソースが必要になった場合やＯＳＩＤの数を使い切った場合に、セキュアなＣＰＵで稼働するハイパーバイザ（５ｃ）に対して、シード更新を申請する（Ｓ６０１）。シードはＯＳＩＤ生成に使用される変数である。ハイパーバイザ（５ｃ）は、ＯＳＩＤマネージャ（５ｆ）に対して、ＯＳＩＤ生成パラメータ（シード、算出関数、生成個数等）をゲストＯＳ１（５ａ）が稼働するＣＰＵ０に対して送信するように指示する（Ｓ６０２）。ＯＳＩＤマネージャ（５ｆ）は、ＯＳＩＤ生成パラメータをＣＰＵ０及びＩＰ０（５ｇ）に対して送信する（Ｓ６０３）。ゲストＯＳ１（５ａ）とＩＰ０（５ｇ）は、内部に配置されたＯＳＩＤ生成部（５ｆ）とＯＳＩＤ生成部（５ｈ）によりＯＳＩＤパラメータと前のＯＳＩＤから新たにＯＳＩＤを生成する（Ｓ６０４）。言い換えると、ゲストＯＳ１（５ａ）及びＩＰ０（５ｇ）は、パラメータ（例えばＯＳＩＤ生成パラメータのシード）と直前に使用していたＯＳＩＤに基づいて、新たに使用するＯＳＩＤを所定の関数（例えばＯＳＩＤ生成パラメータの算出関数）により算出する。ＯＳＩＤ生成パラメータをＣＰＵ０が稼働可能な状態にする（Ｓ６０５）。

ゲストＯＳ１（５ａ）は生成したＯＳＩＤを使用してリソースへのアクセス管理を行う（Ｓ６０６）。ＩＰ０（５ｇ）は、生成したＯＳＩＤを使用してリソースへのアクセス管理を行う（Ｓ６０７）。アクセス要求のＯＳＩＤと、生成したＯＳＩＤとを比較して、一致している場合はアクセス要求を受け付ける。ゲストＯＳ１（５ａ）及びＩＰ０（５ｇ）の内部にそれぞれ配置されたＯＳＩＤ生成部（５ｂ）、ＯＳＩＤ生成部（５ｈ）では、ＯＳＩＤを所定のタイミングで生成するともに、古くなったＯＳＩＤを消去し無効にする（Ｓ６０８）。所定のタイミングとしては、ゲストＯＳ１（５ａ）がＩＰ０（５ｇ）へのアクセス要求をした回数が所定の値となった時、一方ＩＰ０（５ｇ）はゲストＯＳ１（５ａ）からのアクセス要求の回数が所定の回数となった時に、ＯＩＳＤを更新するようにしてもよい。なお、ＣＰＵがロックされている期間はＯＳＩＤを更新しないようにする。ゲストＯＳ１（５ａ）はＩＰ０（５ｇ）へのリソース要求が完了した時に、ハイパーバイザ（５ｃ）に完了を通知する（Ｓ６０９）。

（効果）
第三の実施の形態では、ゲストＯＳからＩＰ（リソース）へのアクセスは順序保証されたアクセスになり、このアクセスを元に更新タイミングを決めることによってＯＳＩＤマネージャからの更新指示がなくても矛盾したＯＳＩＤになることなくアクセス可能となる。また、ＯＳＩＤマネージャは各ゲストＯＳ、ＩＰ（リソース）に対して更新制御を行う必要がないため、制御対象が増えた場合であっても複雑な制御をすることなくＯＳＩＤの頻繁な定期更新が可能となる。

（変形例１）
例えば、ＯＳＩＤ生成部の機能を簡素化する方法もある。第二及び第三の実施形態においては、ゲストＯＳ及びＩＰ内部のＯＳＩＤ生成部がＯＳＩＤを生成していたが、ＯＳＩＤ生成部を設ける代わりに、ＯＳＩＤ格納テーブルを保持することも可能である。ＯＳＩＤ格納テーブルにＯＳＩＤマネージャがＯＳＩＤを格納し、あらかじめ定められた更新のタイミングでテーブル内のＯＳＩＤを順次更新していく。例えば、ゲストＯＳ１（３ａ，５ａ）及びＩＰ０（３ｈ，５ｇ）は、ＯＳＩＤマネージャ（３ｆ，５ｆ）からの指示に基づいて、パラメータと直前に使用していたＯＳＩＤに基づいて、割当情報テーブルとしてのＯＳＩＤ格納テーブルより生成する。ＯＳＩＤがテーブルの最後に到達した場合は、次の更新タイミングで最初に戻るようにする。この方法では、ＯＳＩＤ生成部を有する場合よりも、より簡素な構成で堅牢性の高い仮想化システムの構築が可能になる。

（変形例２）
各実施形態におけるＯＳＩＤ生成部が個別にＯＳＩＤを生成する場合、生成したＯＳＩＤが重複してしまう可能性がある。この問題を解決するために、図７に示すように、ＯＳＩＤをＯＳ識別部（７ａ）とＯＳＩＤ部（７ｂ）により構成するようにする。ＯＳ識別部（７ａ）はゲストＯＳ毎にあらかじめ決められた番号を格納する。図７の構成例では最大４個までのＯＳをサポートすることが可能となっている。ＯＳＩＤは１６ビットの場合、ＯＳ識別部（７ａ）は、ビット０がゲストＯＳ０、ビット１がゲストＯＳ１といったように、ＯＳ識別部（７ａ）のビット位置と各ＯＳに割り振られたＯＳのＯＳＩＤが対応している。ＯＳ識別部（７ａ）のビット０＝１とすることで、ゲストＯＳ０用のＯＳＩＤとして識別される。また、複数のＯＳからアクセスを許可する場合は、同様に対応したビット位置が“１”となる。例えば、ＯＳ０とＯＳ３のみ許可される場合は、ＯＳ識別部（７ａ）は“１００１”となる。

１ａ、３ａ、５ａ、８ａ ゲストＯＳ１（GUEST OS1）
１ｄ、３ｄ、５ｄ、８ｄ ゲストＯＳ２（GUEST OS2）
１ｂ、１ｅ、８ｂ、８ｅ レジスタ
１ｃ、３ｃ、５ｃ ハイパーバイザ（HYPERVISOR）
１ｆ、３ｆ、５ｆ ＯＳＩＤマネージャ（OSID MANAGER）
３ｂ、３ｅ、３ｊ、３ｋ ＯＳＩＤ生成部（OSID GENERATER）
５ｂ、５ｅ、５ｈ、５ｊ ＯＳＩＤ生成部（OSID GENERATER）
１ｇ、３ｇ 更新制御部（UPDATE CONTROLLER）
１ｉ、３ｈ、５ｇ、８ｉ ＩＰ０
１ｊ、３ｉ、５ｉ、８ｊ ＩＰ１
１ｋ、１ｌ レジスタ
８ｆ ゲートウェイ（GATEWAY）
８ｇ、８ｈ レジスタ

Claims (11)

1. 複数のゲストＯＳを仮想環境上で動作させる仮想化システムであって、
   前記複数のゲストＯＳの仮想環境上の動作を制御し、前記ゲストＯＳに対する前記仮想化システムのハードウェア・リソースの割り当てを示す割当情報を管理するハイパーバイザと、
   前記割当情報に基づいて前記ハードウェア・リソースへのアクセスを管理するＩＰと、前記割当情報を更新し、前記ゲストＯＳ及び前記ＩＰに更新した前記割当情報を送信する制御部と、
   を動作させるコンピュータを備え、
   前記ゲストＯＳは自身に割り当てられた前記割当情報に基づいて前記ＩＰに前記ハードウェア・リソースへのアクセスを要求し、
   前記ＩＰは自身に割り当てられた前記割当情報に基づいて、前記ゲストＯＳからのアクセスの要求を許可するかどうかを判断することを特徴とする仮想化システム。
2. 前記制御部は所定のタイミングで前記割当情報を更新し、前記ゲストＯＳ及び前記ＩＰへ送信し、更新した割当情報への切り替えを指示することを特徴とする、請求項１記載の仮想化システム。
3. 複数のゲストＯＳを仮想環境上で動作させる仮想化システムであって、
   前記複数のゲストＯＳの仮想環境上の動作を制御し、前記ゲストＯＳに対する前記仮想化システムのハードウェア・リソースの割り当てを示す割当情報を生成するためのパラメータを管理するハイパーバイザと、
   前記割当情報に基づいて前記ハードウェア・リソースへのアクセスを管理するＩＰと、
   前記割当情報の更新指示を前記ゲストＯＳ及び前記ＩＰに送信する制御部と、
   を動作させるコンピュータを備え、
   前記ハイパーバイザは前記パラメータを前記ゲストＯＳ及び前記ＩＰに送信し、
   前記ゲストＯＳは前記パラメータにより前記割当情報を生成し、生成した割当情報に基づいて前記ＩＰに前記ハードウェア・リソースへのアクセスを要求し、
   前記ＩＰは前記パラメータにより前記割当情報を生成し、生成した割当情報に基づいて、前記ゲストＯＳからのアクセスの要求を許可するかどうかを判断することを特徴とする仮想化システム。
4. 前記制御部は所定のタイミングで前記割当情報の更新指示を前記ゲストＯＳ及び前記ＩＰへ送信することを特徴とする、請求項３記載の仮想化システム。
5. 前記ゲストＯＳ及び前記ＩＰは、前記制御部からの指示に基づいて、前記パラメータと直前に使用していた前記割当情報に基づいて、新たに使用する割当情報を所定の関数により算出することを特徴とする、請求項４記載の仮想化システム。
6. 前記ゲストＯＳ及び前記ＩＰは、前記制御部からの指示に基づいて、前記パラメータと直前に使用していた前記割当情報に基づいて、割当情報テーブルより生成することを特徴とする、請求項４記載の仮想化システム。
7. 複数のゲストＯＳを仮想環境上で動作させる仮想化システムであって、
   前記複数のゲストＯＳの仮想環境上の動作を制御し、前記ゲストＯＳに対する前記仮想化システムのハードウェア・リソースの割り当てを示す割当情報を生成するためのパラメータを管理するハイパーバイザと、
   前記割当情報に基づいて前記ハードウェア・リソースへのアクセスを管理するＩＰと、
   を動作させるコンピュータを備え、
   前記ハイパーバイザは前記パラメータを前記ゲストＯＳ及び前記ＩＰに送信し、
   前記ゲストＯＳは所定のタイミングで前記パラメータにより前記割当情報を生成し、生成した割当情報に基づいて前記ＩＰに前記ハードウェア・リソースへのアクセスを要求し、
   前記ＩＰは所定のタイミングで前記パラメータにより前記割当情報を生成し、生成した割当情報に基づいて、前記ゲストＯＳからのアクセスの要求を許可するかどうかを判断することを特徴とする仮想化システム。
8. 前記ゲストＯＳ及び前記ＩＰは、制御部からの指示に基づいて、前記パラメータと直前に使用していた前記割当情報に基づいて、新たに使用する割当情報を所定の関数により算出することを特徴とする、請求項７記載の仮想化システム。
9. 前記ゲストＯＳ及び前記ＩＰは、制御部からの指示に基づいて、前記パラメータと直前に使用していた前記割当情報に基づいて、割当情報テーブルより生成することを特徴とする、請求項７記載の仮想化システム。
10. 前記所定のタイミングは、前記ゲストＯＳが前記ＩＰへのハードウェア・リソースの要求回数が所定の回数となったタイミングであることを特徴とする請求項７記載の仮想化システム。
11. 複数のゲストＯＳを仮想環境上で動作させる仮想化システムにおける動作管理方法であって、
    ハイパーバイザが前記複数のゲストＯＳの仮想環境上の動作を制御し、前記ゲストＯＳに対する前記仮想化システムのハードウェア・リソースの割り当てを示す割当情報を管理するステップと、
    ＩＰが前記割当情報に基づいて前記ハードウェア・リソースへのアクセスを管理するステップと、
    制御部が前記割当情報を更新し、前記ゲストＯＳ及び前記ＩＰに更新した前記割当情報を送信するステップと、
    前記ゲストＯＳが自身に割り当てられた前記割当情報に基づいて前記ＩＰに前記ハードウェア・リソースへのアクセスを要求するステップと、
    前記ＩＰが自身に割り当てられた前記割当情報に基づいて、前記ゲストＯＳからのアクセスの要求を許可するかどうかを判断するステップと、
    をコンピュータが実行することを特徴とする動作管理方法。

Images