特許 7341784 ストレージ装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-09-01

(45)【発行日】2023-09-11

(54)【発明の名称】ストレージ装置

(51)【国際特許分類】

   G06F 21/57 20130101AFI20230904BHJP

   G06F 3/08 20060101ALI20230904BHJP

   G06F 13/10 20060101ALI20230904BHJP

   G06F 21/79 20130101ALI20230904BHJP

【ＦＩ】

G06F21/57 320

G06F3/08 H

G06F13/10 330Z

G06F21/79

【請求項の数】 10

(21)【出願番号】P 2019147505

(22)【出願日】2019-08-09

(65)【公開番号】P2021028763

(43)【公開日】2021-02-25

【審査請求日】2022-03-09

(73)【特許権者】

【識別番号】318010018

【氏名又は名称】キオクシア株式会社

(74)【代理人】

【識別番号】110001737

【氏名又は名称】弁理士法人スズエ国際特許事務所

(72)【発明者】

【氏名】二木 隼平

(72)【発明者】

【氏名】梅澤 健太郎

【審査官】吉田 歩

(56)【参考文献】

【文献】米国特許出願公開第２０１９／００７３４７８（ＵＳ，Ａ１）

【文献】特開２０１６－１１８８７９（ＪＰ，Ａ）

【文献】特開平０９－３３０２７２（ＪＰ，Ａ）

【文献】特開２０１５－０３６８４７（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／５７

Ｇ０６Ｆ ３／０８

Ｇ０６Ｆ １３／１０

Ｇ０６Ｆ ２１／７９

(57)【特許請求の範囲】

【請求項1】

不揮発性メモリと、
ホストからのコマンドに基づき、前記不揮発性メモリへのデータの書き込みおよび前記不揮発性メモリからのデータの読み出しを制御するコントローラと、
を具備し、
前記コントローラは、少なくとも１つのプロセッサを含み、
前記不揮発性メモリは、前記コマンドに基づくデータの書き込みおよび読み出しの制御を前記少なくとも１つのプロセッサが行うための通常動作用ファームウェアと、前記通常動作用ファームウェアを復旧するためのリカバリー用ファームウェアとを格納し、
前記通常動作用ファームウェアおよび前記リカバリー用ファームウェアが暗号化され、
前記リカバリー用ファームウェアは、前記通常動作用ファームウェアよりも暗号強度の高いアルゴリズムまたは鍵長の大きな暗号鍵を用いて暗号化されて、前記不揮発性メモリに格納されている、
ストレージ装置。

【請求項2】

前記少なくとも１つのプロセッサは、前記通常動作用ファームウェアおよび前記リカバリー用ファームウェアの信頼性を検証する機能を有する第１プロセッサを含み、
前記不揮発性メモリには、前記第１プロセッサのみがアクセス可能な第１領域が設定され、
前記リカバリー用ファームウェアは、前記第１領域に格納されており、
前記通常動作用ファームウェアは、前記不揮発性メモリの前記第１領域以外の第２領域に格納されている、
請求項１に記載のストレージ装置。

【請求項3】

前記リカバリー用ファームウェアによって前記通常動作用ファームウェアが復旧された場合において前記通常動作用ファームウェアによって使用されるべきデータが、前記第１領域に格納されている請求項２に記載のストレージ装置。

【請求項4】

前記リカバリー用ファームウェアは、正規の前記通常動作用ファームウェアを前記ホストから取得する処理と、前記不揮発性メモリの前記第２領域に格納されている前記通常動作用ファームウェアを、前記ホストから取得した正規の前記通常動作用ファームウェアに更新する処理と、を前記第１プロセッサに実行させるためのプログラムである請求項２に記載のストレージ装置。

【請求項5】

不揮発性メモリと、
ホストからのコマンドに基づき、前記不揮発性メモリへのデータの書き込みおよび前記不揮発性メモリからのデータの読み出しを制御するコントローラと、
を具備し、
前記コントローラは、プロセッサを含み、
前記不揮発性メモリは、前記コマンドに基づくデータの書き込みおよび読み出しの制御を前記プロセッサが行うための通常動作用ファームウェアと、前記通常動作用ファームウェアを復旧するためのリカバリー用ファームウェアとを格納し、
前記コントローラは、前記通常動作用ファームウェアと前記リカバリー用ファームウェアの信頼性を検証する機能を有する第１プロセッサと、前記通常動作用ファームウェアを実行する第２プロセッサとを有し、前記第１プロセッサは前記不揮発性メモリの第１領域にはアクセス可能であるが、前記第２プロセッサは前記第１領域にはアクセスできず、かつ、前記リカバリー用ファームウェアは前記第１領域に格納され、前記通常動作用ファームウェアは前記不揮発性メモリの前記第１領域とは異なる第２領域に格納され、
前記通常動作用ファームウェアおよび前記リカバリー用ファームウェアが暗号化され、
前記リカバリー用ファームウェアは、前記通常動作用ファームウェアよりも暗号強度の高いアルゴリズムまたは鍵長の大きな暗号鍵を用いて暗号化されて前記不揮発性メモリに格納されている、
ストレージ装置。

【請求項6】

前記リカバリー用ファームウェアによって前記通常動作用ファームウェアが復旧された場合において前記通常動作用ファームウェアによって使用されるべきデータが、前記第１領域に格納されている請求項５に記載のストレージ装置。

【請求項7】

前記リカバリー用ファームウェアは、正規の前記通常動作用ファームウェアを前記ホストから取得する処理と、前記不揮発性メモリの前記第２領域に格納されている前記通常動作用ファームウェアを、前記ホストから取得した正規の前記通常動作用ファームウェアに更新する処理と、を前記第１プロセッサに実行させるためのプログラムである請求項５に記載のストレージ装置。

【請求項8】

第１不揮発性メモリと、
プログラムを含むデータを前記第１不揮発性メモリよりも高い信頼性が担保された状態で格納するための第２不揮発性メモリと、
ホストからのコマンドに基づき、前記第１不揮発性メモリへのデータの書き込みおよび前記第１不揮発性メモリからのデータの読み出しを制御するコントローラと、
を具備し、
前記コントローラは、プロセッサを含み、
前記コマンドに基づくデータの書き込みおよび読み出しの制御を前記プロセッサが行うための通常動作用ファームウェアが、前記第１不揮発性メモリに格納されており、
前記通常動作用ファームウェアを復旧するためのリカバリー用ファームウェアが、前記第２不揮発性メモリに格納され、
前記コントローラは、前記通常動作用ファームウェアと前記リカバリー用ファームウェアの信頼性を検証する機能を有する第１プロセッサと、前記通常動作用ファームウェアを実行する第２プロセッサとを有し、前記第１プロセッサは前記第２不揮発性メモリにはアクセス可能であるが、前記第２プロセッサは前記第２不揮発性メモリにはアクセスできず、かつ、前記リカバリー用ファームウェアは前記第２不揮発性メモリに格納され、前記通常動作用ファームウェアは前記第1不揮発性メモリに格納され、
前記通常動作用ファームウェアおよび前記リカバリー用ファームウェアが暗号化され、
前記リカバリー用ファームウェアは、前記通常動作用ファームウェアよりも暗号強度の高いアルゴリズムまたは鍵長の大きな暗号鍵を用いて暗号化されて前記第２不揮発性メモリに格納されている、
ストレージ装置。

