JP2010009323A - イメージ検査装置、ｏｓ装置及びイメージ検査方法 - Google Patents

Abstract

【課題】管理ＯＳと、管理ＯＳを検査する検査ＯＳとを有するイメージ検査装置において、管理ＯＳが必要に応じて検査ＯＳの検査状態を変化させることで、オーバヘッドを削減し、かつプログラムを安全に検査する。
【解決手段】イメージ検査装置は、プログラム又はデータの少なくとも一方を含むイメージを格納する格納部２２１と、格納部２２１に格納されたイメージを管理する開放ＯＳ部２００Ａと、格納部２２１に格納されたイメージを検査する検査ＯＳ部３００Ａとを備える。開放ＯＳ部２００Ａは、所定の条件が満たされたとき、メモリ領域に格納されたイメージの検査依頼を検査ＯＳ部に通知する。検査ＯＳ部３００Ａは、管理ＯＳ部３００Ａからの検査依頼に応じて、メモリ領域に格納されたイメージを所定の検査方法で検査する検査部３０１と、検査部３０１による検査結果を管理ＯＳ部３００Ａに通知する検査結果通知部３０３とを備える。
【選択図】 図２

Description

本発明は、プログラム又はデータの少なくとも一方を含むイメージを検査するイメージ検査装置、当該イメージ検査装置に用いられるＯＳ装置及びイメージ検査方法に関する。

携帯電話やＰＤＡ等のモバイル端末（以下、「端末」）では、ｉアプリ（登録商標）のように、利用者が、アプリケーションやドライバ等のプログラムを追加することが可能になっている。端末の販売後に追加されるプログラム（以下、「追加プログラム」）は、開発者や利用者からは正常に動作しているように見えても、他のプログラムに攻撃を加える恐れがある。

ＣＰＵによるプログラムの実行は、オペレーティングシステム（ＯＳ）の中核プログラムであるカーネルによって制御される。ＣＰＵは、カーネルによってメモリ領域に展開されたプログラムを、順に実行する。すなわち、あるプログラムが実行されているときは、実行待ちのアプリケーションプログラムやカーネルもメモリ領域内に存在する。

悪意のある追加プログラムが他のプログラムを攻撃する手法としては、メモリ領域内の他のプログラムやデータなどのイメージを改変することが一般的である。特に、悪意のある追加プログラムによってカーネルプログラムが改変されると、プログラムの実行制御機能が停止するので、端末がフリーズし、再起動もできなくなる可能性がある。

一般的なＯＳは、起動から動作終了までメモリ領域内に存在する静的なカーネルプログラムと、必要に応じてメモリ領域にロード／アンロードされる動的なカーネルプログラムとを有する。静的なカーネルプログラムによって実行が制御される検査プログラムを用いて、動的なカーネルプログラムを検査する手法が提案されている（特許文献１参照）。しかし、当該手法では、悪意のある追加プログラムによって静的なカーネルプログラムが改変されると、検査プログラムが実行不可能となる。

一方、１つの端末に複数のＯＳ（カーネル）を実装可能とする仮想化ソフト（Virtual Machine Monitor）を用いて、追加プログラムの実行を管理するＯＳ（以下、「管理ＯＳ」）と、検査プログラムの実行を制御するＯＳ（以下、「検査ＯＳ」）とを分離する手法が提案されている（特許文献２参照）。

特許文献２では、検査プログラムは、管理ＯＳのメモリ領域を定期的に検査する。これにより、検査ＯＳが、悪意のある追加プログラムからの攻撃を受けることがなく、管理ＯＳを安全に検査することができる。
米国特許第６６８１３２９号明細書 米国特許出願公開第２００５／０１３２１２２号明細書

上述した特許文献２では、検査ＯＳは、管理ＯＳのメモリ領域を検査するための演算処理（例えばハッシュ演算）を実行する。このような演算処理が定期的に実行されることに伴い、演算処理に伴う処理負荷（オーバヘッド）が生じる。

また、検査ＯＳが保護ＯＳのメモリ領域を検査する度に、仮想化ソフトは、ＣＰＵで実行するＯＳを切替える処理を行う。つまり、管理ＯＳから保護ＯＳへの移行処理と、保護ＯＳから管理ＯＳへの復帰処理とに起因してオーバヘッドが増加する。

上記のように、管理ＯＳのメモリ領域の検査を検査ＯＳが定期的に実行するので、プログラムの実行状況とは無関係に、常に一定の処理負荷（オーバヘッド）が生じる。

上記問題点に鑑み、本発明は、管理ＯＳと、管理ＯＳを検査する検査ＯＳとを有するイメージ検査装置において、管理ＯＳが必要に応じて検査ＯＳの検査状態を変化させることで、オーバヘッドを削減し、かつプログラムを安全に検査可能なイメージ検査装置、ＯＳ装置及びイメージ検査方法を提供することを目的とする。

上記目的を達成するため、本発明の第１の特徴は、プログラム又はデータの少なくとも一方を含むイメージを格納するメモリ領域（格納部２２１）と、前記メモリ領域に格納された前記イメージを管理する管理ＯＳ部（開放ＯＳ部２００Ａ〜２００Ｅ）と、前記メモリ領域に格納された前記イメージを検査する検査ＯＳ部（検査ＯＳ部３００Ａ〜３００Ｅ）とを備え、前記管理ＯＳ部は、所定の条件が満たされたとき、前記メモリ領域に格納された前記イメージの検査依頼を前記検査ＯＳ部に通知し、前記検査ＯＳ部は、前記管理ＯＳ部からの前記検査依頼に応じて、前記メモリ領域に格納された前記イメージを所定の検査方法で検査する検査部（検査部３０１）と、前記検査部による検査結果を前記管理ＯＳ部に通知する通知部（検査結果通知部３０３）とを備えることを要旨とする。ここで、「イメージ」とは、プログラム又はデータなど、メモリ領域に格納されるすべての情報である。

このような特徴によれば、管理ＯＳ部は、所定の条件が満たされたとき、メモリ領域に格納されたプログラムの検査依頼を検査ＯＳ部に通知する。検査ＯＳ部は、管理ＯＳ部からの検査依頼に応じて、メモリ領域に格納されたプログラムを所定の検査方法で検査する。また、検査ＯＳ部は、検査部による検査結果を管理ＯＳ部に通知する。したがって、管理ＯＳによって検査ＯＳが実行する検査を制御し、検査ＯＳが適応的に検査を実行するので、オーバヘッドを削減可能となる。

本発明の第２の特徴は、本発明の第１の特徴に係り、前記検査ＯＳ部は、前記検査部が前記イメージを検査する際の判断基準となる検査用情報を予め記憶する検査用情報記憶部（検査用情報記憶部３０２）をさらに備え、前記検査部は、前記検査用情報記憶部に記憶された前記検査用情報を用いて、前記イメージを検査することを要旨とする。

