(57)【要約】  履歴記憶領域（１０６）は、複数のデータの各々についてファイルシステムを経由したアクセス回数を記憶する。キャッシュ管理部（１１９）は、ファイルシステムを経由しない複数のデータへのアクセスが発生する際に、複数のデータのアクセス回数に基づき決定された閾値以上のアクセス回数が履歴記憶領域（１０６）に記憶されているデータを上書き禁止データに設定してディスクキャッシュ領域（１０８）にキャッシュする。
2019123519.tif 000002
【特許請求の範囲】
【請求項１】
キャッシュ領域と、
複数のデータの各々についてファイルシステムを経由したアクセス回数を記憶するアクセス回数記憶領域と、
前記ファイルシステムを経由しない前記複数のデータへのアクセスが発生する際に、前記複数のデータのアクセス回数に基づき決定された閾値以上のアクセス回数が前記アクセス回数記憶領域に記憶されているデータを上書き禁止データに設定して前記キャッシュ領域にキャッシュするキャッシュ管理部とを有する情報処理装置。
【請求項２】
前記キャッシュ管理部は、
前記閾値未満のアクセス回数が前記アクセス回数記憶領域に記憶されているデータを、前記上書き禁止データに上書きすることなく前記キャッシュ領域にキャッシュする請求項１に記載の情報処理装置。
【請求項３】
前記キャッシュ管理部は、
前記キャッシュ領域にキャッシュするデータに対応付けて、前記アクセス回数記憶領域に記憶されているアクセス回数を、前記キャッシュ領域に書き込む請求項１又は２に記載の情報処理装置。
【請求項４】
前記キャッシュ管理部は、
前記キャッシュ領域にキャッシュされているデータに前記ファイルシステムを経由したアクセスが前記アクセス回数に相当する回数あった場合に、前記キャッシュ領域内にキャッシュされているデータを無効化する請求項３に記載の情報処理装置。
【請求項５】
前記キャッシュ管理部は、
前記複数のデータの完全性及び真正性の検証のために前記ファイルシステムを経由しない前記複数のデータへのアクセスが発生する際に、前記閾値以上のアクセス回数が前記アクセス回数記憶領域に記憶されているデータを前記上書き禁止データに設定して前記キャッシュ領域にキャッシュする請求項１に記載の情報処理装置。
【請求項６】
前記アクセス回数記憶領域は、
アプリケーションプログラムを構成する複数のコードデータの各々について前記ファイルシステムを経由したアクセス回数を記憶し、
前記キャッシュ管理部は、
前記アプリケーションプログラムを構成する前記複数のコードデータの前記完全性及び真正性の検証のために前記ファイルシステムを経由しない前記複数のコードデータへのアクセスが発生する際に、前記閾値以上のアクセス回数が前記アクセス回数記憶領域に記憶されているコードデータを前記上書き禁止データに設定して前記キャッシュ領域にキャッシュする請求項５に記載の情報処理装置。
【請求項７】
前記アクセス回数記憶領域は、
複数のアプリケーションプログラムについて、アプリケーションプログラムごとに、アプリケーションプログラムを構成する複数のコードデータの各々について前記ファイルシステムを経由したアクセス回数を記憶し、
前記キャッシュ管理部は、
前記完全性及び真正性の検証のために前記ファイルシステムを経由しない前記複数のアプリケーションプログラムの複数のコードデータへのアクセスが発生する際に、アプリケーションプログラムごとに、前記閾値以上のアクセス回数が前記アクセス回数記憶領域に記憶されているコードデータを前記上書き禁止データに設定して前記キャッシュ領域にキャッシュする請求項６に記載の情報処理装置。
【請求項８】
前記キャッシュ管理部は、
アプリケーションプログラムごとに決定された閾値を用い、
アプリケーションプログラムごとに、対応する閾値以上のアクセス回数が前記アクセス回数記憶領域に記憶されているコードデータを前記上書き禁止データに設定して前記キャッシュ領域にキャッシュする請求項７に記載の情報処理装置。
【請求項９】
前記情報処理装置は、
前記アクセス回数記憶領域がデバイスドライバ用のキャッシュメモリに設けられている請求項１に記載の情報処理装置。
【請求項１０】
キャッシュ領域と、
複数のデータの各々についてファイルシステムを経由したアクセス回数を記憶するアクセス回数記憶領域とを有するコンピュータが、
前記ファイルシステムを経由しない前記複数のデータへのアクセスが発生する際に、前記複数のデータのアクセス回数に基づき決定された閾値以上のアクセス回数が前記アクセス回数記憶領域に記憶されているデータを上書き禁止データに設定して前記キャッシュ領域にキャッシュする情報処理方法。
【請求項１１】
キャッシュ領域と、
複数のデータの各々についてファイルシステムを経由したアクセス回数を記憶するアクセス回数記憶領域とを有するコンピュータに、
前記ファイルシステムを経由しない前記複数のデータへのアクセスが発生する際に、前記複数のデータのアクセス回数に基づき決定された閾値以上のアクセス回数が前記アクセス回数記憶領域に記憶されているデータを上書き禁止データに設定して前記キャッシュ領域にキャッシュするキャッシュ管理処理を実行させる情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法及び情報処理プログラムに関する。
【背景技術】
【０００２】
一般的なオペレーティングシステム（ＯＳ）では、ストレージから読み出されたデータがメモリ（主にＤＲＡＭ：Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）にキャッシュされる。このようにすることで、次回に同一のデータが読み出されるときにストレージへのアクセスを不要とし、データアクセスを高速化している。また、キャッシュ領域（以下、ディスクキャッシュともいう）にキャッシュされたデータは、ＬｅａｓｔＲｅｃｅｎｔｌｙＵｓｅｄなどのアルゴリズムにより廃棄される。このようなアルゴリズムによってデータを廃棄することで、キャッシュ領域を効率的に使用することができる。
従来のＯＳでは、Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）プリフェッチの効率やメモリ使用状況の情報に基づいて、ページに優先順位を与えることで読み出すディスクブロックを選択し、ファイルアクセスを高速化している（例えば、特許文献１）。
また、稼動状態のメモリの状況をストレージに記録しておき、情報処理装置の次回起動時にストレージに記録しているメモリの状況をメモリに戻すことにより、メモリ読み出しにおける重複したアクセスを防止する方法も提案されている（例えば、特許文献２）。
更に、低速なストレージとＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）との間に高速な記憶媒体を配置し、低速なストレージから読み出されたデータを高速な記憶媒体に一時的に格納するという、キャッシュの基本的な方式も提案されている（例えば、特許文献３）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特許第４７２４３６２号
【特許文献２】特許第６０４６９７８号
【特許文献３】特開昭５８−２２４４９１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来技術では、データを使用する主体と、データをキャッシュする主体が同じであることを前提としている。従って、従来技術によれば、データを使用する主体とデータをキャッシュする主体が異なる場合には、データをキャッシュする主体とは異なる主体によって行われたデータ読み出し履歴が有効活用されない。このため、従来技術では、このような場合に、有効にデータアクセスの高速化が図れないという課題がある。具体的には、ＯＳによって提供されているファイルシステムを経由せずに生成されたディスクキャッシュでは、ファイルシステムを経由したデータの読み出し履歴が活用されていない。このため、ファイルシステムを経由したデータ読み出しで頻繁に使用されるキャッシュデータが、ファイルシステムを経由しないデータ読み出しの際に上書きされてしまう可能性があり、性能劣化が発生する。【０００５】
また、組込みプラットフォームでは、ＯＳやアプリケーションプログラム（以下、単にアプリケーションという）が格納される領域は読み出し専用領域であることが多い。このため、情報処理装置の電源投入からアプリケーションが起動するまでのシーケンスが固定的であることが多い。また、ストレージにアクセスするデータブロックの位置やアクセスタイミングについても決定論的であることが多い。【０００６】
組込みプラットフォームでセキュアブートを行う場合、アプリケーションが格納されているパーティションを使用する前に、アプリケーションを構成するコードデータの完全性及び真正性の検証を行う必要がある。そのため、ＯＳが起動してファイルシステム経由でアプリケーションが読み出される前に、アプリケーションを構成するコードデータの完全性及び真正性の検証が完了している必要がある。すなわち、パーティションの検証（アプリケーションを構成するコードデータの完全性及び真正性の検証）では、ファイルシステムを経由せずに、デバイスドライバから直接アプリケーションのコードデータが読み出される。このため、パーティションの検証で読み出されたコードデータは、ファイルシステムのディスクキャッシュに含まれないという課題が発生する。【０００７】
本発明は、このような課題を解決することを主な目的とする。より具体的には、本発明は、ファイルシステムを経由するデータアクセスと、ファイルシステムを経由しないデータアクセスとが発生する構成において、効率的なキャッシュ管理を行うことを目的としている。
【課題を解決するための手段】
【０００８】
本発明に係る情報処理装置は、
キャッシュ領域と、
複数のデータの各々についてファイルシステムを経由したアクセス回数を記憶するアクセス回数記憶領域と、
前記ファイルシステムを経由しない前記複数のデータへのアクセスが発生する際に、前記複数のデータのアクセス回数に基づき決定された閾値以上のアクセス回数が前記アクセス回数記憶領域に記憶されているデータを上書き禁止データに設定して前記キャッシュ領域にキャッシュするキャッシュ管理部とを有する。
【発明の効果】
【０００９】
本発明によれば、ファイルシステムを経由するデータアクセスと、ファイルシステムを経由しないデータアクセスとが発生する構成において、効率的なキャッシュ管理を行うことができる。
【図面の簡単な説明】
【００１０】
【図１】実施の形態１に係る情報処理装置のハードウェア構成例を示す図。
【図２】実施の形態１に係る情報処理装置の機能構成例を示す図。
【図３】実施の形態１に係る履歴記憶領域の構成例を示す図。
【図４】実施の形態１に係るディスクキャッシュ領域の構成例を示す図。
【図５】実施の形態２に係る情報処理装置の機能構成例を示す図。
【図６】実施の形態２に係る履歴記憶領域の構成例を示す図。
【図７】実施の形態３に係る情報処理装置の機能構成例を示す図。
【図８】実施の形態１に係る情報処理装置の動作例を示すフローチャート。
【図９】実施の形態１に係る情報処理装置の動作例を示すフローチャート。
【図１０】実施の形態１に係る情報処理装置の動作例を示すフローチャート。
【図１１】実施の形態１に係る情報処理装置の動作例を示すフローチャート。
【図１２】実施の形態１に係る情報処理装置の動作例を示すフローチャート。
【図１３】実施の形態１に係る情報処理装置の動作例を示すフローチャート。
【発明を実施するための形態】
【００１１】
以下、本発明の実施の形態について、図を用いて説明する。以下の実施の形態の説明及び図面において、同一の符号を付したものは、同一の部分又は相当する部分を示す。
【００１２】
実施の形態１．
＊＊＊構成の説明＊＊＊
本実施の形態では、組込みプラットフォームにおいてセキュアブートを適用するときに発生する課題を解決する構成を説明する。より具体的には、ファイルシステムを経由しないストレージからの読み出しをファイルシステムのディスクキャッシュとして利用可能にし、当該ディスクキャッシュの廃棄アルゴリズムに決定論的な手法を適用することで効率的なキャッシュ管理を行うことができる構成を説明する。
【００１３】
図１は、本実施の形態に係る情報処理装置１００のハードウェア構成例を示す。
本実施の形態に係る情報処理装置１００は、コンピュータである。
図１に示すように、情報処理装置１００は、ハードウェアとして、プロセッサ１０１、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１０３、ストレージ１０４及びＩ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）装置１０５を備える。これらプロセッサ１０１、ＲＡＭ１０３、ストレージ１０４及びＩ／Ｏ装置１０５は、バス１０２で接続される。
プロセッサ１０１は、情報処理装置１００の制御を行う演算装置である。プロセッサ１０１は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）である。情報処理装置１００は、複数のプロセッサ１０１を備えていてもよい。
ＲＡＭ１０３は、プロセッサ１０１上で実行中のプログラム、スタック、変数などが格納される揮発性記憶装置である。
ストレージ１０４は、プログラムやデータなどを格納しておく不揮発性記憶装置である。ストレージ１０４は、例えば、ｅＭＭＣ（ｅｍｂｅｄｄｅｄ  Ｍｕｌｔｉ  Ｍｅｄｉａ  Ｃａｒｄ）である。
Ｉ／Ｏ装置１０５はディスプレイやキーボードなどの外部デバイスを接続するためのインタフェースである。
本実施の形態では、プロセッサ１０１、ＲＡＭ１０３、ストレージ１０４及びＩ／Ｏ装置１０５は、バス１０２で接続されることとしているが、他の接続手段によって接続されてもよい。
なお、情報処理装置１００で行われる動作は、情報処理方法及び情報処理プログラムに相当する。
【００１４】
ストレージ１０４には、後述する検証プログラム１１０、アプリケーション１１１及びオペレーティングシステム１１２の機能を実現するプログラムが記憶されている。これら検証プログラム１１０、アプリケーション１１１及びオペレーティングシステム１１２の機能を実現するプログラムはＲＡＭ１０２にロードされる。そして、プロセッサ１０１がこれらプログラムを実行して、後述する検証プログラム１１０、アプリケーション１１１及びオペレーティングシステム１１２の動作を行う。
図１では、プロセッサ１０１が検証プログラム１１０、アプリケーション１１１及びオペレーティングシステム１１２の機能を実現するプログラムを実行している状態を模式的に表している。
【００１５】
また、検証プログラム１１０、アプリケーション１１１及びオペレーティングシステム１１２の処理の結果を示す情報、データ、信号値及び変数値の少なくともいずれかが、ストレージ１０４、ＲＡＭ１０３及びプロセッサ１０１内のレジスタの少なくともいずれかに記憶される。
また、検証プログラム１１０、アプリケーション１１１及びオペレーティングシステム１１２は、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ブルーレイ（登録商標）ディスク、ＤＶＤ等の可搬記録媒体に格納されていてもよい。
【００１６】
また、情報処理装置１００は、処理回路により実現されてもよい。処理回路は、例えば、ロジックＩＣ（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）、ＧＡ（Ｇａｔｅ  Ａｒｒａｙ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）である。
なお、本明細書では、プロセッサ１０１と処理回路との上位概念を、「プロセッシングサーキットリー」という。
つまり、プロセッサ１０１と処理回路とは、それぞれ「プロセッシングサーキットリー」の具体例である。
【００１７】
図２は、本実施の形態に係る情報処理装置１００の機能構成例を示す。
情報処理装置１００では、オペレーティングシステム１１２が動作している。また、オペレーティングシステム１１２上で検証プログラム１１０及びアプリケーション１１１が動作している。
検証プログラム１１０は、セキュアブートのための検証を行う。すなわち、検証プログラム１１０は、アプリケーション１１１の完全性及び真正性の検証を行う。
【００１８】
図２では、オペレーティングシステム１１２の内部構成のうち、ファイルシステムに関係する構成を示している。
上位ファイルシステム１１５及び下位ファイルシステム１１４は、アプリケーション１１１から使用可能なファイルアクセスを抽象化した実際のファイルシステムを構成する。
上位ファイルシステム１１５及び下位ファイルシステム１１４は、オペレーティングシステムによっては単一のファイルシステムとして実装されている場合がある。本実施の形態に係る情報処理装置１００は、ファイルシステムの多重化構成には依存せずに実施可能である。
【００１９】
デバイスドライバ１１３は、デバイスアクセス部１１６、ブロックアクセスＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）部１１７、アクセス回数管理部１１８及びキャッシュ管理部１１９を含む。
【００２０】
デバイスアクセス部１１６は、デバイスであるストレージ１０４にアクセスする。
ブロックアクセスＡＰＩ１１７は、下位ファイルシステム１１４及び検証プログラム１１０から直接アクセス可能なＡＰＩである。
【００２１】
アクセス回数管理部１１８は、アプリケーション１１１を構成する複数のコードデータの各々について上位ファイルシステム１１５及び下位ファイルシステム１１４を経由したアクセス回数を計数する。また、アクセス回数管理部１１８は、コードデータごとのアクセス回数の計数結果に基づき、アクセス回数の閾値を決定する。
アクセス回数管理部１１８が計数したアクセス回数及びアクセス回数管理部１１８が決定した閾値は、ストレージ１０４の履歴記憶領域１０６で記憶される。
【００２２】
キャッシュ管理部１１９は、上位ファイルシステム１１５及び下位ファイルシステム１１４を経由しないアクセスが発生する際に、閾値以上のアクセス回数が履歴記憶領域１０６に記憶されているコードデータを上書き禁止データに設定してディスクキャッシュ領域１０８にキャッシュする。具体的には、検証プログラム１１０がアプリケーション１１１を構成する複数のコードデータの完全性及び真正性の検証を行う際に、上位ファイルシステム１１５及び下位ファイルシステム１１４を経由しないアクセスが発生する。キャッシュ管理部１１９は、検証プログラム１１０による検証の際に、閾値以上のアクセス回数が履歴記憶領域１０６に記憶されているコードデータを抽出し、抽出したコードデータを上書き禁止データに設定してディスクキャッシュ領域１０８にキャッシュする。
また、キャッシュ管理部１１９は、履歴記憶領域１０６に記憶されている上書き禁止データのアクセス回数を、上書き禁止データに対応付けて、ディスクキャッシュ領域１０８に書き込む。
更に、キャッシュ管理部１１９は、閾値未満のアクセス回数が履歴記憶領域１０６に記憶されているコードデータを、上書き禁止データに上書きすることなくディスクキャッシュ領域１０８にキャッシュする。
キャッシュ管理部１１９が行う処理は、キャッシュ管理処理に相当する。
【００２３】
オペレーティングシステム１１２が利用するディスクキャッシュ領域１０８はＲＡＭ１０３上に確保される。
ディスクキャッシュ領域１０８はキャッシュ領域に相当する。
【００２４】
ストレージ１０４には、アプリケーションパーティション１０７、履歴記憶領域１０６及びファームウェア領域１０９が含まれる。
アプリケーションパーティション１０７には、アプリケーション１１１の実行イメージが格納されている。
履歴記憶領域１０６には、アクセス回数管理部１１８が計数したコードデータごとのアクセス回数とアクセス回数管理部１１８が決定した閾値が格納されている。履歴記憶領域１０６は、アクセス回数記憶領域に相当する。
ファームウェア領域１０９には、オペレーティングシステム１１２が格納されている。
【００２５】
図３は、図２で示した履歴記憶領域１０６の構成例を示す。
履歴記憶領域１０６では、アプリケーションパーティション１０７のサイズをストレージ１０４へのアクセスに使用するブロックサイズで除算した個数分のエントリ１２０が存在する。各エントリ１２０は、アプリケーション１１１の実行イメージをブロックサイズで分割して得られるコードデータに対応する。つまり、図３の例では、アプリケーション１１１の実行イメージは、Ｎ個のコードデータに分割される。
オフセットは各エントリ１２０に対して番号を振るために便宜的に示しているものである。このため、履歴記憶領域１０６はアクセス回数の値と閾値１２１のみを記憶している。本実施の形態では、アクセス回数の１エントリのサイズは１バイトである。しかし、ストレージ１０４の容量に応じて１エントリのサイズは任意に変更可能である。
閾値１２１は、アクセス回数の１エントリと同じサイズを持つ。つまり、本実施の形態では、閾値１２１のサイズは１バイトである。閾値１２１は、前述したように、キャッシュ管理部１１９がコードデータを上書き禁止データに設定するか否かを判定するために用いられる。
【００２６】
図４は、図２で示したＲＡＭ１０３内のディスクキャッシュ領域１０８の構成例を示す。
エントリ１２２は、キャッシュデータ１２５のエントリである。エントリ１２２は連続であっても、不連続であっても構わない。
エントリ１２２の配列は、デバイスドライバ１１３によるバッファの確保の方法に依存する。本実施の形態に係る情報処理装置１００は、このデバイスドライバ１１３のバッファ確保の方法には依存せずに実施可能である。
各エントリ１２２では、キャッシュデータ１２５と、上書き禁止フラグ１２３と、リファレンスカウント１２４とが格納される。
キャッシュデータ１２５は、キャッシュ管理部１１９によりキャッシュされたアプリケーション１１１のコードデータである。
キャッシュ管理部１１９は上書き禁止フラグ１２３をＯＮにすることにより、キャッシュデータ１２５を上書き禁止データに設定する。
なお、上書き禁止フラグ１２３は、ＯＮ／ＯＦＦが判別できればよいため、少なくとも１ビットで構成されている。
リファレンスカウント１２４は、履歴記憶領域１０６内のアクセス回数と同じ値である。このため、リファレンスカウント１２４には、アクセス回数と同じサイズが必要である。
【００２７】
＊＊＊動作の説明＊＊＊
次に、本実施の形態に係る情報処理装置１００の動作例を説明する。
【００２８】
まず、決定論的なキャッシュ廃棄のデータを学習するために、情報処理装置１００を通常起動し、アプリケーション１１１を実行する手順を、図８及び図９を参照して実施する。
【００２９】
情報処理装置１００が起動されると（ステップ５０１）、搭載されているオペレーティングシステム１１２が起動する（ステップ５０２）。
そして、オペレーティングシステム１１２の各種サービスが実行された後、アプリケーション１１１の実行が開始される（ステップ５０３）。このときローダがストレージ１０４からアプリケーション１１１の実行イメージの読み出しを開始する（ステップ５０４）。
アプリケーション１１１の実行イメージの読み出しでは、上位ファイルシステム１１５が下位ファイルシステム１１４にアプリケーション１１１の実行イメージの読み出しを要求する（ステップ５０５）。次に、上位ファイルシステム１１５からの要求に基づき、下位ファイルシステム１１４がブロックアクセスＡＰＩ部１１７にアプリケーション１１１の実行イメージの読み出しを要求する（ステップ５０６）。次に、下位ファイルシステム１１４からの要求に基づき、ブロックアクセスＡＰＩ部１１７がデバイスアクセス部１１６にアプリケーション１１１の実行イメージの読み出しを要求する（ステップ５０７）。次に、デバイスアクセス部１１６がストレージ１０４のブロック番号を算出する（ステップ５０８）。
次に、デバイスアクセス部１１６が、ステップ５０８で算出したブロック番号のデータをストレージから読み出すと、アプリケーション１１１の実行イメージの一部であるコードデータが取得される（ステップ５０９）。
このとき、アクセス回数管理部１１８が、履歴記憶領域１０６の当該ブロック番号に対応するオフセットのアクセス回数１２０に１を加算する（ステップ５１０）。
また、キャッシュ管理部１１９は、読み出されたコードデータをディスクキャッシュ領域１０８にキャッシュしてもよい。
なお、アプリケーション１１１の読み出しが完了しない場合（ステップ５１１でＮＯ）は、デバイスアクセス部１１６が、次に読み出すブロック番号を算出する（ステップ５１２）。
そして、算出したブロック番号のコードデータの読み出しと、当該ブロック番号に対応するオフセットのアクセス回数の加算をくり返す（ステップ５０９、５１０）。
【００３０】
アプリケーション１１１のロードが完了すると、ブロックアクセスＡＰＩ部１１７がクローズされる（ステップ５１２−５１６）。
ブロックアクセスＡＰＩ部１１７のクローズを契機に、アクセス回数管理部１１８がアクセス回数の閾値を算出し、算出した閾値を履歴記憶領域１０６に閾値１２１として書き込む（ステップ５１７）。
より具体的には、アクセス回数管理部１１８は、履歴記憶領域１０６のエントリ１２０をアクセス回数の降順にソートする。そして、アクセス回数管理部１１８は、アクセス回数が大きいエントリから順に、ディスクキャッシュ領域１０８で確保可能なブロック数の半分と同数のエントリ１２０を選択する。そして、アクセス回数管理部１１８は、選択したエントリ１２０のアクセス回数の中で最も少ないアクセス回数を閾値として決定する。
例えば、履歴記憶領域１０６の総エントリ数が２０であり、ディスクキャッシュ領域１０８で確保可能なブロック数が２０であれば、アクセス回数管理部１１８は、２０個のエントリの中からアクセス回数が大きい順に１０個のエントリを選択する。そして、アクセス回数管理部１１８は、選択した１０個のエントリのアクセス回数の中で最も少ないアクセス回数を閾値として決定する。
アクセス回数管理部１１８は、理論的にはディスクキャッシュ領域１０８で確保可能なブロック数と同数のエントリを選択することが可能である。しかし、このような選択を行うと、新たにストレージ１０４から読み出されたコードデータをディスクキャッシュ領域１０８に格納できなくなるため、本実施の形態では、ディスクキャッシュ領域１０８で確保可能なブロック数の半分と同数のエントリを選択することとしている。
【００３１】
次に、上位ファイルシステム１１５及び下位ファイルシステム１１４を経由せずに、ストレージ１０４のアプリケーションパーティション１０７からアプリケーション１１１のコードデータを読み出す場合の動作を図１０及び図１１を参照して説明する。
以下では、セキュアブートのように検証プログラム１１０がアプリケーション１１１の完全性及び真正性の検証を行う際に、上位ファイルシステム１１５及び下位ファイルシステム１１４を経由せずにデバイスドライバ１１３がアプリケーションパーティション１０７からアプリケーションのコードデータを読み出す場合の動作を説明する。
【００３２】
上位ファイルシステム１１５及び下位ファイルシステム１１４がストレージ１０４のアプリケーションパーティション１０７を使用できるようになる前に情報処理装置１００が起動されると（ステップ６０１）、搭載されているオペレーティングシステム１１２が起動する（ステップ６０２）。
また、検証プログラム１１０が起動する（ステップ６０３）。
なお、情報処理装置１００の起動時（ステップ６０１）には、ディスクキャッシュ領域１０８にはキャッシュデータ１２５は格納されていない。
【００３３】
次に、デバイスアクセス部１１６が、アプリケーションパーティション１０７の先頭のブロックからコードデータを読み出す（ステップ６０４）。デバイスアクセス部１１６は、読み出したコードデータをキャッシュ管理部１１９に転送し、また、当該コードデータのブロック番号を通知する。
【００３４】
キャッシュ管理部１１９は、履歴記憶領域１０６から、デバイスアクセス部１１６から通知されたブロック番号に対応するオフセットのアクセス回数を取得する（ステップ６０６）。
次に、キャッシュ管理部１１９は、ステップ６０６で取得したアクセス回数が閾値１２１以上であるか否かを判定する（ステップ６０７）。
ステップ６０６で取得したアクセス回数が閾値１２１以上である場合（ステップ６０７でＹＥＳ）は、キャッシュ管理部１１９は、ディスクキャッシュ領域１０８に上書き禁止のフラグ１２３を設定して当該コードデータをキャッシュデータ１２５としてディスクキャッシュ領域１０８に書き込む（ステップ６０８）。前述したように、上書き禁止のフラグ１２３を設定することで、当該コードデータは上書き禁止データとして扱われる。
また、キャッシュ管理部１１９は、履歴記憶領域１０６のアクセス回数の値を、リファレンスカウント１２４としてディスクキャッシュ領域１０８に書き込む（ステップ６０８）。
一方、ステップ６０６で取得したアクセス回数が閾値１２１未満である場合（ステップ６０７でＮＯ）は、キャッシュ管理部１１９は、当該コードデータをキャッシュデータ１２５としてディスクキャッシュ領域１０８に書き込む（ステップ６０９）。この場合は、上書き禁止のフラグ１２３が設定されないので、当該コードデータは上書き禁止データとして扱われない。
また、キャッシュ管理部１１９は、履歴記憶領域１０６のアクセス回数の値を、リファレンスカウント１２４としてディスクキャッシュ領域１０８に書き込む（ステップ６０９）。
【００３５】
次に、検証プログラム１１０が、ステップ６０６で読み出されたコードデータの完全性及び真正性を検証する（ステップ６１０）。
次に、デバイスアクセス部１１６が、アクセス先のブロック番号を１つ増加する（ステップ６１１）。
以降、アクセス先のブロック番号がアプリケーションパーティション１０７の総ブロック数を超えるまで、ステップ６０５からステップ６１１の動作が繰り返される（ステップ６０４、ステップ６１２）。つまり、ステップ６０５からステップ６１１の動作がアプリケーションパーティション１０７全体に渡って繰り返される。
【００３６】
検証プログラム１１０が対象とするアプリケーションパーティション１０７は、一般にディスクキャッシュ領域１０８の容量よりも大きいため、古いキャッシュデータ１２５は後に読み出されたコードデータで上書きされる。
キャッシュ管理部１１９は、コードデータをディスクキャッシュ領域１０８に書き込む際に、上書き禁止フラグ１２３がＯＮになっていない領域、すなわち、上書き可能な領域を探し、上書き可能な領域にコードデータを書き込む。上書き可能な領域に既にコードデータが格納されている場合は、当該コードデータは、新たなコードデータによって上書きされる。
上書き禁止フラグ１２３がＯＮになっている領域のキャッシュデータ１２５（すなわち、上書き禁止データ）は他のコードデータによって上書きされることなく、ディスクキャッシュ領域１０８で保持される。
【００３７】
次に、上位ファイルシステム１１５及び下位ファイルシステム１１４を経由してアプリケーション１１１をロードし、実行する際の動作例を図１２及び図１３を参照して説明する。
【００３８】
検証プログラム１１０の実行後に、引き続いてアプリケーション１１１の実行が開始される（ステップ７０１）。
ローダがストレージ１０４からアプリケーション１１１の実行イメージのロード作業を開始し、上位ファイルシステム１１５が読み出しを開始する（ステップ７０２、７０３）。このとき、読み出し対象のブロックがディスクキャッシュ領域１０８に存在しているか否かが判定される（ステップ７０４）。具体的には、図８のステップ５０５から５０９の手順が行われ、キャッシュ管理部１１９が、ステップ５０９で算出されたブロック番号のコードデータがディスクキャッシュ領域１０８に存在しているか否かを判定する。
読み出し対象のコードデータがディスクキャッシュ領域１０８に存在している場合（ステップ７０４でＹＥＳ）は、キャッシュ管理部１１９が、ディスクキャッシュ領域１０８から該当するキャッシュデータ１２５を読み出し、読み出したキャッシュデータ１２５をローダに転送する（ステップ７０５）。具体的には、キャッシュ管理部１１９がディスクキャッシュ領域１０８から読み出したキャッシュデータ１２５をブロックアクセスＡＰＩ部１１７に転送し、その後、図９のステップ５１４及び５１５の手順が行われる。
また、キャッシュ管理部１１９は、読み出したキャッシュデータ１２５のリファレンスカウント１２４を１減算する（ステップ７０６）。
リファレンスカウント１２４を１減算した結果、リファレンスカウント１２４の値が０となった場合（ステップ７０７でＹＥＳ）は、キャッシュ管理部１１９は、該当する領域を開放し、当該領域を新しいディスクキャッシュとして使用可能にする（ステップ７０８）。すなわち、キャッシュ管理部１１９は、図３に示すアクセス回数に相当する回数のアクセスがキャッシュデータにあった場合に、当該キャッシュデータを無効化する。
一方、ステップ７０４において読み出し対象のブロックがディスクキャッシュ領域１０８に存在しない場合（ステップ７０４でＮＯ）は、上位ファイルシステム１１５はストレージ１０４から該当するコードデータを読み出し、読み出したコードデータをローダに転送する（ステップ７０９）。具体的には、図８のステップ５０９及び図９のステップ５１３から５１５の手順が行われる。
ロードが完了していれば（ステップ７１０でＹＥＳ）、処理完了である。
一方、実行イメージのロードが完了していない場合（ステップ７１０でＮＯ）は、デバイスアクセス部１１６が次にアクセスするブロック番号を算出し（ステップ７１１）、ステップ７０４以降の手順がくり返される。
【００３９】
＊＊＊実施の形態の効果の説明＊＊＊
以上のように、本実施の形態では、セキュアブートのようなファイルシステムを経由しないデータアクセスにより得られたキャッシュデータのうち、ファイルシステムを経由するデータアクセスで頻繁にアクセスされるデータのキャッシュデータは上書きされずに維持される。このため、ファイルシステムを経由するデータアクセスの際に、キャシュデータを利用して高速にデータアクセスを行うことができる。
従って、本実施の形態によれば、ファイルシステムを経由するデータアクセスと、ファイルシステムを経由しないデータアクセスとが発生する構成において、効率的なキャッシュ管理を行うことができる。
【００４０】
セキュアブートの対象となるパーティションは読み出し専用であるが、従来技術では、ファイルシステムで実装されている従来のキャッシュ廃棄アルゴリズムが使用され、アプリケーション実行時の情報を用いて廃棄すべきキャッシュデータが判定される。このため、従来技術では、効率的なキャッシュデータの廃棄判定を行うことができない。
本実施の形態では、あらかじめアプリケーションの実行記録を取ることで、アプリケーションパーティション中で頻繁に使用されるブロックの学習と、当該ブロックに対するキャッシュデータを廃棄するまでの読み出し回数を把握することができる。また、本実施の形態では、キャシュデータを廃棄するまでの読み出し回数を把握することにより、読み出し回数が規定数に到達したら該当するキャシュデータを廃棄することができる。これにより、キャッシュデータを廃棄した領域を新規のディスクキャッシュとして使用することが可能になり、ディスクキャッシュの効率的な利用が可能になる。
【００４１】
実施の形態２．
実施の形態１では、アプリケーションが１つの場合に高速なデータ読み出しとディスクキャッシュの効率的な利用を可能にする構成を説明した。本実施の形態では、アプリケーションが複数存在する場合に高速なデータ読み出しとディスクキャッシュの効率的な利用を可能にする構成を説明する。
本実施の形態では、主に実施の形態１との差異を説明する。
なお、以下で説明していない事項は、実施の形態１と同様である。
【００４２】
＊＊＊構成の説明＊＊＊
図５は、本実施の形態に係る情報処理装置１００の機能構成例を示す。
【００４３】
図２と比較して、図５では、３つのアプリケーション（アプリケーションＡ１３４、アプリケーションＢ１３５、アプリケーションＣ１３６）が存在する。また、３つのアプリケーションパーティション（アプリケーションＡパーティション１３０、アプリケーションＢパーティション１３１、アプリケーションＣパーティション１３２）が存在する。アプリケーションＡ１３４は、アプリケーションＡパーティション１３０に格納される。アプリケーションＢ１３５は、アプリケーションＢパーティション１３１に格納される。アプリケーションＣ１３６は、アプリケーションＣパーティション１３２に格納される。
図５では、３つのアプリケーションが存在することとしているが、アプリケーションの数は任意である。
また、図５では、履歴記憶領域１０６の代わりに履歴記憶領域１３３が存在する。
履歴記憶領域１３３では、３つのアプリケーションに対応させた構成になっている。
他の構成要素は、図２に示すものと同じであるため、説明を省略する。
【００４４】
図６は、履歴記憶領域１３３の構成例を示す。
図６のエントリ１４０では、図３のエントリ１２０の構成に加えて、パーティション番号が加わっている。図６では便宜的にバーティション番号をＡ、Ｂ及びＣと表記しているが、実装の際にはパーティション番号を数値で表すことが適当である。
パーティション番号：Ａは、アプリケーションＡパーティション１３０に対応する。パーティション番号：Ｂは、アプリケーションＢパーティション１３１に対応する。パーティション番号：Ｃは、アプリケーションＣパーティション１３２に対応する。
本実施の形態では、アクセス回数管理部１１８は、アプリケーションパーティションごとに、対応するエントリ１４０にアクセス回数を格納する。
【００４５】
＊＊＊動作の説明＊＊＊
次に、本実施の形態に係る情報処理装置１００の動作を説明する。
本実施の形態では、アプリケーションの起動順序は定められていない。このため、アクセス回数管理部１１８は、アプリケーションごとに閾値１２１の算出を行う。
つまり、アプリケーションごとに、図８及び図９の処理が行われて、アクセス回数管理部１１８は、アプリケーションごとに各コードデータのアクセス回数を履歴記憶領域１３３に格納し、アプリケーションごとに、アクセス回数に基づき閾値１２１を決定する。
アクセス回数の履歴記憶領域１３３への格納方法及び閾値１２１の決定方法自体は、実施の形態１で示したものと同じである。本実施の形態では、３つのアプリケーションの各々に対して、アクセス回数が記録され、閾値１２１が決定される。
【００４６】
また、本実施の形態では、キャッシュ管理部１１９は、検証プログラム１１０による検証が行われる際に、アプリケーションごとに、閾値１２１以上のアクセス回数が履歴記憶領域１０６に記憶されているコードデータを抽出する。そして、キャッシュ管理部１１９は、抽出したコードデータを上書き禁止データに設定してディスクキャッシュ領域１０８にキャッシュする。
キャッシュ管理部１１９の動作自体は、実施の形態１で示したものと同じである。本実施の形態では、キャッシュ管理部１１９は、３つのアプリケーションの各々に対して、閾値１２１とアクセス回数との比較を行い、抽出したコードデータを上書き禁止データに設定するか否かを決定する。
【００４７】
＊＊＊実施の形態の効果の説明＊＊＊
本実施の形態によれば、複数のアプリケーションに対して実施の形態１と同様の効果を得ることができる。
また、本実施の形態によれば、アプリケーションパーティションの単位で検証を行うことができる。このため、検証プログラムを複数のアプリケーションに対して並行して実行することが可能であり、検証処理を高速化することができる。
【００４８】
実施の形態３．
実施の形態１では、履歴記憶領域はストレージ１０４上にある。しかし、アプリケーションパーティションのサイズが大きい場合は、ストレージ１０４へのアクセス頻度が多くなるため性能が低下する可能性がある。本実施の形態では、これを避けるために、履歴記憶領域をデバイスドライバ１１３内でキャッシュする構成を説明する。本実施の形態の構成では、履歴記憶領域への書き込みが完了したタイミングで履歴記憶領域の情報をストレージ１０４に書き戻すことで、データアクセス速度の低下を抑えることができる。
本実施の形態では、主に実施の形態１との差異を説明する。
なお、以下で説明していない事項は、実施の形態１と同様である。
【００４９】
図７は、本実施の形態に係る情報処理装置１００の機能構成例を示す。
図７では、図１と比較して、履歴記憶領域（キャッシュ）１５０が追加されている。
図７では、理解の容易のために、履歴記憶領域（キャッシュ）１５０はデバイスドライバ１１３内に示されているが、物理的には、履歴記憶領域（キャッシュ）１５０はＲＡＭ１０３のディスクキャッシュ領域１０８に配置されている。
なお、作図上の理由から、図７では、ストレージ１０４の内部構成が図示されていないが、図７においても、ストレージ１０４の内部構成は、図１と同じである。すなわち、図７においても、ストレージ１０４には、アプリケーションパーティション１０７、履歴記憶領域１０６、ファームウェア領域１０９が存在する。
【００５０】
次に、本実施の形態に係る情報処理装置１００の動作例を説明する。
【００５１】
本実施の形態では、オペレーティングシステム１１２の起動時にストレージ１０４の履歴記憶領域１０６の情報がディスクキャッシュ領域１０８にコピーされる。これにより、履歴記憶領域（キャッシュ）１５０が生成される。
アクセス回数管理部１１８は、履歴記憶領域（キャッシュ）１５０にアクセス回数を書き込む。また、アクセス回数管理部１１８は、履歴記憶領域（キャッシュ）１５０に書き込んだアクセス回数に基づいて閾値１２１を算出する。
履歴記憶領域（キャッシュ）１５０の情報のストレージ１０４の履歴記憶領域１０６への書き戻しは、アクセス回数管理部１１８による閾値１２１の算出及びアプリケーション１１１のクローズの後に行われる。
【００５２】
以上のように、本実施の形態では、履歴記憶領域のキャッシュ領域がメモリ上に実現されるため、ストレージへの頻繁なアクセスを回避することができ、性能低下を抑えることができる。
【００５３】
以上、本発明の実施の形態について説明したが、これらの実施の形態のうち、２つ以上を組み合わせて実施しても構わない。
あるいは、これらの実施の形態のうち、１つを部分的に実施しても構わない。
あるいは、これらの実施の形態のうち、２つ以上を部分的に組み合わせて実施しても構わない。
なお、本発明は、これらの実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。
【符号の説明】
【００５４】
１００  情報処理装置、１０１  プロセッサ、１０２  バス、１０３  ＲＡＭ、１０４  ストレージ、１０５  Ｉ／Ｏ装置、１０６  履歴記憶領域、１０７  アプリケーションパーティション、１０８  ディスクキャッシュ領域、１０９  ファームウェア領域、１１０  検証プログラム、１１１  アプリケーション、１１２  オペレーティングシステム、１１３  デバイスドライバ、１１４  下位ファイルシステム、１１５  上位ファイルシステム、１１６  デバイスアクセス部、１１７  ブロックアクセスＡＰＩ部、１１８  アクセス回数管理部、１１９  キャッシュ管理部、１３０  アプリケーションＡパーティション、１３１  アプリケーションＢパーティション、１３２  アプリケーションＣパーティション、１３３  履歴記憶領域、１３４  アプリケーションＡ、１３５  アプリケーションＢ、１３６  アプリケーションＣ、１５０  履歴記憶領域（キャッシュ）。
【図１】
2019123519.tif 000003
【図２】
2019123519.tif 000004
【図３】
2019123519.tif 000005
【図４】
2019123519.tif 000006
【図５】
2019123519.tif 000007
【図６】
2019123519.tif 000008
【図７】
2019123519.tif 000009
【図８】
2019123519.tif 000010
【図９】
2019123519.tif 000011
【図１０】
2019123519.tif 000012
【図１１】
2019123519.tif 000013
【図１２】
2019123519.tif 000014
【図１３】
2019123519.tif 000015
【国際調査報告】
2019123519.tif 000016
2019123519.tif 000017
2019123519.tif 000018