【請求項9】

前記リカバリー用ファームウェアによって前記通常動作用ファームウェアが復旧された場合において前記通常動作用ファームウェアによって使用されるべきデータが、前記第１不揮発性メモリに格納されている請求項８に記載のストレージ装置。

【請求項10】

前記リカバリー用ファームウェアは、正規の前記通常動作用ファームウェアを前記ホストから取得する処理と、前記第２不揮発性メモリに格納されている前記通常動作用ファームウェアを、前記ホストから取得した正規の前記通常動作用ファームウェアに更新する処理と、を前記第１プロセッサに実行させるためのプログラムである請求項８に記載のストレージ装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、ストレージ装置に関する。

【背景技術】

【0002】

近年、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）などといった様々なストレージ装置が広く普及している。この種のストレージ装置は、データの書き込みやデータの読み出しなどの処理を、ファームウェアなどと称されるプログラムで示される手順で実行する。従って、ファームウェアが改ざんされると、ストレージ装置は、不正な動作を行ってしまう。また、ストレージ装置の動作に影響を及ぼすデータが改ざんされた場合も同様である。そのため、ファームウェアを含むプログラムやデータの信頼性を検証するセキュリティ機能を搭載するストレージ装置が登場するに至っている。起動時などにファームウェアの信頼性を検証するセキュリティ機能は、セキュアブート機能などと称されている。

【先行技術文献】

【特許文献】

【0003】

【文献】米国特許第８４９０１８９号明細書

【文献】特開２０１５－５５８９８号公報

【文献】米国特許出願公開第２０１８／０１５７８３９号明細書

【発明の概要】

【発明が解決しようとする課題】

【0004】

セキュアブート機能を搭載するストレージ装置において、ファームウェアが改ざんされてしまった場合、そのセキュアブート機能によって、ストレージ装置の起動が抑止されることになる。したがって、ストレージ装置を復旧するためには、製造元などへストレージ装置を預けて復旧を依頼する必要があった。

【0005】

改ざんされたファームウェアを、ファームウェアを復旧するためのリカバリー用ファームウェアに書き換えることでストレージ装置を復旧する機能が、ストレージ装置自体に搭載されているならば、製造元などへストレージ装置を預けて復旧を依頼することを不要にできる。しかしながら、リカバリー用ファームウェアも同様に改ざんされてしまった場合には、ユーザの手元でストレージ装置を復旧することは、もはや不可能となってしまう。

【0006】

本発明が解決しようとする課題は、ファームウェアについて高いレベルで信頼性が担保されたリカバリーを可能とするストレージ装置を提供することである。

【課題を解決するための手段】

【0007】

実施形態によれば、ストレージ装置は、不揮発性メモリと、コントローラと、を具備する。前記コントローラは、ホストからのコマンドに基づき、前記不揮発性メモリへのデータの書き込みおよび前記不揮発性メモリからのデータの読み出しを制御する。前記コントローラは、少なくとも１つのプロセッサを含む。前記不揮発性メモリは、前記コマンドに基づくデータの書き込みおよび読み出しの制御を前記少なくとも１つのプロセッサが行うための通常動作用ファームウェアと、前記通常動作用ファームウェアを復旧するためのリカバリー用ファームウェアとを格納する。前記通常動作用ファームウェアおよび前記リカバリー用ファームウェアは暗号化されている。前記リカバリー用ファームウェアは、前記通常動作用ファームウェアよりも暗号強度の高いアルゴリズムまたは鍵長の大きな暗号鍵を用いて暗号化されて、前記不揮発性メモリに格納されている。

【図面の簡単な説明】

【0008】

【図1】第１実施形態のストレージ装置の一構成例を示す図。

【図2】第１実施形態のストレージ装置のファームウェアのリカバリーに関する機能ブロックを示す図。

【図3】第１実施形態のストレージ装置のファームウェアのリカバリーに関する動作手順を示すフローチャート。

【図4】第２実施形態のストレージ装置のファームウェアのリカバリーに関する機能ブロックを示す図。

【図5】第３実施形態のストレージ装置の一構成例を示す図。

【図6】第３実施形態のストレージ装置のファームウェアのリカバリーに関する機能ブロックを示す図。

【図7】第４実施形態のストレージ装置のファームウェアのリカバリーに関する機能ブロックを示す図。

【発明を実施するための形態】

【0009】

以下、実施の形態について、図面を参照して説明する。

【0010】

（第１実施形態）
まず、第１実施形態について説明する。

【0011】

図１は、本実施形態のストレージ装置１の一構成例を示す図である。

【0012】

ストレージ装置１は、ＰＣＩｅ（登録商標）などのインタフェースを介して接続されるホスト２からコマンドを受信し、そのコマンドに対応する処理を実行して、その処理結果をホスト２へ送信する。ストレージ装置１が受信するコマンドには、データの書き込みを要求するライトコマンドや、データの読み出しを要求するリードコマンドなどが存在する。また、ストレージ装置１は、記憶領域上に区画を設けるためのコマンドなどといった様々な制御コマンドを受信し得る。

【0013】

ストレージ装置１は、たとえばＳｏＣ（System On a Chip）として構成されるコントローラ１０と、たとえばＤＲＡＭである揮発性メモリ２０と、たとえばフラッシュメモリである不揮発性メモリ３０とを有する。

【0014】

コントローラ１０は、揮発性メモリ２０をデータの一時的な格納領域として利用しながら、不揮発性メモリ３０へのデータの書き込み処理および不揮発性メモリ３０からのデータの読み出し処理を実行する。つまり、コントローラ１０は、ホスト２からのコマンドに基づき、不揮発性メモリ３０を制御する。コントローラ１０は、Security ＣＰＵ１１を含む複数のＣＰＵ（１１，１２－１，１２－２）を有する。

【0015】