本発明の第３の特徴は、本発明の第１の特徴に係り、前記管理ＯＳ部は、前記通知部によって通知された前記検査結果に応じて、前記メモリ領域に前記イメージをロードし直すロード部を備えることを要旨とする。

本発明の第４の特徴は、本発明の第１の特徴に係り、前記検査ＯＳ部は、前記検査部による前記検査結果に応じて、前記メモリ領域に前記イメージをロードし直すロード部（ロード部３０４）をさらに備えることを要旨とする。

本発明の第５の特徴は、本発明の第１の特徴に係り、前記管理ＯＳ部は、前記管理ＯＳ部においてドライバのイメージが実行される場合、前記ドライバのイメージを前記メモリ領域にロードするロード部（ロード部２０３）と、前記ドライバのイメージの実行が完了すると、前記メモリ領域にロードされた前記ドライバのイメージをアンロードするアンロード部（アンロード部２１０）とを備えることを要旨とする。

本発明の第６の特徴は、本発明の第１の特徴に係り、前記管理ＯＳ部は、前記管理ＯＳ部においてプログラムが実行される際に、前記メモリ領域へのイメージのロードを禁止するロード禁止部（ロード禁止部２１１）と、前記メモリ領域にロードされたイメージが前記管理ＯＳ部において実行されるプログラムによってアンドロードされることを禁止するアンロード禁止部（ロード禁止部２１２）と、前記メモリ領域にロードされるイメージが前記管理ＯＳ部において実行されるプログラムによってアクセスされることを禁止するアクセス禁止部（隠蔽部２１３）とを備えることを要旨とする。

本発明の第７の特徴は、本発明の第１の特徴に係り、前記メモリ領域に格納された前記イメージを演算処理により検査する演算処理部（検査部２０７）と、前記演算処理の結果を記憶する演算結果記憶部（演算結果記憶部２０８）とを備え、前記検査部は、前記演算結果記憶部に記憶された前記結果を用いて、前記メモリ領域に格納された前記イメージを検査することを要旨とする。

本発明の第８の特徴は、本発明の第７の特徴に係り、前記検査部は、前記演算結果記憶部に記憶された前記結果と、前記検査用情報記憶部に記憶された前記検査用情報とを用いて、前記メモリ領域に格納された前記イメージの検査を行うことを要旨とする。

本発明の第９の特徴は、本発明の第１の特徴に係り、前記検査部は、前記メモリ領域に格納された前記イメージの一部を検査することを要旨とする。

本発明の第１０の特徴は、本発明の第１の特徴に係り、前記検査部は、所定のイベントが発生した場合に、前記メモリ領域に格納された前記イメージの少なくとも一部を検査することを要旨とする。

本発明の第１１の特徴は、本発明の第２の特徴に係り、前記管理ＯＳ部は、前記検査用情報の更新を前記検査ＯＳ部に要求する更新要求部（更新要求部２０５）と、新たな検査用情報を記憶する更新情報記憶部（更新情報記憶部２０６）とを備え、前記検査ＯＳ部は、前記更新情報記憶部に記憶されている前記新たな検査用情報を取得する更新情報取得部（更新情報取得部３０７）と、前記更新情報取得部によって取得された前記新たな検査用情報を前記検査用情報記憶部に格納する検査用情報生成部（検査用情報生成部３０８）とをさらに備えることを要旨とする。

本発明の第１２の特徴は、本発明の第１の特徴に係り、前記管理ＯＳ部は、前記メモリ領域に格納された前記イメージが断続的に前記メモリ領域に格納される動的なイメージである場合、前記動的なイメージが前記メモリ領域に格納されているときのみ、前記動的なイメージを検査対象とすることを要旨とする。

本発明の第１３の特徴は、本発明の第１の特徴に係り、前記管理ＯＳ部は、前記管理ＯＳ部の処理負荷が閾値未満であるとき、前記管理ＯＳ部において実行中のプログラムがシステムコールを発行したとき、前記メモリ領域に格納された前記イメージを利用中のプログラムが存在するとき、のいずれかのタイミングで、前記検査依頼を前記検査ＯＳ部に通知することを要旨とする。

本発明の第１４の特徴は、本発明の第１の特徴に係り、前記検査部は、前記検査依頼を受け取る前よりも、前記検査依頼を受けた後の検査実行回数を増加させることを要旨とする。

本発明の第１５の特徴は、プログラム又はデータの少なくとも一方を含むイメージを格納するメモリ領域（格納部２２１）、及び前記メモリ領域に格納された前記イメージを検査する他のＯＳ装置（検査ＯＳ３０）とともに用いられるＯＳ装置（開放ＯＳ２０）であって、所定の条件が満たされたとき、前記メモリ領域に格納された前記イメージの検査依頼を前記他のＯＳ装置に通知する通知部（検査依頼通知部２０１）を備えることを要旨とする。

本発明の第１６の特徴は、プログラム又はデータの少なくとも一方を含むイメージを格納するメモリ領域（格納部２２１）、及び前記メモリ領域に格納された前記イメージを管理する他のＯＳ装置（開放ＯＳ２０）とともに用いられるＯＳ装置であって、前記他のＯＳ装置からの検査依頼に応じて、前記メモリ領域に格納された前記イメージを所定の検査方法で検査する検査部（検査部３０１）と、前記検査部による検査結果を前記他のＯＳ装置に通知する通知部（検査結果通知部３０３）とを備えることを要旨とする。

本発明の第１７の特徴は、プログラム又はデータの少なくとも一方を含むイメージが格納されるメモリ領域と、前記メモリ領域に格納された前記イメージを管理する管理ＯＳ部と、前記メモリ領域に格納された前記イメージを検査する検査ＯＳ部とを備えるイメージ検査装置に適用されるイメージ検査方法であって、前記管理ＯＳ部が、所定の条件が満たされたとき、前記メモリ領域に格納された前記イメージの検査依頼を前記検査ＯＳ部に通知するステップと、前記検査ＯＳ部が、前記管理ＯＳ部からの前記検査依頼に応じて、前記メモリ領域に格納された前記イメージを所定の検査方法で検査するステップと、前記検査ＯＳ部が、前記検査するステップで得られた検査結果を前記管理ＯＳ部に通知するステップとを備えることを要旨とする。

本発明によれば、管理ＯＳと、管理ＯＳを検査する検査ＯＳとを有するイメージ検査装置において、管理ＯＳが必要に応じて検査ＯＳの検査状態を変化させることで、オーバヘッドを削減し、かつプログラムを安全に検査可能なイメージ検査装置、ＯＳ装置及びイメージ検査方法を提供できる。

次に、図面を参照して、本発明の第１〜第５実施形態を説明する。以下の第１〜第５実施形態における図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。

［第１実施形態］
（１）情報処理装置の概略構成
本発明の実施形態に係るイメージ検査装置の説明の前に、イメージ検査装置が実装される情報処理装置の概略構成について簡単に説明する。図１は、本実施形態に係るイメージ検査装置が実装される情報処理装置の概略構成図である。

図１に示すように、情報処理装置は、物理マシン５００、仮想化部４００、開放ＯＳ２０及び検査ＯＳ３０を有する。

物理マシン５００は、ＣＰＵやメモリなど、情報処理装置のハードウェアに相当する。なお、本実施形態では、情報処理装置として携帯通信端末を想定している。よって、追加プログラム、例えばアプリケーションプログラムやドライバをダウンロードする通信装置などが、物理マシン５００に含まれる。

仮想化部４００は、物理マシン５００のリソースを開放ＯＳ２０及び検査ＯＳ３０に配分する仮想マシンモニタとして機能する。開放ＯＳ２０及び検査ＯＳ３０には、仮想的なデバイスが提供される。

これにより、複数のＯＳを１つの情報処理装置に設けることが可能となる。ただし、仮想化部４００としては、仮想マシンモニタに限らず、種々の仮想化ソフトウェアが利用可能である。仮想化部４００は、開放ＯＳ２０と検査ＯＳ３０との間で通信を可能とする。

開放ＯＳ２０は、仮想マシン２１及び開放ＯＳ部２００Ａを有する。仮想マシン２１及び開放ＯＳ部２００Ａは、追加プログラムを実行する。具体的には、実行部２２１は、開放ＯＳ部２００Ａによって格納部２３１に展開された追加プログラムを、順に実行する。

開放ＯＳ２０上で追加プログラムが動作する場合、検査ＯＳ３０が攻撃される可能性がある。したがって、検査ＯＳ３０から開放ＯＳ２０へのアクセスは仮想化部４００によって許可されるが、開放ＯＳ２０から検査ＯＳ３０へのアクセスは仮想化部４００によって遮断される。

検査ＯＳ３０は、仮想マシン３１及び検査ＯＳ部３００Ａを有する。仮想マシン３１及び検査ＯＳ部３００Ａは、検査プログラムを実行する。これにより、検査ＯＳ３０は、開放ＯＳ２０の格納部２３１内に展開されているプログラムを検査する。

上記のように、検査ＯＳ３０（検査ＯＳ部３００Ａ）から開放ＯＳ２０の格納部２３１へのアクセスは可能であるが、開放ＯＳ２０（開放ＯＳ部２００Ａ）から検査ＯＳ３０の格納部３３１へのアクセスは不可能である。

（２）イメージ検査装置の構成
次に、本実施形態に係るイメージ検査装置の構成について説明する。図２は、本実施形態に係るイメージ検査装置の機能ブロック図である。

（２．１）開放ＯＳ部の構成
図２に示すように、開放ＯＳ部２００Ａは、検査依頼通知部２０１、検査結果取得部２０２、ロード部２０３及びイメージ記憶部２０４を有する。

検査依頼通知部２０１は、仮想化部４００を介して、格納部２３１に格納されているプログラムの検査を依頼する。検査依頼のタイミングとしては、例えば、（ａ）実行部２２１の処理負荷が閾値未満であるとき、（ｂ）実行部２２１によって実行されたプログラムがシステムコールを発行したとき、（ｃ）格納部２３１に格納されたプログラムがドライバを含むときが挙げられる。

検査結果取得部２０２は、仮想化部４００を介して、格納部２３１の検査結果を検査ＯＳ部３００Ａから取得する。

ロード部２０３は、検査結果取得部２０２によって取得された検査結果に基づき、イメージ記憶部２０４にイメージをロードする。イメージ記憶部２０４は、格納部２３１内に構成される。

なお、図１では図示を省略したが、開放ＯＳ２０の仮想マシン２１には、ロード元のプログラムを格納する補助格納部を有している。ロード部２０３は、当該補助格納部から読み出されたプログラムをイメージ記憶部２０４にイメージとしてロードする。

このため、イメージ記憶部２０４内のイメージが改変されても、改変前のイメージをイメージ記憶部２０４にロードし直すことにより、正常な状態に復帰できる。

（２．２）検査ＯＳ部の構成
引き続き、図２を参照して、検査ＯＳ部３００Ａの構成について説明する。検査ＯＳ部３００Ａは、検査部３０１、検査用情報記憶部３０２及び検査結果通知部３０３を有する。

検査用情報記憶部３０２は、検査対象のメモリ領域に関する情報である検査用情報を記憶する。

検査部３０１は、開放ＯＳ部２００Ａから検査依頼を受け取ると、検査用情報記憶部３０２に記憶された検査用情報を用いて、格納部２３１内のイメージを検査する。検査方法としては、例えば、検査を一回だけ実行する、又は検査依頼を受けてから一定期間において定期的に検査を行うといった方法がある。

検査結果通知部３０３は、検査部３０１による検査結果を開放ＯＳ部２００Ａに通知する。

（３）検査依頼の一例
次に、開放ＯＳ部２００Ａから検査ＯＳ部３００Ａに通知される検査依頼について説明する。図３は、検査依頼の一例を示す図である。

図３に示すように、検査依頼は、（ａ）検査依頼のみからなる場合と、（ｂ）検査対象領域を指定する情報を含む場合とがある。

上記（ａ）の場合では、開放ＯＳ部２００Ａの検査依頼通知部２０１は、予め定められた検査対象領域についての検査依頼を検査ＯＳ部３００Ａに通知する。

一方、上記（ｂ）の場合では、検査依頼通知部２０１は、検査対象領域を指定して、検査ＯＳ部３００Ａに検査依頼を通知する。図３の例では、検査対象領域を指定する情報により、検査対象のメモリ領域が３つ指定されている。

検査対象領域を指定する情報としては、メモリアドレス、ページ番号、領域識別子又はドライバ名の少なくとも１つが使用できる。メモリアドレスとは、格納部２３１のアドレスである。ページ番号とは、格納部２３１内の各ページに割り振られた番号である。領域識別子とは、検査対象領域を一意に識別する情報である。ドライバ名とは、格納部２３１に格納されたドライバを識別する情報である。

なお、検査依頼通知部２０１は、上記（ａ）及び（ｂ）の検査依頼を同時に検査ＯＳ部３００Ａに通知してもよい。

（４）検査結果の一例
次に、検査ＯＳ部３００Ａから開放ＯＳ部２００Ａに通知される検査結果について説明する。図４は、検査結果の一例を示す図である。

図４に示すように、検査結果は、（ａ）検査結果のみからなる場合と、（ｂ）検査結果がＮＧであった領域を特定する情報を含む場合と、（ｃ）検査した領域を特定する情報、及び検査結果を含む場合とがある。