Security ＣＰＵ１１に内蔵されるメモリに格納されている情報へのアクセス手段は限られており、その情報の信頼性が保証される。従って、Security ＣＰＵ１１は一般的なＣＰＵと比較してセキュリティ強度の高いＣＰＵである。ここでは、コントローラ１０が、このSecurity ＣＰＵ１１のほか、２つの一般的なＣＰＵ（ＣＰＵ－Ａ１２－１，ＣＰＵ－Ｂ１２－２）を有していることを想定する。信頼性を保証することは、デジタル署名での検証によってプログラムの発行者を保証することを含む。なお、信頼性の保証には、完全性の保証が含まれる。つまり、信頼性を検証することには、完全性を検証することが含まれる。コントローラ１０は、ＣＰＵ－Ａ１２－１とＣＰＵ－Ｂ１２－２とが協働して、不揮発性メモリ３０へのデータの書き込み処理や不揮発性メモリ３０からのデータの読み出し処理を実行する。あるいは、ＣＰＵ－Ａ１２－１とＣＰＵ－Ｂ１２－２とが、各々、不揮発性メモリ３０へのデータの書き込み処理や不揮発性メモリ３０からのデータの読み出し処理を実行する。以下、一般的なＣＰＵであるＣＰＵ－Ａ１２－１とＣＰＵ－Ｂ１２－２とを、ＣＰＵ１２と総称することがある。

【0016】

Security ＣＰＵ１１、ＣＰＵ－Ａ１２－１およびＣＰＵ－Ｂ１２－２は、不揮発性メモリ３０に格納されている各々のファームウェア（後述する通常動作用Security ＣＰＵ ＦＷ３１，通常動作用ＣＰＵ－Ａ ＦＷ３２－１，通常動作用ＣＰＵ－Ｂ ＦＷ３２－２）によって示される手順で処理を実行していく。具体的には、Security ＣＰＵ１１、ＣＰＵ－Ａ１２－１およびＣＰＵ－Ｂ１２－２は、各々のファームウェアを不揮発性メモリ３０から揮発性メモリ２０へたとえばモジュール単位で適宜にロードして実行する。Security ＣＰＵ１１内には、各々のファームウェアの信頼性を検証するためのセキュリティ保証データが格納されている。Security ＣＰＵ１１は、たとえばストレージ装置１の起動時、このセキュリティ保証データを用いて、各々のファームウェアの信頼性を検証する。つまり、本ストレージ装置１は、セキュアブート機能を有している。Security ＣＰＵ１１内に格納されるセキュリティ保証データは、Security ＣＰＵ１１からでしかアクセスできず、セキュリティ保証データを改ざんするためには、Security ＣＰＵ１１を不正に動作させなければならないので、まず、Security ＣＰＵ１１のファームウェアを改ざんする必要がある。しかし、Security ＣＰＵ１１のファームウェアの改ざんは、たとえばストレージ装置１の起動時における信頼性の検証によって検知される。従って、Security ＣＰＵ１１内のセキュリティ保証データは、その信頼性が保証されるので、信頼性の起点（Root of Trust）として扱うことができる。セキュリティ保証データとしては、特定の情報に限定されず、検証鍵やＭＡＣ値などといった様々な情報を適用し得る。

【0017】

以上のような構成を持つ本ストレージ装置１は、改ざんされたファームウェアをリカバリーする機能を有する。図２は、本ストレージ装置１のファームウェアのリカバリーに関する機能ブロックを示す図である。

【0018】

Security ＣＰＵ１１は、検知部１１１と、リカバリー判定部１１２と、リカバリー実行部１１３とを有する。これらの各部は、Security ＣＰＵ１１のみがアクセス可能であり、かつ、読み出しのみが可能であるメモリに格納されている等により、その信頼性が高いレベルで担保されているプログラムを当該Security ＣＰＵ１１が実行することによって実現される。あるいは、このプログラム自体が、セキュリティ保証データ１１４の１つとして、Security ＣＰＵ１１内に格納されていてもよい。

【0019】

また、不揮発性メモリ３０は、第１に、Security ＣＰＵ１１のためのファームウェアである通常動作用Security ＣＰＵ ＦＷ３１と、ＣＰＵ－Ａ１２－１のためのファームウェアである通常動作用ＣＰＵ－Ａ ＦＷ３２－１と、ＣＰＵ－Ｂ１２－２のためのファームウェアである通常動作用ＣＰＵ－Ｂ ＦＷ３２－２とを格納している。また、不揮発性メモリ３０は、第２に、通常動作用Security ＣＰＵ ＦＷ３１を復旧するためのファームウェアであるリカバリー用Security ＣＰＵ ＦＷ３３と、通常動作用ＣＰＵ－Ａ ＦＷ３２－１を復旧するためのファームウェアであるリカバリー用ＣＰＵ－Ａ ＦＷ３４－１と、通常動作用ＣＰＵ－Ｂ ＦＷ３２－２を復旧するためのファームウェアであるリカバリー用ＣＰＵ－Ｂ ＦＷ３４－２とを格納している。

【0020】

前者の通常動作用Security ＣＰＵ ＦＷ３１、通常動作用ＣＰＵ－Ａ ＦＷ３２－１および通常動作用ＣＰＵ－Ｂ ＦＷ３２－２と、後者のリカバリー用Security ＣＰＵ ＦＷ３３、リカバリー用ＣＰＵ－Ａ ＦＷ３４－１およびリカバリー用ＣＰＵ－Ｂ ＦＷ３４－２とのうち、少なくとも後者のリカバリー用Security ＣＰＵ ＦＷ３３、リカバリー用ＣＰＵ－Ａ ＦＷ３４－１およびリカバリー用ＣＰＵ－Ｂ ＦＷ３４－２は、暗号化された状態で不揮発性メモリ３０に格納されている。つまり、本ストレージ装置１は、プログラムやデータを暗号化し、また、暗号化されているプログラムやデータを復号する暗号化機能のうちの少なくとも復号に関する機能を有している。また、詳細については後述するが、後者のリカバリー用Security ＣＰＵ ＦＷ３３、リカバリー用ＣＰＵ－Ａ ＦＷ３４－１およびリカバリー用ＣＰＵ－Ｂ ＦＷ３４－２は、前者の通常動作用Security ＣＰＵ ＦＷ３１、通常動作用ＣＰＵ－Ａ ＦＷ３２－１および通常動作用ＣＰＵ－Ｂ ＦＷ３２－２と比較して、暗号強度の高いアルゴリズムまたは鍵長の大きな暗号鍵を用いて暗号化されている。つまり、高い信頼性が担保された状態で不揮発性メモリ３０に格納されている。通常動作用ファームウェア（３１，３２－１，３２－２）およびリカバリー用ファームウェア（３３，３４－１，３４－２）は、さらに、本ストレージ装置１が圧縮されたプログラムやデータを伸長する機能を有しているならば、圧縮された状態で不揮発性メモリ３０に格納されていてもよい。

【0021】