（５）検査用情報の一例
次に、検査用情報記憶部３０２に記憶されている検査用情報について説明する。図５は、検査用情報の一例を示す図である。

図５に示すように、検査用情報は、検査対象のメモリ領域の場所を示す領域情報と、メモリ領域内のイメージに関するイメージ情報とを含む。

領域情報としては、領域の開始アドレス及び終了アドレスが使用される。あるいは、格納部２３１が固定長の区画に分割されている場合には、各区画に識別子を付与してもよい。

なお、格納部２３１が固定長の区画に分割されている場合、検査用情報の一部は、本情報処理装置が販売される前に格納しておくことができる。

イメージ情報としては、イメージのハッシュ値が使用される。あるいは、メモリ領域内のイメージそのものであってもよい。

また、検査用情報には、検査を行った時刻や、検査回数等を含めてもよい。これらの情報を検査用情報に含めることで、検査履歴等として利用できる。

（６）イメージ検査装置の動作
次に、本実施形態に係るイメージ検査装置の動作について説明する。図６は、本実施形態に係るイメージ検査装置の動作を示すフローチャートである。ここでは、領域情報として開始アドレス及び終了アドレスを用い、イメージ情報としてハッシュ値を用いた場合について説明する。

ステップＳ１０１において、開放ＯＳ部２００Ａは、カーネルが管理するメモリマップテーブルなどに基づき、検査対象の格納部２３１を示す情報（メモリのアドレスやページ番号）を取得する。

ステップＳ１０２において、開放ＯＳ部２００Ａは、格納部２３１の検査を検査ＯＳ部３００Ａに依頼する。

ステップＳ１０３において、検査ＯＳ部３００Ａは、ステップＳ１０２で受けた依頼に応じて、検査用情報を取得する。

ステップＳ１０４において、検査ＯＳ部３００Ａは、ステップＳ１０３で取得した検査用情報に基づいて格納部２３１を検査する。具体的には、領域情報が示す開始アドレス及び終了アドレスの範囲内のイメージに対し、イメージ情報が示すハッシュ値を用いたハッシュ演算が実行される。

演算結果とハッシュ値とを比較して同じであれば、イメージが改変されていないので、検査結果はＯＫとなる。一方、演算結果とハッシュ値とが異なっていれば、イメージが改変されており、検査結果はＮＧとなる。

ステップＳ１０５において、検査ＯＳ部３００Ａは、ステップＳ１０４で得られた検査結果を開放ＯＳ部２００Ａに通知する。

ステップＳ１０６において、開放ＯＳ部２００Ａは、ステップＳ１０６で通知された検査結果を取得する。

ステップＳ１０７において、開放ＯＳ部２００Ａは、ステップＳ１０６で取得した検査結果が改変有りを示しているか否かを判定する。当該検査結果が改変有り（ＮＧ）を示している場合、ステップＳ１０８に進む。当該検査結果が改変無し（ＯＫ）を示している場合、処理が終了する。

ステップＳ１０８において、開放ＯＳ部２００Ａは、改変前のイメージを取得する。

ステップＳ１０９において、開放ＯＳ部２００Ａは、ステップＳ１０８で取得されたイメージをロードし直す。

（７）作用・効果
以上詳細に説明したように、本実施形態によれば、開放ＯＳ部２００Ａは、格納部２３１に格納されたイメージの検査依頼を検査ＯＳ部３００Ａに通知する。検査ＯＳ部３００Ａは、開放ＯＳ部２００Ａからの検査依頼に応じて、格納部２３１の検査を実行する。つまり、検査ＯＳ部３００Ａが検査依頼を受けてから検査を行うことで、検査ＯＳ部３００Ａが実行する検査の回数を削減でき、オーバヘッドを削減できる。

また、開放ＯＳ部２００Ａは、検査ＯＳ部３００Ａによって通知された検査結果に応じて、格納部２３１に正しいイメージを格納し直す。これにより、正常な状態に復帰可能となり、フリーズの発生が回避される。

さらに、検査ＯＳ部３００Ａの検査部３０１は、検査用情報記憶部３０２を参照することで、検査対象の領域を特定し、特定された領域を検査する。これにより、予めロード先が決まっているイメージを容易かつ迅速に検査可能となる。

［第２実施形態］
上述した第１実施形態では、イメージ記憶部２０４が開放ＯＳ部２００Ａ内に設けられていた。この場合、追加プログラムからの攻撃により、開放ＯＳ部２００Ａと同じアクセス権限を獲得されると、追加プログラムがイメージ記憶部２０４内のイメージを改変する恐れがある。イメージ記憶部２０４内のイメージが改変されると、不正なイメージがロードされる危険性がある。

そこで、本実施形態では、追加プログラムが開放ＯＳ部２００Ａと同じアクセス権限で動作しても、イメージを不正にロードできないようにする。

なお、以下の第２〜第５実施形態の説明では、上述した第１実施形態と異なる点を主に説明する。

（１）イメージ検査装置の構成
図７は、本実施形態に係るイメージ検査装置の構成を示す機能ブロック図である。

図７に示すように、開放ＯＳ部２００Ｂは、図２で示したロード部２０３及びイメージ記憶部２０４を備えていない。

検査ＯＳ部３００Ｂは、図２で示した検査部３０１、検査用情報記憶部３０２及び検査結果通知部３０３に加えて、ロード部３０４及びイメージ記憶部３０５を備える。イメージ記憶部３０５は、ロード部３０４のロード元のイメージを記憶している。

ロード部３０４は、検査部３０１の検査結果に応じて、開放ＯＳ部２００Ｂの格納部２３１にイメージをロードする。具体的には、ロード部３０４は、検査部３０１の検査結果がＮＧである場合に、検査用情報記憶部３０２に記憶されている検査用情報を用いて、開放ＯＳ部２００Ｂの格納部２３１にイメージをロードする。検査用情報には、検査対象の領域を特定する情報が含まれているので、ロード先が特定可能である。

（２）イメージ検査装置の動作
次に、本実施形態に係るイメージ検査装置の動作について説明する。図８は、本実施形態に係るイメージ検査装置の動作を示すフローチャートである。

ステップＳ２０１において、開放ＯＳ部２００Ｂは、カーネルが管理するメモリマップテーブルなどに基づき、検査対象の格納部２３１を示す情報（メモリのアドレスやページ番号）を取得する。

ステップＳ２０２において、開放ＯＳ部２００Ｂは、格納部２３１の検査を検査ＯＳ部３００Ｂに依頼する。

ステップＳ２０３において、検査ＯＳ部３００Ｂは、ステップＳ２０２で受けた依頼に応じて、検査用情報を取得する。

ステップＳ２０４において、検査ＯＳ部３００Ｂは、ステップＳ２０３で取得した検査用情報に基づいて格納部２３１を検査する。