検知部１１１は、ストレージ装置１の動作中における通常動作用ファームウェアの改ざんを検知するためのモジュールであり、ストレージ装置１の異常動作、より詳しくは、Security ＣＰＵ１１、ＣＰＵ－Ａ１２－１またはＣＰＵ－Ｂ１２－２の異常動作を検知する。なお、ストレージ装置１の停止中における通常動作用ファームウェアの改ざんは、ストレージ装置１の起動時において前述のセキュアブート機能によって検知される。異常動作を検知する方法については、特定の方法に限定されず、既知の様々な方法を適用し得る。

【0022】

リカバリー判定部１１２は、ストレージ装置１の異常動作が検知された場合、当該ストレージ装置１を通常動作用ファームウェアのリカバリーによって回復させることが可能か否かを判定する。この判定は、たとえば、検出された異常動作がハードウェア障害を原因とするものか否かを調べ、ハードウェア障害を原因とするものでない場合、通常動作用ファームウェアのリカバリーによって回復させることが可能と判定するといったものであってもよい。また、Security ＣＰＵ１１内に格納されているセキュリティ保証データを用いて通常動作用Security ＣＰＵ ＦＷ３１、通常動作用ＣＰＵ－Ａ ＦＷ３２－１および通常動作用ＣＰＵ－Ｂ ＦＷ３２－２の信頼性を検証し、改ざんが検出された場合、通常動作用ファームウェアのリカバリーによって回復させることが可能と判定するといったものであってもよい。

【0023】

リカバリー実行部１１３は、異常動作が検知されたストレージ装置１を、通常動作用ファームウェアのリカバリーによって回復させることが可能と判定された場合、通常動作用ファームウェアのリカバリーを実行する。たとえば、ＣＰＵ－Ａ１２－１の異常動作が検知部１１１によって検知された場合であって、通常動作用ＣＰＵ－Ａ ＦＷ３２－１のリカバリーによって当該ＣＰＵ－Ａ１２－１を回復させることが可能とリカバリー判定部１１２によって判定された場合、リカバリー実行部１１３は、通常動作用ＣＰＵ－Ａ ＦＷ３２－１をリカバリー用ＣＰＵ－Ａ ＦＷ３４－１に書き換えて、ストレージ装置１を再起動する処理を実行する。なお、通常動作用ファームウェアのリカバリーによって回復させることが不可能と判定された場合には、リカバリー判定部１１２によって、ホスト２へのエラーの通知が行われる。ホスト２へエラーを通知した場合、リカバリー判定部１１２は、ストレージ装置１を停止させるようにしてもよい。

【0024】

また、リカバリー実行部１１３は、ストレージ装置１の起動時、前述のセキュアブート機能によって、たとえば、通常動作用ＣＰＵ－Ａ ＦＷ３２－１の改ざんが検出された場合も、通常動作用ＣＰＵ－Ａ ＦＷ３２－１をリカバリー用ＣＰＵ－Ａ ＦＷ３４－１に書き換えて、ストレージ装置１を再起動する処理を実行する。

【0025】

なお、リカバリー用ファームウェア（３３，３４－１，３４－２）は、いわゆるバックアップとして通常動作用ファームウェア（３１，３２－１，３２－２）と同じものが用意されてもよいし、ホスト２から正規の通常動作用ファームウェアを取得する等の通常動作用ファームウェアを復旧するための必要最小限の機能を備えるものであってもよい。ファームウェアを復旧するとは、たとえば改ざんされたファームウェアを正規のファームウェアに書き換えて改ざん前の状態に戻すことである。

【0026】

ところで、たとえば、改ざんされた通常動作用ＣＰＵ－Ａ ＦＷ３２－１をリカバリー用ＣＰＵ－Ａ ＦＷ３４－１によって復旧しようとしても、リカバリー用ＣＰＵ－Ａ ＦＷ３４－１も同様に改ざんされてしまっている場合、ストレージ装置１の再起動時に作動するセキュアブート機能によって、ストレージ装置１の起動が抑止される。つまり、本ストレージ装置１でのリカバリーはもはや不可能であり、製造元などへストレージ装置を預けて復旧を依頼しなければならない。

【0027】

そこで、本ストレージ装置１は、リカバリー用ファームウェア（３３，３４－１，３４－２）について、通常動作用ファームウェア（３１，３２－１，３２－２）と比較して、高い信頼性が担保された状態で不揮発性メモリ３０に格納する。また、本ストレージ装置１は、通常動作用ファームウェアをリカバリー用ファームウェアに書き換えるにあたり、Security ＣＰＵ１１内に格納されているセキュリティ保証データ１１４を用いて、リカバリー用ファームウェアの信頼性を検証する。

【0028】

リカバリー用ファームウェアを通常動作用ファームウェアと比較して高い信頼性が担保された状態で不揮発性メモリ３０に格納することについては、前述したように、暗号強度の高いアルゴリズムまたは鍵長の大きな暗号鍵を用いて暗号化することによって実現する。たとえば共通鍵暗号方式で暗号化が行われる場合、復号のための共通鍵（暗号鍵）がセキュリティ保証データ１１４としてSecurity ＣＰＵ１１内に格納される。本ストレージ装置１の暗号化機能を司るモジュールは、セキュリティ保証データ１１４としてSecurity ＣＰＵ１１内に格納されている暗号鍵を示す情報をパラメータとして受け取り、その情報で示される暗号鍵を用いて、指示されたプログラムまたはデータの復号を実行する。また、暗号化機能を司るモジュールが複数のアルゴリズムに対応する場合、アルゴリズムの指定もパラメータによって受け付ける。

【0029】

リカバリー実行部１１３は、たとえば、通常動作用ファームウェア３２－１をリカバリー用ファームウェア３４－１に書き換える場合、まず、リカバリー用ファームウェア３４－１の不揮発性メモリ３０からの読み出しを実行する（図２：ａ１）。前述したように、リカバリー用ファームウェア３４－１は、暗号化されて不揮発性メモリ３０に格納されている。リカバリー実行部１１３は、暗号化機能を司るモジュールに対して、不揮発性メモリ３０から読み出されるリカバリー用ファームウェア３４－１の復号を指示する。リカバリー実行部１１３は、復号後のリカバリー用ファームウェア３４－１を揮発性メモリ２０へ格納する（図２：ａ２）。なお、リカバリー実行部１１３は、暗号化されているリカバリー用ファームウェア３４－１を揮発性メモリ２０へ格納した後、暗号化機能を司るモジュールに対して、その復号を指示するようにしてもよい。図２において示される揮発性メモリ２０上のリカバリー用ファームウェアは、復号後のリカバリー用ファームウェアである。

【0030】