ステップＳ２０５において、検査ＯＳ部３００Ａは、ステップＳ２０４の結果が改変有りを示しているか否かを判定する。当該検査結果が改変有り（ＮＧ）を示している場合、ステップＳ２０６に進む。当該検査結果が改変無し（ＯＫ）を示している場合、ステップＳ２０８に進む。

ステップＳ２０６において、検査ＯＳ部３００Ｂのロード部３０４は、イメージ記憶部３０５から元のイメージを取得する。

ステップＳ２０７において、ロード部３０４は、ステップＳ２０６で取得した元のイメージを、格納部２３１のうち改変が生じた領域へロードする。

ステップＳ２０８において、検査ＯＳ部３００Ｂは、ステップＳ２０４で得られた検査結果を開放ＯＳ部２００Ｂに通知する。

ステップＳ２０９において、開放ＯＳ部２００Ｂは、検査結果を取得する。検査結果がＮＧを示している場合、元のイメージがロードされたことが確認される。

（３）作用・効果
開放ＯＳ部２００Ｂのロード部２０３が改変されると、正しいイメージを再びロードすることができなくなる。ロード部２０３を復帰させるには、開放ＯＳ部２００Ｂをリブートすればよいが、利用者の利便性を低下させる。本実施形態では、検査ＯＳ部３００Ｂがロード部３０４を備えることで、上記の問題が回避される。

上述したように、開放ＯＳ部２００Ｂから検査ＯＳ部３００Ｂへのアクセスは、仮想化部４００によって制限されるため、追加プログラムが開放ＯＳ部２００Ｂと同じ権限で動作しても、イメージ記憶部３０５にアクセスできない。

さらに、検査ＯＳ部３００Ｂにてロード処理を行うことによって、不正なイメージをロードすることもなくなる。したがって、開放ＯＳ部２００Ｂにロードされるイメージが、より改変され難くなる。

また、（ａ）実行部２２１の処理負荷が閾値未満であるとき、（ｂ）実行部２２１によって実行されたプログラムがシステムコールを発行したとき、（ｃ）格納部２３１に格納されたプログラムがドライバを含むときのいずれかのタイミングで検査依頼が行われることで、安全性を犠牲にせずに検査負荷を削減できる。

［第３実施形態］
上述した第１実施形態では、開放ＯＳと検査ＯＳとの切り替え頻度を従来よりも低減できるが、仮想化部４００の種類によっては切り替えコストが大きい場合も考えられるため、できる限り切り替え頻度を低減することが望ましい。

そこで、本実施形態では、検査処理を開放ＯＳ及び検査ＯＳで分散させることで、ＯＳ切り替え頻度を低減する。

（１）イメージ検査装置の構成
図９は、本実施形態に係るイメージ検査装置の構成を示す機能ブロック図である。

（１．１）開放ＯＳ部の構成
図９に示すように、開放ＯＳ部２００Ｃは、図２で示した検査依頼通知部２０１、検査結果取得部２０２、ロード部２０３及びイメージ記憶部２０４に加えて、検査部２０７、演算結果記憶部２０８及び検査用情報記憶部２０９を有する。

検査用情報記憶部２０９は、検査ＯＳ部３００Ｃの検査用情報記憶部３０２と同様に、検査対象のメモリ領域の場所を示す領域情報と、メモリ領域内のイメージに関するイメージ情報とを含む。

検査部２０７は、検査用情報記憶部２０９に記憶された検査用情報を用いて、格納部２３１を検査する。例えば、検査部２０７は、領域情報が示す開始アドレス及び終了アドレスの範囲内のイメージに対し、イメージ情報が示すハッシュ値を用いたハッシュ演算を実行する。

演算結果記憶部２０８は、検査部２０７による演算結果を記憶する。演算結果記憶部２０８は、図１０に示すように格納部２３１内に設けられていてもよく、格納部２３１の外部のレジスタとして構成されていてもよい。ただし、演算結果記憶部２０８は、検査ＯＳ部３００Ｃの検査部３０１によって参照されるため、検査部３０１によって認識できることが必要である。

（１．２）検査ＯＳ部の構成
検査ＯＳ部３００Ｃは、図２とほぼ同様に構成される。ただし、検査部３０１は、演算結果記憶部２０８に記憶されている演算結果を利用した検査を行う。

また、検査用情報記憶部３０２は、領域情報を含まずに、イメージ情報（例えば、ハッシュ値）を含んでいればよい。検査部３０１は、演算結果記憶部２０８に記憶されている演算結果と、検査用情報記憶部３０２に記憶されているイメージ情報とを比較することで、イメージの改変を検出する。

このように、検査部３０１は、演算処理を行うことなく、比較を行うことでイメージの改変を検出する。

（２）イメージ検査装置の動作
次に、本実施形態に係るイメージ検査装置の動作について説明する。図１１は、本実施形態に係るイメージ検査装置の動作を示すフローチャートである。

ステップＳ３０１において、開放ＯＳ部２００Ｃは、カーネルが管理するメモリマップテーブルなどに基づき、検査対象の格納部２３１を示す情報（メモリのアドレスやページ番号）を取得する。

ステップＳ３０２において、開放ＯＳ部２００Ｃは、検査用情報を取得（参照）する。

ステップＳ３０３において、開放ＯＳ部２００Ｃは、ステップＳ３０２で取得した検査用情報に基づいて格納部２３１を検査する。

ステップＳ３０４において、演算結果記憶部２０８は、ステップＳ３０３で得られた演算結果を記憶する。

ステップＳ３０５において、開放ＯＳ部２００Ｃは、高速検査を実行するか否かを判定する。高速検査を実行する場合、ステップＳ３１１に進む。一方、処理速度は低下するものの信頼性を重視した検査を行う場合、ステップＳ３０６に進み、開放ＯＳ部２００Ｃが検査ＯＳ部３００Ｃに検査を依頼する。

ステップＳ３０６において、検査ＯＳ部３００Ｃは、ステップＳ３０４で記憶された演算結果を取得する。

ステップＳ３０７において、検査ＯＳ部３００Ｃは、検査用情報を取得（参照）する。

ステップＳ３０８において、検査ＯＳ部３００Ｃは、ステップＳ３０７で取得した検査用情報に基づいて格納部２３１を検査する。

ステップＳ３０９において、検査ＯＳ部３００Ｃは、ステップＳ３０８の検査結果を開放ＯＳ部２００Ｃに通知する。

ステップＳ３１０において、開放ＯＳ部２００Ｃは、検査ＯＳ部３００Ｃから検査結果を取得する。

ステップＳ３１１において、開放ＯＳ部２００Ｃは、検査結果が改変有りを示しているか否かを判定する。当該検査結果が改変有り（ＮＧ）を示している場合、ステップＳ３１２に進む。当該検査結果が改変無し（ＯＫ）を示している場合、処理が終了する。

ステップＳ３１２において、開放ＯＳ部２００Ｃは、元のイメージを取得する。

ステップＳ３１３において、開放ＯＳ部２００Ｃは、ステップＳ３１２で取得した元のイメージを、格納部２３１のうち改変が生じた領域にロードする。

（３）作用・効果
開放ＯＳ部２００Ｃは、格納部２３１に格納されたイメージを演算処理により検査する検査部２０７と、当該演算処理の結果を記憶する演算結果記憶部２０８とを備える。検査ＯＳ部３００Ｃは、演算結果記憶部２０８に記憶された演算結果を用いて、格納部２３１に格納されたイメージの検査を行う。

このように、開放ＯＳ部２００Ｃにて検査を行うが、追加プログラムにより検査部２０７が改変される可能性があるため、検査ＯＳ部３００Ｃにて安全な検査を行う。検査ＯＳ部３００Ｃ出の検査は、開放ＯＳ部２００Ｃの演算結果を利用するので、高速な検査が実現されると共に、ＯＳ切り替え頻度を削減可能となる。

［第４実施形態］
上述した各実施形態では、検査ＯＳ部３００Ａ，３００Ｂ，３００Ｃの検査用情報記憶部３０２に記憶された検査用情報を用いた検査が実行されるが、当該検査用情報は、検査の前に記憶しておく必要がある。ところが、一般的なＯＳでは、ドライバなどのカーネルイメージを動的にロード／アンロードする機能を持つので、ロード先のメモリ領域が常に同じであるとは限らない。したがって、イメージのロード先が変わったときに、開放ＯＳが検査ＯＳ内の検査用情報を更新することが望ましい。

そこで、本実施形態では、開放ＯＳが検査ＯＳ内の検査用情報を更新可能な構成について説明する。

（１）イメージ検査装置の構成
図１２は、本実施形態に係るイメージ検査装置の構成を示す機能ブロック図である。

（１．１）開放ＯＳ部の構成
図１２に示すように、開放ＯＳ部２００Ｄは、図２で示した検査依頼通知部２０１、検査結果取得部２０２、ロード部２０３及びイメージ記憶部２０４に加えて、更新要求部２０５及び更新情報記憶部２０６を有する。

更新要求部２０５は、検査用情報の更新を検査ＯＳ部３００Ｄに要求する。仮想化部４００により、開放ＯＳ部２００Ｄは検査ＯＳ部３００Ｄのメモリ領域にアクセスできないため、検査ＯＳ部３００Ａが作成した新たな検査用情報は、一旦、更新情報記憶部２０６に記憶される。更新情報記憶部２０６に記憶される情報は、領域情報又はイメージ情報の少なくとも一方を含む。

更新情報記憶部２０６は、検査ＯＳ部３００Ｄからの設定要求を受けると、新たな検査用情報を記憶する。更新情報記憶部２０６は、上述した演算結果記憶部２０８と同様に、特定のメモリ領域やレジスタを用いることができる。

（１．２）検査ＯＳ部の構成
検査ＯＳ部３００Ｄは、図２で示した検査部３０１、検査用情報記憶部３０２及び検査結果通知部３０３に加えて、設定要求部３０６、更新情報取得部３０７及び検査用情報生成部３０８を有する。

設定要求部３０６は、開放ＯＳ部２００Ｄから更新要求を受けると、更新情報記憶部２０６への設定を開放ＯＳ部２００Ｄに要求する。

更新情報取得部３０７は、更新情報記憶部２０６に格納された情報を取得する。

検査用情報生成部３０８は、更新情報取得部３０７によって取得された情報（領域情報やイメージ情報）から、検査用情報を生成する。検査用情報生成部３０８は、領域情報やイメージ情報のデータ構造のみを変換してもよい。

例えば、検査用情報生成部３０８は、更新情報取得部３０７によって取得された領域情報（開始アドレス及び終了アドレス）を、実際のメモリ領域のサイズに変換する。また、検査用情報生成部３０８は、更新情報取得部３０７によって取得されたイメージそのものを、ハッシュ値に変換する。

（２）イメージ検査装置の動作
次に、本実施形態に係るイメージ検査装置の動作について説明する。図１３は、本実施形態に係るイメージ検査装置の動作を示すフローチャートである。

ステップＳ４０１において、開放ＯＳ部２００Ｄは、カーネルが管理するメモリマップテーブルなどに基づき、検査対象の格納部２３１を示す情報（メモリのアドレスやページ番号）を取得する。

ステップＳ４０２において、開放ＯＳ部２００Ｄは、検査用情報の更新を検査ＯＳ部３００Ｄに要求する。

ステップＳ４０３において、検査ＯＳ部３００Ｄは、新たな検査用情報を更新情報記憶部２０６に格納するよう開放ＯＳ部２００Ｄに要求する。

ステップＳ４０４において、開放ＯＳ部２００Ｄは、新たな検査用情報を更新情報記憶部２０６に格納する。

ステップＳ４０５において、検査ＯＳ部３００Ｄは、開放ＯＳ部２００Ｂから新たな検査用情報を取得する。

ステップＳ４０６において、検査ＯＳ部３００Ｄは、ステップＳ４０５で取得した新たな検査用情報から、検査用情報記憶部３０２に格納すべき検査用情報を生成する。

ステップＳ４０７において、検査ＯＳ部３００Ｄは、ステップＳ４０６で生成した検査用情報を検査用情報記憶部３０２に格納する。

ステップＳ４０８において、検査ＯＳ部３００Ｄは、検査用情報を更新した旨を開放ＯＳ部２００Ｄに通知する。

ステップＳ４０９において、開放ＯＳ部２００Ｄは、検査ＯＳ部３００Ｄからの通知を受け取る。

（３）作用・効果
本実施形態によれば、検査用情報の更新に必要な情報が検査ＯＳ部３００Ｄに渡される前に、当該情報が追加プログラムによる改変を受けることを防ぐために、検査ＯＳ部３００Ｄから開放ＯＳ部２００Ｄへ制御を移した後、検査ＯＳ部３００Ｄへ制御を戻す。これにより、検査用情報が安全に更新される。

［第５実施形態］
上述した第３実施形態では、検査処理を開放ＯＳ及び検査ＯＳで分散させることで、ＯＳ切り替え頻度を低減する構成について説明した。本実施形態では、必要なときにだけ検査を行うようにすることで、開放ＯＳの安全性を保ちつつ、ＯＳ切り替え頻度を低減する構成について説明する。

（１）イメージ検査装置の構成
図１４は、本実施形態に係るイメージ検査装置の構成を示す機能ブロック図である。