次に、リカバリー実行部１１３は、Security ＣＰＵ１１内に格納されているセキュリティ保証データ１１４を用いて、揮発性メモリ２０に格納したリカバリー用ファームウェア３４－１の信頼性を検証する（図２：ａ３）。検証が成功した場合、リカバリー実行部１１３は、不揮発性メモリ３０上の通常動作用ファームウェア３２－１をリカバリー用ファームウェア３４－１に更新し（図２：ａ４）、ストレージ装置１を再起動する。検証が失敗した場合には、リカバリー実行部１１３は、ホスト２へエラーを通知する。ホスト２へエラーを通知した場合、リカバリー実行部１１３は、ストレージ装置１を停止させるようにしてもよい。

【0031】

なお、リカバリー実行部１１３は、暗号化されている状態のリカバリー用ファームウェアについて、Security ＣＰＵ１１内に格納されているセキュリティ保証データ１１４を用いた信頼性の検証を実行し、検証が成功した場合に、暗号化機能を司るモジュールに対して、その復号を指示するようにしてもよい。

【0032】

リカバリー用ファームウェアを通常動作用ファームウェアよりも高い信頼性が担保された状態で不揮発性メモリ３０に格納することで、本ストレージ装置１は、製造元などへストレージ装置を預けてファームウェアの復旧を依頼するといった復旧作業のためのコストを削減することができ、よって、可用性を向上させることができる。

【0033】

リカバリー用ファームウェアが、ホスト２から正規の通常動作用ファームウェアを取得する等の、通常動作用ファームウェアを復旧するための必要最小限の機能を備えるものであった場合、リカバリー実行部１１３によって再起動されたストレージ装置１は、たとえば以下のような手順で動作する。

【0034】

まず、ストレージ装置１は、セキュアブート機能によって、リカバリー用ファームウェアの信頼性を検証する。リカバリー用ファームウェアは、高い信頼性が担保された状態で不揮発性メモリ３０に格納されているので、この検証は成功し、ストレージ装置１は、リカバリー用ファームウェアで示される手順に沿った動作を開始する。

【0035】

ストレージ装置１は、通常動作用ファームウェアをホスト２から取得する。たとえば、ストレージ装置１とホスト２とを接続するインタフェースが、ホスト２側のメモリにストレージ装置１側からアクセスすることをサポートしているならば、ホスト２側のメモリから通常動作用ファームウェアを読み出すことによって取得してもよい。あるいは、ホスト２に対して、通常動作用ファームウェアの転送を要求するコマンドを送信することによって取得してもよい。または、ストレージ装置１は、ファームウェアの更新が必要であることを示すメッセージなどをホスト２へ送信するだけでもよく、以降、ホスト２主導の下、通常動作用ファームウェアの更新を行ってもよい。

【0036】

ストレージ装置１は、リカバリー用ファームウェアに書き換えられている状態の不揮発性メモリ３０上のファームウェアを、ホスト２から取得した通常動作用ファームウェアに再び書き換える。この書き換え後、ストレージ装置１は再起動する。

【0037】

なお、通常動作用ファームウェアをホスト２から取得する際、この通常動作用ファームウェアの信頼性を検証するための情報や、暗号化を解くための暗号鍵を共に取得し、セキュリティ保証データとして改めてSecurity ＣＰＵ１１内に格納するようにしてもよい。

【0038】

図３は、本実施形態のストレージ装置１のファームウェアのリカバリーに関する動作手順を示すフローチャートである。

【0039】

検知部１１１は、ストレージ装置１（Security ＣＰＵ１１、ＣＰＵ－Ａ１２－１またはＣＰＵ－Ｂ１２－２）の異常動作を検知する（Ｓ１１）。異常動作が検知された場合（Ｓ１１：ＹＥＳ）、リカバリー判定部１１２は、異常動作の原因を判定する（Ｓ１２）。たとえば、その異常動作がハードウェア障害を原因とするものか否かを判定する。リカバリー判定部１１２は、異常動作の原因の判定結果に基づき、ファームウェア（通常動作用Security ＣＰＵ ＦＷ３１、ＣＰＵ－Ａ１２－１またはＣＰＵ－Ｂ１２－２）の更新による復旧は可能か否かを判定する（Ｓ１３）。

【0040】

ファームウェアの更新による復旧は可能と判定された場合（Ｓ１３：ＹＥＳ）、リカバリー実行部１１３は、リカバリー用ファームウェア（リカバリー用Security ＣＰＵ ＦＷ３３、リカバリー用ＣＰＵ－Ａ ＦＷ３４－１またはリカバリー用ＣＰＵ－Ｂ ＦＷ３４－２）を不揮発性メモリ３０から読み出し、揮発性メモリ２０に格納する（Ｓ１４）。リカバリー実行部１１３は、Security ＣＰＵ１１内に格納されているセキュリティ保証データを用いて、リカバリー用ファームウェアの信頼性を検証する（Ｓ１５）。

【0041】

検証が成功した場合（Ｓ１６：ＹＥＳ）、リカバリー実行部１１３は、不揮発性メモリ３０上の通常動作用ファームウェアをリカバリー用ファームウェアに更新し（Ｓ１７）、ストレージ装置１を再起動する（Ｓ１８）。

【0042】

一方、リカバリー判定部１１２によって、異常動作が検知されたストレージ装置１をファームウェアのリカバリーによって回復させることは不可能と判定された場合（Ｓ１３：ＮＯ）、または、リカバリー実行部１１３によるリカバリー用ファームウェアの信頼性の検証が失敗した場合（Ｓ１６：ＮＯ）、リカバリー判定部１１２またはリカバリー実行部１１３からホスト２に対してエラーが通知される（Ｓ１９）。

【0043】

以上のように、リカバリー用ファームウェアを通常動作用ファームウェアよりも高い信頼性が担保された状態で不揮発性メモリ３０に格納する本ストレージ装置１は、ファームウェアについて高いレベルで信頼性が担保されたリカバリーを可能とする。

【0044】

（第２実施形態）
次に、第２実施形態について説明する。

【0045】

図４は、本実施形態のストレージ装置１のファームウェアのリカバリーに関する機能ブロックを示す図である。本実施形態のストレージ装置１も、第１実施形態と同様、コントローラ１０、揮発性メモリ２０および不揮発性メモリ３０を有する。ここでは、第１実施形態と同一の構成要素については同一の符号を用い、それらについての重複する説明を省略する。

【0046】

本実施形態のストレージ装置１においては、不揮発性メモリ３０上に、アクセス権限がSecurity ＣＰＵ１１に限定される区画が設定され、この区画にリカバリー用ファームウェア（３３，３４－１，３４－２）が格納される。ここで、アクセス権限がSecurity ＣＰＵ１１に限定されるとは、Security ＣＰＵ１１のみがアクセス可能またはSecurity ＣＰＵ１１からの指示でのみアクセス可能であることを意味する。Security ＣＰＵ１１からの指示でのみアクセス可能とは、たとえば、ＣＰＵ－Ａ１２－１やＣＰＵ－Ｂ１２－２は、Security ＣＰＵ１１の制御下においてのみアクセス可能であることを意味する。