図１４に示すように、開放ＯＳ部２００Ｅは、図２で示した検査依頼通知部２０１、検査結果取得部２０２、ロード部２０３及びイメージ記憶部２０４に加えて、アンロード部２１０、ロード禁止部２１１、アンロード禁止部２１２及び隠蔽部２１３を有する。

ロード部２０３は、開放ＯＳ部２００Ｅでドライバを使う処理を行う場合に、ドライバのイメージをロードする。当該イメージは、動的にロード／アンロードされ、他のプログラムによって利用される。

アンロード部２１０は、ドライバを利用するプログラムがすべて終了すると、ドライバイメージをアンロードする。これにより、ドライバイメージに関する情報が開放ＯＳ部２００Ｅから削除される。

なお、ロード禁止部２１１、アンロード禁止部２１２及び隠蔽部２１３は、開放ＯＳ部２００Ｅ内で動作する追加プログラムが、ロード済みのイメージをロードして、保存されているイメージを改変してロードする場合の対策用に設けられている。ロード禁止部２１１は、イメージのロードを禁止する。アンロード禁止部２１２は、アンロードを禁止する。隠蔽部２１３は、ロード部２０３で利用されるイメージにアクセスできないようにする。これにより、追加プログラムによるイメージのロード／アンロードや、改変が禁止される。

（２）イメージ検査装置の動作
次に、本実施形態に係るイメージ検査装置の動作について説明する。図１５は、本実施形態に係るイメージ検査装置の動作を示すフローチャートである。ここでは、ドライバイメージをロードするルーチン（Ｓ５００）と、ドライバイメージをアンロードするルーチン（Ｓ６００）とを分けて説明する。

（２．１）ドライバイメージのロード
ステップＳ５０１において、開放ＯＳ部２００Ｅは、カーネルイメージ（モジュール）を使用する必要があるか否かを判定する。カーネルイメージを使用する必要がある場合、ステップＳ５０２に進む。

ステップＳ５０２において、開放ＯＳ部２００Ｅは、必要なイメージが既にロードされているか否かを判定する。必要なイメージがロードされていない場合、ステップＳ５０３に進む。

ステップＳ５０３において、開放ＯＳ部２００Ｅは、イメージ記憶部２０４からドライバイメージを取得する。

ステップＳ５０４において、開放ＯＳ部２００Ｅは、メモリ領域へイメージをロードする。

ステップＳ５０５において、開放ＯＳ部２００Ｅ及び検査ＯＳ部３００Ｅは、第１実施形態で説明した検査を実行する。

（２．２）ドライバイメージのアンロード
ステップＳ６０１において、開放ＯＳ部２００Ｅは、カーネルイメージ（モジュール）を使用するプロセスが存在するか否かを判定する。カーネルイメージを使用するプロセスが存在する場合、ステップＳ６０２に進む。

ステップＳ６０２において、開放ＯＳ部２００Ｅは、ロードされたイメージを消去する。

ステップＳ６０３において、開放ＯＳ部２００Ｅは、イメージをアンロードする。

ステップＳ６０４において、開放ＯＳ部２００Ｅは、ステップＳ５０５で開始した検査を終了する。

（３）作用・効果
以上のように、開放ＯＳ部２００Ｅの格納部２３１を検査するタイミングが限定される。つまり、動的にロード／アンロードされるイメージについては、ロード中のときのみ検査対象とする。したがって、安全性を保ちつつ、処理負荷を抑えることができる。

［その他の実施形態］
上記のように、本発明は第１〜第５実施形態によって記載したが、この開示の一部をなす論述及び図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施形態、実施例及び運用技術が明らかとなる。

上述した各実施形態に係るイメージ検査装置は、携帯端末装置に限らず、デスクトップＰＣ等の固定型の情報処理装置にも適用できる。

上述した実施形態では、検査ＯＳが、検査を一回だけ実行する、又は検査依頼を受けてから一定期間において定期的に検査を行う場合について説明した。しかし、検査ＯＳは、開放ＯＳから検査依頼を受けてから、検査終了が通知されるまで定期的に検査を行ってもよい。あるいは、検査ＯＳは、普段でも定期的に検査を実行し、検査依頼を受けたときだけ検査頻度を増加させてもよい。

また、仮想化部４００として仮想マシンモニタを採用していたが、仮想マシンモニタに限らず、各ＯＳに仮想マシンを提供せず、物理マシンを共用するような仮想化ソフトウェア等であって採用可能である。

上述した実施形態では、改変検出用の演算としてハッシュ演算を利用していたが、誤り検出が可能な演算処理であればよく、ハッシュ演算に限定されない。

このように本発明は、ここでは記載していない様々な実施形態等を包含するということを理解すべきである。したがって、本発明はこの開示から妥当な特許請求の範囲の発明特定事項によってのみ限定されるものである。

本発明の第１実施形態に係るイメージ検査装置が実装される情報処理装置の概略構成図である。 本発明の第１実施形態に係るイメージ検査装置の機能ブロック図である。 本発明の第１実施形態に係る検査依頼の一例を示す図である。 本発明の第１実施形態に係る検査結果の一例を示す図である。 本発明の第１実施形態に係る検査用情報の一例を示す図である。 本発明の第１実施形態に係るイメージ検査装置の動作を示すフローチャートである。 本発明の第２実施形態に係るイメージ検査装置の機能ブロック図である。 本発明の第２実施形態に係るイメージ検査装置の動作を示すフローチャートである。 本発明の第３実施形態に係るイメージ検査装置の機能ブロック図である。 本発明の第３実施形態に係る演算結果記憶部の構成例を示す図である。 本発明の第３実施形態に係るイメージ検査装置の動作を示すフローチャートである。 本発明の第４実施形態に係るイメージ検査装置の機能ブロック図である。 本発明の第４実施形態に係るイメージ検査装置の動作を示すフローチャートである。 本発明の第５実施形態に係るイメージ検査装置の機能ブロック図である。 本発明の第５実施形態に係るイメージ検査装置の動作を示すフローチャートである。

符号の説明

２０…開放ＯＳ、２１…仮想マシン、３０…検査ＯＳ、３１…仮想マシン、２００Ａ〜２００Ｅ…開放ＯＳ部、２０１…検査依頼通知部、２０２…検査結果取得部、２０３…ロード部、２０４…イメージ記憶部、２０５…更新要求部、２０６…更新情報記憶部、２０７…検査部、２０８…演算結果記憶部、２０９…検査用情報記憶部、２１０…アンロード部、２１１…ロード禁止部、２１２…アンロード禁止部、２１３…隠蔽部、２２１…実行部、２３１…格納部、３００Ａ〜３００Ｅ…検査ＯＳ部、３０１…検査部、３０２…検査用情報記憶部、３０３…検査結果通知部、３０４…ロード部、３０５…イメージ記憶部、３０６…設定要求部、３０７…更新情報取得部、３０８…検査用情報生成部、３３１…格納部、４００…仮想化部、５００…物理マシン