【0047】

アクセス権限がSecurity ＣＰＵ１１に限定される区画の設定は、たとえばストレージ装置１の製造過程で行われ、かつ、その区画は、制御コマンドを含む外部からのコマンドの対象となり得ない区画として設けられる。

【0048】

ここでは、アクセス権限がSecurity ＣＰＵ１１に限定される区画内の領域を高セキュリティ領域３０Ａと称し、不揮発性メモリ３０上の当該区画以外の領域を通常領域３０Ｂと称する。たとえば、ＣＰＵ－Ａ１２－１のための通常動作用ＣＰＵ－Ａ ＦＷ３２－１は、ＣＰＵ－Ａ１２－１がアクセス可能な通常領域３０Ｂに格納される。つまり、通常動作用ファームウェア（３１，３２－１，３２－２）は、通常領域３０Ｂに格納される。

【0049】

このように、本実施形態のストレージ装置１は、アクセス権限がSecurity ＣＰＵ１１に限定される区画内の領域である高セキュリティ領域３０Ａにリカバリー用ファームウェアを格納することで、通常動作用ファームウェアと比較して高い信頼性が担保された状態で不揮発性メモリ３０に格納することを実現する。

【0050】

なお、本実施形態のストレージ装置１においても、リカバリー用ファームウェアを高セキュリティ領域３０Ａに格納するにあたり、さらに、通常動作用ファームウェアを通常領域３０Ｂに格納する場合と比較して、暗号強度の高いアルゴリズムまたは鍵長の大きな暗号鍵を用いて暗号化するようにしてもよい。

【0051】

本実施形態のストレージ装置１におけるリカバリー実行部１１３は、たとえば、通常動作用ファームウェア３２－１をリカバリー用ファームウェア３４－１に書き換える場合、そのリカバリー用ファームウェア３４－１を、不揮発性メモリ３０の高セキュリティ領域３０Ａから読み出す（図４：ｂ１）。以降、リカバリー実行部１１３は、第１実施形態と同様の手順で処理を実行する。つまり、リカバリー実行部１１３は、読み出されたリカバリー用ファームウェア３４－１を揮発性メモリ２０へ格納し（図４：ｂ２）、Security ＣＰＵ１１内に格納されているセキュリティ保証データ１１４を用いて、揮発性メモリ２０に格納したリカバリー用ファームウェア３４－１の信頼性を検証する（図４：ｂ３）。

【0052】

検証が成功した場合、リカバリー実行部１１３は、不揮発性メモリ３０上の通常動作用ファームウェア３２－１をリカバリー用ファームウェア３４－１に更新し（図４：ｂ４）、本ストレージ装置１を再起動する。検証が失敗した場合には、リカバリー実行部１１３は、ホスト２へエラーを通知する。ホスト２へエラーを通知した場合、リカバリー実行部１１３は、ストレージ装置１を停止させるようにしてもよい。

【0053】

以上のように、アクセス権限がSecurity ＣＰＵ１１に限定される区画内の領域である高セキュリティ領域３０Ａにリカバリー用ファームウェアを格納することで、通常動作用ファームウェアと比較して高い信頼性が担保された状態で不揮発性メモリ３０に格納する本実施形態のストレージ装置１においても、第１実施形態と同様、たとえば製造元などへストレージ装置を預けてファームウェアの復旧を依頼するといった復旧作業のためのコストを削減することができ、よって、可用性を向上させることができる。

【0054】

つまり、本ストレージ装置１も、ファームウェアについて高いレベルで信頼性が担保されたリカバリーを可能とする。

【0055】

（第３実施形態）
次に、第３実施形態について説明する。

【0056】

図５は、本実施形態のストレージ装置１の一構成例を示す図である。

【0057】

本実施形態のストレージ装置１は、第１実施形態や第２実施形態と比較して、マスクＲＯＭなどである読み出し専用メモリ４０をさらに有する。また、この読み出し専用メモリ４０は、そのアクセス権限が、Security ＣＰＵ１１に限定されている。ここで、アクセス権限がSecurity ＣＰＵ１１に限定されるとは、Security ＣＰＵ１１のみがアクセス可能またはSecurity ＣＰＵ１１からの指示でのみアクセス可能であることを意味する。Security ＣＰＵ１１からの指示でのみアクセス可能とは、たとえば、ＣＰＵ－Ａ１２－１やＣＰＵ－Ｂ１２－２は、Security ＣＰＵ１１の制御下においてのみアクセス可能であることを意味する。なお、ここでも、第１実施形態や第２実施形態と同一の構成要素については同一の符号を用い、それらについての重複する説明を省略する。

【0058】

図６は、本実施形態のストレージ装置１のファームウェアのリカバリーに関する機能ブロックを示す図である。

【0059】

本実施形態のストレージ装置１においては、アクセス権限がSecurity ＣＰＵ１１に限定される読み出し専用メモリ４０に、リカバリー用ファームウェア（３３，３４－１，３４－２）を格納する。つまり、本実施形態のストレージ装置１は、アクセス権限がSecurity ＣＰＵ１１に限定される読み出し専用メモリ４０をリカバリー用ファームウェアの格納場所とすることで、リカバリー用ファームウェアを、通常動作用ファームウェアと比較して高い信頼性が担保された状態で格納することを実現する。

【0060】

なお、第１実施形態や第２実施形態のように、リカバリー用ファームウェアを大容量の不揮発性メモリ３０に格納する場合には、第１実施形態の説明で述べたように、当該リカバリー用ファームウェアは、いわゆるバックアップとして通常動作用ファームウェアと同じものが用意されてもよいし、ホスト２から正規の通常動作用ファームウェアを取得する等の、通常動作用ファームウェアを復旧するための必要最小限の機能を備えるものであってもよい。一方、リカバリー用ファームウェアを高い信頼性が担保された状態で格納することを目的として、読み出し専用メモリ４０を新設する場合には、コストを抑えるために、当該読み出し専用メモリ４０の容量を極力小さくすることが求められる。たとえば５００Ｋバイト程度に収めることが好ましい。この点を考慮して、本実施形態のストレージ装置１においては、リカバリー用ファームウェアを、ホスト２から正規の通常動作用ファームウェアを取得する等の、通常動作用ファームウェアを復旧するための必要最小限の機能を備えるものとする。つまり、読み出し専用メモリ４０の容量は、通常動作用ファームウェアを格納するために必要な容量よりも格段に小さい容量でよい。

【0061】