Claims (17)

1. プログラム又はデータの少なくとも一方を含むイメージを格納するメモリ領域と、
   前記メモリ領域に格納された前記イメージを管理する管理ＯＳ部と、
   前記メモリ領域に格納された前記イメージを検査する検査ＯＳ部と
   を備え、
   前記管理ＯＳ部は、所定の条件が満たされたとき、前記メモリ領域に格納された前記イメージの検査依頼を前記検査ＯＳ部に通知し、
   前記検査ＯＳ部は、
   前記管理ＯＳ部からの前記検査依頼に応じて、前記メモリ領域に格納された前記イメージを所定の検査方法で検査する検査部と、
   前記検査部による検査結果を前記管理ＯＳ部に通知する通知部と
   を備えることを特徴とするイメージ検査装置。
2. 前記検査ＯＳ部は、前記検査部が前記イメージを検査する際の判断基準となる検査用情報を予め記憶する検査用情報記憶部をさらに備え、
   前記検査部は、前記検査用情報記憶部に記憶された前記検査用情報を用いて、前記イメージを検査することを特徴とする請求項１に記載のイメージ検査装置。
3. 前記管理ＯＳ部は、前記通知部によって通知された前記検査結果に応じて、前記メモリ領域に前記イメージをロードし直すロード部を備えることを特徴とする請求項１に記載のイメージ検査装置。
4. 前記検査ＯＳ部は、前記検査部による前記検査結果に応じて、前記メモリ領域に前記イメージをロードし直すロード部をさらに備えることを特徴とする請求項１に記載のイメージ検査装置。
5. 前記管理ＯＳ部は、
   前記管理ＯＳ部においてドライバのイメージが実行される場合、前記ドライバのイメージを前記メモリ領域にロードするロード部と、
   前記ドライバのイメージの実行が完了すると、前記メモリ領域にロードされた前記ドライバのイメージをアンロードするアンロード部と
   を備えることを特徴とする請求項１に記載のイメージ検査装置。
6. 前記管理ＯＳ部は、
   前記管理ＯＳ部においてプログラムが実行される際に、前記メモリ領域へのイメージのロードを禁止するロード禁止部と、
   前記メモリ領域にロードされたイメージが前記管理ＯＳ部において実行されるプログラムによってアンドロードされることを禁止するアンロード禁止部と、
   前記メモリ領域にロードされるイメージが前記管理ＯＳ部において実行されるプログラムによってアクセスされることを禁止するアクセス禁止部と
   を備えることを特徴とする請求項１に記載のイメージ検査装置。
7. 前記管理ＯＳ部は、 前記メモリ領域に格納された前記イメージを演算処理により検査する演算処理部と、
   前記演算処理の結果を記憶する演算結果記憶部と
   を備え、
   前記検査部は、前記演算結果記憶部に記憶された前記結果を用いて、前記メモリ領域に格納された前記イメージを検査することを特徴とする請求項１に記載のイメージ検査装置。
8. 前記検査部は、前記演算結果記憶部に記憶された前記結果と、前記検査用情報記憶部に記憶された前記検査用情報とを用いて、前記メモリ領域に格納された前記イメージの検査を行うことを特徴とする請求項７に記載のイメージ検査装置。
9. 前記検査部は、前記メモリ領域に格納された前記イメージの一部を検査することを特徴とする請求項１に記載のイメージ検査装置。
10. 前記検査部は、所定のイベントが発生した場合に、前記メモリ領域に格納された前記イメージの少なくとも一部を検査することを特徴とする請求項１に記載のイメージ検査装置。
11. 前記管理ＯＳ部は、
    前記検査用情報の更新を前記検査ＯＳ部に要求する更新要求部と、
    新たな検査用情報を記憶する更新情報記憶部と
    を備え、
    前記検査ＯＳ部は、
    前記更新情報記憶部に記憶されている前記新たな検査用情報を取得する更新情報取得部と、
    前記更新情報取得部によって取得された前記新たな検査用情報を前記検査用情報記憶部に格納する検査用情報生成部と
    をさらに備えることを特徴とする請求項２に記載のイメージ検査装置。
12. 前記管理ＯＳ部は、前記メモリ領域に格納された前記イメージが断続的に前記メモリ領域に格納される動的なイメージである場合、前記動的なイメージが前記メモリ領域に格納されているときのみ、前記動的なイメージを検査対象とすることを特徴とする請求項１に記載のイメージ検査装置。
13. 前記管理ＯＳ部は、前記管理ＯＳ部の処理負荷が閾値未満であるとき、前記管理ＯＳ部において実行中のプログラムがシステムコールを発行したとき、前記メモリ領域に格納された前記イメージを利用中のプログラムが存在するとき、のいずれかのタイミングで、前記検査依頼を前記検査ＯＳ部に通知することを特徴とする請求項１に記載のイメージ検査装置。
14. 前記検査部は、前記検査依頼を受け取る前よりも、前記検査依頼を受けた後の検査実行回数を増加させることを特徴とする請求項１に記載のイメージ検査装置。
15. プログラム又はデータの少なくとも一方を含むイメージを格納するメモリ領域、及び前記メモリ領域に格納された前記イメージを検査する他のＯＳ装置とともに用いられるＯＳ装置であって、
    所定の条件が満たされたとき、前記メモリ領域に格納された前記イメージの検査依頼を前記他のＯＳ装置に通知する通知部を備えることを特徴とするＯＳ装置。
16. プログラム又はデータの少なくとも一方を含むイメージを格納するメモリ領域、及び前記メモリ領域に格納された前記イメージを管理する他のＯＳ装置とともに用いられるＯＳ装置であって、
    前記他のＯＳ装置からの検査依頼に応じて、前記メモリ領域に格納された前記イメージを所定の検査方法で検査する検査部と、
    前記検査部による検査結果を前記他のＯＳ装置に通知する通知部と
    を備えることを特徴とするＯＳ装置。
17. プログラム又はデータの少なくとも一方を含むイメージが格納されるメモリ領域と、
    前記メモリ領域に格納された前記イメージを管理する管理ＯＳ部と、
    前記メモリ領域に格納された前記イメージを検査する検査ＯＳ部と
    を備えるイメージ検査装置に適用されるイメージ検査方法であって、
    前記管理ＯＳ部が、所定の条件が満たされたとき、前記メモリ領域に格納された前記イメージの検査依頼を前記検査ＯＳ部に通知するステップと、
    前記検査ＯＳ部が、前記管理ＯＳ部からの前記検査依頼に応じて、前記メモリ領域に格納された前記イメージを所定の検査方法で検査するステップと、
    前記検査ＯＳ部が、前記検査するステップで得られた検査結果を前記管理ＯＳ部に通知するステップと
    を備えることを特徴とするイメージ検査方法。

Images