本実施形態のストレージ装置１におけるリカバリー実行部１１３は、たとえば、通常動作用ファームウェア３２－１をリカバリー用ファームウェア３４－１に書き換える場合、そのリカバリー用ファームウェア３４－１を、アクセス権限がSecurity ＣＰＵ１１に限定される読み出し専用メモリ４０から読み出す（図６：ｃ１）。以降、リカバリー実行部１１３は、第１実施形態や第２実施形態と同様の手順で処理を実行する。つまり、リカバリー実行部１１３は、読み出されたリカバリー用ファームウェア３４－１を揮発性メモリ２０へ格納し（図６：ｃ２）、Security ＣＰＵ１１内に格納されているセキュリティ保証データ１１４を用いて、揮発性メモリ２０に格納したリカバリー用ファームウェア３４－１の信頼性を検証する（図６：ｃ３）。

【0062】

検証が成功した場合、リカバリー実行部１１３は、不揮発性メモリ３０上の通常動作用ファームウェア３２－１をリカバリー用ファームウェア３４－１に更新し（図６：ｃ４）、本ストレージ装置１を再起動する。検証が失敗した場合には、リカバリー実行部１１３は、ホスト２へエラーを通知する。ホスト２へエラーを通知した場合、リカバリー実行部１１３は、ストレージ装置１を停止させるようにしてもよい。

【0063】

本実施形態のストレージ装置１においては、前述したように、リカバリー用ファームウェアが、ホスト２から正規の通常動作用ファームウェアを取得する等の、通常動作用ファームウェアを復旧するための必要最小限の機能を備えるものであることを想定している。そのため、リカバリー用ファームウェア３４－１の信頼性の検証が成功し、通常動作用ファームウェア３２－１がリカバリー用ファームウェア３４－１に書き換えられて再起動されたストレージ装置１は、第１実施形態の説明でも述べたように、たとえば以下のような手順で動作する。

【0064】

まず、ストレージ装置１は、セキュアブート機能によって、リカバリー用ファームウェアの信頼性を検証する。アクセス権限がSecurity ＣＰＵ１１に限定される読み出し専用メモリ４０から読み出されたリカバリー用ファームウェアの検証は成功し、ストレージ装置１は、リカバリー用ファームウェアで示される手順に沿った動作を開始する。

【0065】

ストレージ装置１は、通常動作用ファームウェアをホスト２から取得し、リカバリー用ファームウェアに書き換えられている状態の不揮発性メモリ３０上のファームウェアを、ホスト２から取得した通常動作用ファームウェアに再び書き換える。この書き換え後、ストレージ装置１は、再起動する。

【0066】

以上のように、アクセス権限がSecurity ＣＰＵ１１に限定される読み出し専用メモリ４０をリカバリー用ファームウェアの格納場所とすることで、リカバリー用ファームウェアを、通常動作用ファームウェアと比較して高い信頼性が担保された状態で格納する本実施形態のストレージ装置１においても、第１実施形態や第２実施形態と同様、製造元などへストレージ装置を預けてファームウェアの復旧を依頼するといった復旧作業のためのコストを削減することができ、よって、可用性を向上させることができる。

【0067】

つまり、本ストレージ装置１も、ファームウェアについて高いレベルで信頼性が担保されたリカバリーを可能とする。

【0068】

ところで、以上では、リカバリー用ファームウェアを格納する記憶素子として、アクセス権限がSecurity ＣＰＵ１１に限定される、マスクＲＯＭなどである読み出し専用メモリ４０をさらに有する例を説明した。つまり、書き換え不可の記憶素子を格納場所とすることで、リカバリー用ファームウェアを、不揮発性メモリ３０に格納する通常動作用ファームウェアと比較して高い信頼性が担保された状態で格納することを実現する例について説明した。この一変形例として、読み出し専用メモリ４０に代えて、ＮＯＲ型フラッシュメモリなどの書き込みも可能な記憶素子を適用する例を説明する。

【0069】

当該一変形例においては、リカバリー用ファームウェアを格納する記憶素子として、ＮＯＲ型フラッシュメモリがコントローラ１０に外付けされているものと想定する。また、このＮＯＲ型フラッシュメモリのアクセス権限は、Security ＣＰＵ１１に限定されている。そして、書き込みが可能なＮＯＲ型フラッシュメモリをリカバリー用ファームウェアの格納場所とする当該一変形例においては、ＮＯＲ型フラッシュメモリに格納されているリカバリー用ファームウェアの信頼性を検証するための検証データを、たとえば、電気的に素子特性を不可逆的に変更させることによってデータを記憶するフューズ素子（ｅＦｕｓｅ）に格納する。ｅＦｕｓｅは、コントローラ１０内に設けられてもよいし、コントローラ１０の外部に設けられてもよい。検証データは、たとえばハッシュ値である。

【0070】

リカバリー実行部１１３は、ＮＯＲ型フラッシュメモリからリカバリー用ファームウェアを読み出し、不揮発性メモリ３０上の通常動作用ファームウェアを当該読み出したリカバリー用ファームウェアに書き換えるにあたり、ｅＦｕｓｅに記録されている検証データを用いて当該読み出したリカバリー用ファームウェアの信頼性を検証する。リカバリー実行部１１３は、この検証が成功した場合、不揮発性メモリ３０上の通常動作用ファームウェアをリカバリー用ファームウェアに書き換える。このように、当該一変形例においても、リカバリー用ファームウェアを、通常動作用ファームウェアと比較して高い信頼性が担保された状態で格納することが実現される。

【0071】

当該一変形例においては、マスクＲＯＭなどである読み出し専用メモリ４０の場合と比較して、ストレージ装置１の製造時において、ＮＯＲ型フラッシュメモリへ格納するリカバリー用ファームウェアを変更することができるという効果を奏する。また、リカバリー用ファームウェアの信頼性を検証するための検証データがｅＦｕｓｅによって記録されるので、ＮＯＲ型フラッシュメモリ自体の差し替えに対応することができる。あるいは、マスクＲＯＭなどである読み出し専用メモリ４０にリカバリー用ファームウェアを格納する場合において、さらに、当該リカバリー用ファームウェアの信頼性を検証するための検証データをｅＦｕｓｅに記録するようにしてもよい。

【0072】

また、本実施形態においては、リカバリー用ファームウェアが、ホスト２から正規の通常動作用ファームウェアを取得する等の、通常動作用ファームウェアを復旧するための必要最小限の機能を備えるものと想定し、不揮発性メモリ３０上の通常動作用ファームウェアをリカバリー用ファームウェアに書き換えて、ストレージ装置１を再起動することとしている。リカバリー用ファームウェアが、ホスト２から正規の通常動作用ファームウェアを取得する等の、通常動作用ファームウェアを復旧するための必要最小限の機能を備えるものである場合、不揮発性メモリ３０上の通常動作用ファームウェアをリカバリー用ファームウェアに書き換えることに代えて、揮発性メモリ２０に格納された後、セキュリティ保証データ１１４を用いた信頼性の検証が成功したリカバリー用ファームウェアが、正規の通常動作用ファームウェアをホスト２から取得し、改ざんされている不揮発性メモリ３０上の通常動作用ファームウェアを、ホスト２から取得した正規の通常動作用ファームウェアに書き換えるようにしてもよい。この場合、ストレージ装置１の再起動が１回で済むことになる。

【0073】

（第４実施形態）
次に、第４実施形態について説明する。

【0074】

図７は、本実施形態のストレージ装置１のファームウェアのリカバリーに関する機能ブロックを示す図である。本実施形態のストレージ装置１も、第１実施形態から第３実施形態と同様、コントローラ１０、揮発性メモリ２０および不揮発性メモリ３０を有する。ここでは、第１実施形態から第３実施形態と同一の構成要素については同一の符号を用い、それらについての重複する説明を省略する。

【0075】

本実施形態のストレージ装置１は、第１実施形態と同様、不揮発性メモリ３０上に、アクセス権限がSecurity ＣＰＵ１１に限定される区画を設定し、この区画にリカバリー用ファームウェアを格納する。つまり、本実施形態のストレージ装置１においては、高セキュリティ領域３０Ａが不揮発性メモリ３０上に存在する。

【0076】

また、本実施形態のストレージ装置１においては、通常動作用ファームウェアが、たとえば暗号鍵などの重要データを扱うことを想定する。重要データは、通常動作用ファームウェアと同様、不揮発性メモリ３０の通常領域３０Ｂに格納されている。また、その信頼性を検証するための情報がセキュリティ保証データ１１４としてSecurity ＣＰＵ１１内に格納されている。さらに、本実施形態のストレージ装置１においては、ホスト２からのコマンドによる指示やストレージ装置１の内部処理などによって、重要データが特定のタイミングで更新され得る。

【0077】

この場合、通常動作用ファームウェアのリカバリー時、最新の重要データが失われると、再起動されたストレージ装置１は、正常な動作が行えなくなってしまう。そこで、本実施形態のストレージ装置１は、さらに、重要データ３５を復旧するためのリカバリー用重要データ３６を、不揮発性メモリ３０上の高セキュリティ領域３０Ａに格納する。

【0078】

本実施形態のストレージ装置１におけるリカバリー実行部１１３は、たとえば特定のタイミングでの重要データ３５の更新時、更新された重要データ３５を不揮発性メモリ３０の通常領域３０Ｂから読み出す（図７：ｄ１１）。なお、リカバリー実行部１１３によるリカバリー用重要データ３６の高セキュリティ領域３０Ａへの格納は、重要データ３５の更新時とは異なるタイミングで実行されてもよい。つまり、符号ｄ１１で示される、重要データ３５の通常領域３０Ｂからの読み出しは、特定のタイミングでの重要データ３５の更新時に限定されない。

【0079】

リカバリー実行部１１３は、Security ＣＰＵ１１内に格納されているセキュリティ保証データ１１４を用いて、通常領域３０Ｂから読み出した重要データ３５の信頼性を検証する（図７：ｄ１２）。この検証が成功した場合、リカバリー実行部１１３は、読み出した重要データ３５の高セキュリティ領域３０Ａへの書き込みを実行する（図７：ｄ１３）。検証が失敗した場合には、リカバリー実行部１１３は、ホスト２へエラーを通知する。ホスト２へエラーを通知した場合、リカバリー実行部１１３は、ストレージ装置１を停止させるようにしてもよい。

【0080】

また、通常動作用ファームウェアのリカバリー実行時、リカバリー実行部１１３は、リカバリー用重要データ３６を不揮発性メモリ３０の高セキュリティ領域３０Ａから読み出す（図７：ｄ２１）。なお、通常動作用ファームウェア自体のリカバリーの手順は、第１実施形態で説明した通りであるので、ここでは、その説明を省略する。

【0081】

リカバリー実行部１１３は、読み出したリカバリー用重要データ３６について、Security ＣＰＵ１１内に格納されているセキュリティ保証データ１１４を用いて、その信頼性を検証する（図７：ｄ２２）。そして、検証が成功した場合、リカバリー実行部１１３は、不揮発性メモリ３０の通常領域３０Ｂに格納されている重要データ３５をリカバリー用重要データ３６に書き換える。

【0082】

本実施形態のストレージ装置１においては、通常動作用ファームウェアによって扱われる重要データが特定のタイミングで更新され、かつ、通常動作用ファームウェアのリカバリー時、最新の重要データが復旧されるので、異常動作が検知される前の状態から使い続けることが可能となり、可用性を向上させることができる。

【0083】

また、本実施形態では、不揮発性メモリ３０上に、アクセス権限がSecurity ＣＰＵ１１に限定される区画を設定し、この区画にリカバリー用ファームウェアと通常動作用ファームウェアが扱う重要データとを格納する例を説明した。第３実施形態において一変形例として説明した、ＮＯＲ型フラッシュメモリなどの書き込みが可能な記憶素子にリカバリー用ファームウェアを格納し、かつ、リカバリー用ファームウェアの信頼性を検証するための検証データがｅＦｕｓｅによって記録される形態において、通常動作用ファームウェアが扱う重要データのバックアップをＮＯＲ型フラッシュメモリに格納するようにしてもよい。検証データは、更新が発生しないリカバリー用ファームウェア分のみＦｕｓｅによって記録する。アクセス権限がSecurity ＣＰＵ１１に限定されるＮＯＲ型フラッシュメモリに重要データを格納するだけでも、重要データの信頼性は高いレベルで担保される。

【0084】

この場合、ＮＯＲ型フラッシュメモリの一部領域に、検証データがＦｕｓｅによって記録される、更新が発生しないリカバリー用ファームウェアを格納し、ＮＯＲ型フラッシュメモリの他の領域には、更新が発生する重要データを格納するという組み合わせを低コストで実現できる。

【0085】

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

【符号の説明】

【0086】

１…ストレージ装置、２…ホスト、１０…コントローラ、１１…Security ＣＰＵ、１２－１，１２－２…一般的なＣＰＵ、２０…揮発性メモリ、３０…不揮発性メモリ、３０Ａ…高セキュリティ領域、３０Ｂ…通常領域、３１，３２－１，３２－２…通常動作用ファームウェア、３３，３４－１，３４－２…リカバリー用ファームウェア、３５…重要データ、３６…リカバリー用重要データ、４０…読み出し専用メモリ、１１１…検知部、１１２…リカバリー判定部、１１３…リカバリー実行部、１１４…セキュリティ保証データ。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】