特許 6204555 不揮発性メモリに格納した変数を保護する方法、システム・ファームウェアおよびコンピュータ

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

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

(11)【特許番号】6204555

(24)【登録日】2017年9月8日

(45)【発行日】2017年9月27日

(54)【発明の名称】不揮発性メモリに格納した変数を保護する方法、システム・ファームウェアおよびコンピュータ

(51)【国際特許分類】

   G06F 9/445 20060101AFI20170914BHJP

【ＦＩ】

   G06F9/06 610J

【請求項の数】17

【全頁数】16

(21)【出願番号】特願2016-183556(P2016-183556)

(22)【出願日】2016年9月21日

【審査請求日】2016年9月21日

(73)【特許権者】

【識別番号】505205731

【氏名又は名称】レノボ・シンガポール・プライベート・リミテッド

(74)【代理人】

【識別番号】100106699

【弁理士】

【氏名又は名称】渡部 弘道

(72)【発明者】

【氏名】佐々木 健

(72)【発明者】

【氏名】森重 勇作

(72)【発明者】

【氏名】内田 宏幸

(72)【発明者】

【氏名】荒木 直幸

【審査官】 石川 亮

(56)【参考文献】

【文献】 特開２０１５−２２２４７４（ＪＰ，Ａ）

【文献】 特開２０１５−１５３１９８（ＪＰ，Ａ）

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

Ｇ０６Ｆ ９／４４５

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

【請求項1】

オペレーティング・システムが改変することが可能な変数を格納した不揮発性メモリを実装するコンピュータに、
前記変数を参照してプリブートを実行する機能と、
前記変数を保護対象変数と非保護対象変数のいずれかとして認識する機能と、
前記保護対象変数を代替メモリにコピーする機能と、
前記変数にアクセスするためのリクエストがあったときに、該リクエストが前記プリブートの終了前に発生したことの認識に応じて前記リクエストのアクセス先を前記不揮発性メモリと判断する機能と
を実現させるためのシステム・ファームウェア。

【請求項2】

前記保護対象変数は前記システム・ファームウェアがブートルーチンを実行するために前記プリブートで参照する変数である請求項１に記載のシステム・ファームウェア。

【請求項3】

前記保護対象変数は前記オペレーティング・システムがロードするブート・イメージの格納場所を指定する変数である請求項１に記載のシステム・ファームウェア。

【請求項4】

前記リクエストが前記変数の書き込みである請求項１に記載のシステム・ファームウェア。

【請求項5】

前記認識する機能が、前記保護対象変数の識別子を登録したリストを参照する請求項１に記載のシステム・ファームウェア。

【請求項6】

前記代替メモリが、揮発性のメモリである請求項１に記載のシステム・ファームウェア。

【請求項7】

前記コピーする機能を、前記不揮発性メモリがライト・ロックされるまでの間に実行する請求項１に記載のシステム・ファームウェア。

【請求項8】

オペレーティング・システムが改変することが可能な変数を格納した不揮発性メモリを実装するコンピュータに、
前記変数を参照してプリブートを実行する機能と、
前記変数を保護対象変数と非保護対象変数のいずれかとして認識する機能と、
前記保護対象変数を代替メモリにコピーする機能と、
前記変数にアクセスするためのリクエストがあったときに、前記システム・ファームウェアのセット・アップ画面を通じて前記変数の保護がディスエーブルに設定されていることの認識に応じて前記リクエストのアクセス先を前記不揮発性メモリと判断する機能と
を実現させるためのシステム・ファームウェア。

【請求項9】

オペレーティング・システムが改変することが可能な変数を格納した不揮発性メモリを実装するコンピュータに、
前記変数を参照してプリブートを実行する機能と、
前記変数を保護対象変数と非保護対象変数のいずれかとして認識する機能と、
前記保護対象変数を代替メモリにコピーする機能と、
前記変数にアクセスするためのリクエストがあったときに、該リクエストの対象が前記非保護対象変数であることの認識に応じて前記リクエストのアクセス先を前記不揮発性メモリと判断する機能と
を実現させるためのシステム・ファームウェア。

【請求項10】

オペレーティング・システムが改変することが可能な変数を格納した不揮発性メモリを実装するコンピュータに、
前記変数を参照してプリブートを実行する機能と、
前記変数を保護対象変数と非保護対象変数のいずれかとして認識する機能と、
前記保護対象変数を代替メモリにコピーする機能と、
前記変数にアクセスするためのリクエストがあったときに、該リクエストが前記プリブートの終了後に発生し、かつ、前記リクエストの対象が前記保護対象変数であるとの認識に応じて前記リクエストのアクセス先を前記代替メモリと判断する機能と
を実現させるためのシステム・ファームウェア。

【請求項11】

コンピュータが不揮発性メモリに格納した変数を保護する方法であって、
前記変数を保護対象変数と非保護対象変数に区分するステップと、
前記変数を参照してブートを実行するステップと、
前記保護対象変数を代替メモリにコピーするステップと、
オペレーティング・システムから前記変数を改変するリクエストを受け取るステップと、
前記リクエストの対象が前記保護対象変数のときに前記代替メモリにコピーした保護対象変数を改変するステップと
を有する方法。

【請求項12】

前記リクエストの対象が前記非保護対象変数のときに前記不揮発性メモリに格納した前記非保護対象変数を改変するステップを有する請求項１１に記載の方法。

【請求項13】

次回のブートの前に前記代替メモリが記憶する改変された前記保護対象変数を消去するステップを有する請求項１１に記載の方法。

【請求項14】

システム・ファームウェアが参照する変数を格納する不揮発性メモリと、
前記変数を保護対象変数と非保護対象変数に区別することが可能な制御リストと、
プリブートが終了する前に前記保護対象変数を代替メモリに退避する退避部と、
前記変数にアクセスするためのリクエストがあったときに、該リクエストが前記プリブートの終了前に発生したことの認識に応じて前記リクエストのアクセス先を前記不揮発性メモリに設定する変数保護部と
を有するコンピュータ。

【請求項15】

システム・ファームウェアが参照する変数を格納する不揮発性メモリと、
前記変数を保護対象変数と非保護対象変数に区別することが可能な制御リストと、
プリブートが終了する前に前記保護対象変数を代替メモリに退避する退避部と、
前記変数にアクセスするためのリクエストがあったときに、前記システム・ファームウェアのセット・アップ画面を通じて前記変数の保護がディスエーブルに設定されていることの認識に応じて前記リクエストのアクセス先を前記不揮発性メモリに設定する変数保護部と
を有するコンピュータ。

【請求項16】

システム・ファームウェアが参照する変数を格納する不揮発性メモリと、
前記変数を保護対象変数と非保護対象変数に区別することが可能な制御リストと、
プリブートが終了する前に前記保護対象変数を代替メモリに退避する退避部と、
前記変数にアクセスするためのリクエストがあったときに、該リクエストの対象が前記非保護対象変数であることの認識に応じて前記リクエストのアクセス先を前記不揮発性メモリに設定する変数保護部と
を有するコンピュータ。

【請求項17】

システム・ファームウェアが参照する変数を格納する不揮発性メモリと、
前記変数を保護対象変数と非保護対象変数に区別することが可能な制御リストと、
プリブートが終了する前に前記保護対象変数を代替メモリに退避する退避部と、
前記変数にアクセスするためのリクエストがあったときに、該リクエストが前記プリブートの終了後に発生し、かつ、前記リクエストの対象が前記保護対象変数であるとの認識に応じて前記リクエストのアクセス先を前記代替メモリに設定する変数保護部と
を有するコンピュータ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、コンピュータの動作不良を防止する技術に関し、さらには、ＵＥＦＩ（Unified Extensible Firmware Interface）規格に適合するコンピュータが格納する変数を保護する技術に関する。

【背景技術】

【0002】

コンピュータのファームウェアは、主としてハードウェアとオペレーティング・システム（ＯＳ）、デバイス・ドライバまたはアプリケーションなどの上位のプログラムとの間のインターフェースを提供するコードである。ファームウェアは、周辺デバイスを専用に制御するデバイス・ファームウェアとシステム全体の動作にかかわるシステム・ファームウェア（プラットフォーム・ファームウェアともいう。）に分けることができる。

【0003】

システム・ファームウェアは通常マザーボードに取り付けられた不揮発性メモリ（ＮＶＲＡＭ）に格納されている。ＢＩＯＳはこれまで多くのコンピュータ・システムに実装されてきたシステム・ファームウェアで、コンピュータの電源が起動してからＯＳがロードを開始するまでの間にＰＯＳＴ（Power On Self-Test）およびパスワード処理をしたり、ＯＳがハードウェアにアクセスする為のサービスを提供したりする。

【0004】

しかしＢＩＯＳは、近年の進化したハードウェアに対する対応が困難になってきたため、ＵＥＦＩフォーラムが、従来のＢＩＯＳであるレガシーＢＩＯＳに代わる新しいシステム・ファームウェアとしてＵＥＦＩ規格を策定した。ＵＥＦＩ規格では、バリアブル・サービス（Variable Services）を規定している。バリアブル・サービスは、不揮発性のメモリにＵＥＦＩ規格で定義した変数であるグローバル・バリアブルズ（ＧＶ：Global Variables）を格納する。

【0005】

一般にパーソナル・コンピュータ（ＰＣ）は、ＵＥＦＩファームウェアを格納する不揮発性メモリにＧＶを登録している。ＵＥＦＩ規格ではＧＶの公開性を規定し、ＯＳやＯＳアプリケーションが登録されたＧＶに対する修正、削除、および追加をすることができる。特許文献１はブート時に所定のＧＶが改変されたと判断したときにあらかじめ登録しておいたデフォルト値で修正する発明を開示する。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特開２０１５−１５３１９８号公報

【発明の概要】

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

【0007】

ＧＶは、ＵＥＦＩファームウェアがブートルーチンで使用するブート・デバイスまでのパス、ブート・デバイスの選択順位、およびハードウェアの構成に関するデータを含む。このようなＧＶがＯＳによって改変されるとＵＥＦＩファームウェアは予定するＰＣの起動処理ができなくなって、システムの起動失敗やハードウェアの動作不良に至ることがある。したがって、ＵＥＦＩファームウェアがブートルーチンを正しく実行するためには、主要なＧＶの一貫性を維持する必要がある。

【0008】

しかし、ＵＥＦＩ規格によるＧＶの公開性により、誤ったパラメータの設定による書き込みやマルウェアによる書き込みによって、ＧＶが改変されることがある。レガシーＢＩＯＳでは、ＧＶに相当する変数を書き込んだ不揮発性メモリをＯＳの実行環境に対してライト・プロテクトすることができたが、公開性が要求される保護対象ＧＶに対してはそのような手法を採用することができない。

【0009】

さらにＯＳは、所定のＧＶを改変しないとインストールできないことがある。したがって、ＵＥＦＩ規格で規定する認証サービス（Variable Authentication）を利用して保護対象ＧＶに対して個別にライト・プロテクトすることも、不揮発性メモリをライト・ロックすることもできない。特許文献１の発明では、前回のブートにおいてＯＳがＧＶを改変したり消去したりすると今回のブート時にＵＥＦＩファームウェアがデフォルト値でＧＶを書き換えるため、ＯＳに対してＧＶの書き換えを許容しながらＵＥＦＩファームウェアのブートルーチンに支障がでないようにすることができる。

【0010】

しかし、不揮発性メモリの書き換えはブート時間の遅延をもたらす。また、ＯＳは頻繁にＧＶを改変するためブートごとに書き換えが発生する。不揮発性メモリは消去および書き込み回数が増加すると酸化膜が劣化して記憶保持の信頼性が低下する。本発明はこのような背景のもとに、ＵＥＦＩファームウェアのようなシステム・ファームウェアが起動時に参照する変数を保護するための諸問題を解決することを目的にする。

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

【0011】

本発明の一の態様では、不揮発性メモリはオペレーティング・システムが改変することが可能な変数を格納する。システム・ファームウェアはコンピュータに、変数を参照してプリブートを実行する機能と、変数を保護対象変数と非保護対象変数のいずれかとして認識する機能と、保護対象変数を代替メモリにコピーする機能と、変数にアクセスするためのリクエストに応じてアクセス先を判断する機能とを実現させる。変数はＵＥＦＩ規格で定義するグローバル・バリアブルであってもよい。

【0012】

本発明の他の態様では、コンピュータが不揮発性メモリに格納した変数を保護する。変数を保護対象変数と非保護対象変数に区分するステップと、変数を参照してブートを実行するステップと、保護対象変数を代替メモリにコピーするステップと、オペレーティング・システムから変数を改変するリクエストを受け取るステップと、リクエストの対象が保護対象変数のときに代替メモリにコピーした保護対象変数を改変するステップとを有する。リクエストの対象が非保護対象変数のときは、不揮発性メモリに格納した非保護対象変数を改変することができる

【発明の効果】

【0013】

本発明により、以下のいずれかまたはすべての効果を奏することができた。第１に、システム・ファームウェアがアクセスする変数を保護することができた。第２にＯＳが正常に動作できるようにしながらそのような変数を保護することができた。さらに、ブートの遅延をもたらさないようにしながらそのような変数を保護することができた。さらに、不揮発性メモリに対する書込回数が増大しないようにしながらそのような変数を保護することができた。

【図面の簡単な説明】

【0014】

【図1】ＰＣ１０の主要なハードウェアの構成を示す概略の機能ブロック図である。

【図2】ファームウェアＲＯＭ１００のデータ構造の一例を示す図である。

【図3】ＰＣ１０が実装するソフトウェアの実行状態における階層構造を示す図である。

【図4】ＵＥＦＩファームウェア１５０が変数領域に対するアクセスを制御する手順の一例を示すフローチャートである。

【図5】保護対象ＧＶ１５３をＳＭＲＡＭ領域１５ａにコピーする手順の一例を示すフローチャートである。

【図6】バリアブル・サービスの動作手順の一例を示すフローチャートである。

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

【0015】

［ハードウェアの概略構成］
図１は、ノートブック型またはラップトップ型のＰＣ１０の主要なハードウェアの構成を示す機能ブロック図である。多くのハードウェアの構成は周知であるため、本発明の理解に必要な範囲で説明する。チップセット１３はさまざまな規格のインターフェース機能を備えており、ＣＰＵ１１、システム・メモリ（ＲＡＭ）１５、ＧＰＵ１７、ＨＤＤ２１、ＵＳＢコネクタ２３、有線または無線のＬＡＮに接続するためのネットワーク・モジュール２５、およびキーボード２９などが接続されている。ＧＰＵ１７にはＬＣＤ１９が接続されている。さらにチップセット１３が含む、ＳＰＩ（Serial Peripheral Interface）コントローラ１４にはファームウェアＲＯＭ１００が接続されている。

【0016】

システム・メモリ１５のメモリ空間には、システムの電源が起動したときにＳＭＲＡＭ領域１５ａが確保される。ＳＭＲＡＭ領域１５ａは、ＣＰＵ１１がシステム・マネジメント・モード（ＳＭＭ）で動作するときに実行するコードをロードする領域である。ＨＤＤ２１はブート・デバイスで、ＵＥＦＩ規格に対応するＯＳのブート・イメージを格納する。

【0017】

ＨＤＤ２１のブート・セクタは、ＯＳのブート・イメージをロードするためのＵＥＦＩ＿ＯＳローダー１６３（図３）を格納する。ＵＳＢコネクタ２３には、外付けのＵＳＢメモリ、ＵＳＢ＿ＣＤ、ＵＳＢ＿ＦＤＤ、ＵＳＢ＿ＨＤＤなどのＵＳＢデバイスを接続することができる。ＰＣ１０は、ＵＳＢコネクタ２３に接続されたブート・イメージを格納するＵＳＢデバイスからブートすることもできる。ＰＣ１０は、ＰＸＥ（Preboot eXecution Environment）などの機能により、ネットワーク・モジュール２５を通じてＯＳのブート・イメージを受け取ってＰＸＥブートすることもできる。

【0018】

［ファームウェアＲＯＭのデータ構造］
図２は、ファームウェアＲＯＭ１００のデータ構造を示す図で、図３はシステム・メモリ１５にロードされて実行状態にあるソフトウェアの階層構造を示す図である。ファームウェアＲＯＭ１００は、不揮発性で記憶内容の電気的な書き替えが可能なフラッシュ・メモリで、一例としてコード領域１０１、変数領域１０３〜１０９およびデータ領域１１１からなる記億ブロックに区分している。変数領域１０３〜１０９およびデータ領域１１１の記億ブロックは、ファームウェアＲＯＭ１００とは異なる不揮発性メモリに設けてもよい。

【0019】

コード領域１０１は、ＵＥＦＩファームウェア１５０およびＵＥＦＩアプリケーション１６５のコードを格納する。変数領域１０３はデフォルトＧＶ１５１を格納し、変数領域１０５は保護対象ＧＶ１５３と非保護対象ＧＶ１５５からなるＧＶを格納する。なお、以下において保護対象ＧＶ１５３と非保護対象ＧＶ１５５を区別しないときは単にＧＶと称する。変数領域１０７はConfiguration Variables（ＣＶ）１５７を格納し、変数領域１０９はUser Variables（ＵＶ）１５９を格納する。データ領域１１１は制御リスト１６１を格納する。

【0020】

最初に変数領域１０３〜１０９が格納する変数について説明する。デフォルトＧＶ１５１はＵＥＦＩベンダーが書き込んだＧＶで、システムの動作に異常が発生した場合や何らかの理由で必要がある場合にユーザがシステムを初期化するために利用する。本実施の形態ではデフォルトＧＶ１５１を、ブートごとに変数領域１０５のＧＶを置換するためには利用しない。

【0021】

ＧＶはＵＥＦＩ規格において定義されており、ＵＥＦＩファームウェア１５０、ＵＥＦＩアプリケーション１６５、ＯＳ１６７およびＯＳアプリケーション１６９（図３）のいずれからもアクセスできることが保証されている。なお、以下においてはＯＳ１６７と称した場合にＯＳアプリケーション１６９も含む場合がある。ＧＶに対するアクセスは、新たなＧＶの書き込み、変更、削除および読み取りなどに相当する。ＧＶの書き込み、変更および削除は、オリジナル・バリアブル・サービス１５０ｂまたは新バリアブル・サービス１５０ｆのファンクションを構成するSetVariableという関数を呼び出す。

【0022】

ＧＶの読み取りはオリジナル・バリアブル・サービス１５０ｂまたは新バリアブル・サービス１５０ｆのファンクションを構成するGetVariableという関数を呼び出す。保護対象ＧＶ１５３は、一例としてBoot####、BootOrder、BootNext、Driver####、DriverOrderといったブート・デバイスの種類とその選択順位、デバイス・ドライバの種類とその選択順位といったようなブートに関連する変数を含む。さらに保護対象ＧＶは、ConIn、ConOutといった入出力デバイスまでのパスのようなハードウェアの構成に関連する変数を含む。

【0023】

保護対象ＧＶ１５３がＵＥＦＩファームウェア１５０以外のプログラムによって書き換えられるとシステムが正常に起動できなくなる可能性がある。ＧＶの問題がある改変は、ＯＳ１６７、ＵＥＦＩアプリケーション１６５またはマルウェアがSetVariableを呼び出したときに発生する。保護対象ＧＶ１５３は、問題がある改変から保護する対象となる変数に相当する。

【0024】

ユーザは、ＵＥＦＩファームウェア１５０のセット・アップ画面を通じて保護対象ＧＶ１５３を改変することができる。この場合、ＵＥＦＩファームウェア１５０が認識しているため問題がある改変には相当しない。ＧＶの保護は、ＵＥＦＩファームウェア１５０がブートルーチンを実行するためにアクセスする場所の一例である変数領域１０５に格納した保護対象ＧＶ１５３が、ＵＥＦＩファームウェア１５０以外のプログラムによって改変されないようにすることを意味する。

【0025】

本実施の形態では、図４〜図７で説明するようにＧＶを保護しながらＯＳ１６７が所定の動作のために必要な保護対象ＧＶ１５３にアクセスすることを可能にする。非保護対象ＧＶ１５５は、保護対象ＧＶ１５３以外のＧＶで、ブートやハードウェアの構成に関係しない変数に相当する。非保護対象ＧＶ１５５は、ＵＥＦＩファームウェア１５０がブートルーチンを実行する際に、変数領域１０５にＵＥＦＩファームウェア１５０以外のプログラムで改変された状態で存在してもよい。

【0026】

ＣＶ１５７は、ＵＥＦＩファームウェア１５０が、ブートの際にデバイスの認識や初期化などの処理をするために、変数領域１０７に書き込んだ変数に相当する。ＣＶ１５７は、ＵＥＦＩファームウェア１５０のベンダーが定義する。ＵＥＦＩファームウェア１５０は、オリジナル・バリアブル・サービス１５０ｂを利用してＣＶ１５７を書き込むことができる。

【0027】

ＣＶ１５７はＵＥＦＩファームウェア１５０が設定するデバイスの属性情報およびデバイスに設定するパラメータ、セット・アップ画面を呼び出してユーザが設定したデバイスの種類、デバイスの動作モード、およびデバイスの有効／無効などの設定情報、ブート・イメージが格納されているパーティションのパスやロードするＯＳの種類などの情報を含む。ＣＶ１５７はブートに不可欠な変数を含むが、ＵＥＦＩ規格では公開性が要求されないので変数領域１０７をライト・ロックしてＯＳ１６７やマルウェアによる改変から保護することができる。

【0028】

ＵＶ１５９は、ＯＳ１６７、ＵＥＦＩアプリケーション１６５が、その実行に際して自らをカスタマイズするための環境変数や、デバッグ・ログまたはエラー・ログのようなダンプ・ファイルをＵＥＦＩ規格の制約を受けないで自由に書き込む変数に相当する。ＵＥＦＩファームウェア１５０は、オリジナル・バリアブル・サービス１５０ｂを利用してＵＶ１５９を書き込むことができる。

【0029】

本実施の形態では、コード領域１０１、変数領域１０３、１０７およびデータ領域１０９に、チップセット１３のＳＰＩコントローラ１４においてライト・ロックが可能な記録領域を割り当てている。ライト・ロックが実行された記録領域に対しては、チップセット１３がリセットされるまですべてのプログラムの書き込みが禁止される。ＵＥＦＩファームウェア１５０は、ブートの際に安全が保証されたコードから、他のコードにＣＰＵ１１の制御権を渡す前にファームウェアＲＯＭ１００のコード領域１０１、変数領域１０３、１０７およびデータ領域１１１をライト・ロックすることができる。

【0030】

ＵＥＦＩファームウェア１５０は、初期化コード１５０ａ、オリジナル・バリアブル・サービス（Variable Services）１５０ｂ、ブート・マネージャ１５０ｃ、セット・アップ・コード１５０ｄ、ＧＶ制御コード１５０ｅ、新バリアブル・サービス１５０ｆ、およびＵＥＦＩドライバ１５０ｇを含む。ＵＥＦＩファームウェア１５０は一例において、書き換えに伴うリスクを軽減するためにブート・ブロック方式を採用することができる。ブート・ブロック方式では、初期化コード１５０ａを格納する領域をブート・ブロックに設定する。ブート・ブロックに格納されたコードはＴＰＭ（Trusted Platform Module）の仕様書に規定するＣＲＴＭ（Core Root Of Trust Measurement）として扱われ特別な権限がないと書き換えができないようになっている。

【0031】

ＣＲＴＭは、プラットフォームの初期化コードの中で完全性が保証されている部分として構成され、プラットフォームのリセット時には必ず最初に実行される。ＣＲＴＭは、ＰＣ１０がＡＣＰＩに規定するハイバネーション状態（Ｓ４ステート）またはパワー・オフ状態（Ｓ５ステート）からパワー・オン状態（Ｓ０ステート）に遷移するための動作プロセスであるいわゆるコールド・ブートのときに必ず最初に実行される。

【0032】

初期化コード１５０ａは、ＰＣ１０がコールド・ブートをする際に、システム・メモリ１５にＵＥＦＩファームウェア１５０をロードして実行を開始するために必要なＣＰＵ１１、システム・メモリ１５およびその他の基本的なデバイスの検出、検査および初期化を必要な範囲で行う。初期化コード１５０ａはまた、ＣＰＵ１１がリセットしてから、ＵＥＦＩ＿ＯＳローダー１６３に制御が移行するまでの期間にチップセット１３のコントローラや周辺デバイスなどの所定のデバイスを初期化して使用できる状態にする。初期化コード１５０ａは、ＵＥＦＩファームウェア１５０のコードのオリジナルからの一貫性または完全性を検査して改竄を発見した場合はブートを停止する。

【0033】

オリジナル・バリアブル・サービス１５０ｂは、変数領域１０５に格納したＧＶにアクセスするためのGetVariable、 GetNextVariableName、SetVariableなどのファンクションを含む。ブート・マネージャ１５０ｃは、ブート処理およびパスワード認証処理などを行う。ブート・マネージャ１５０ｃは、ＵＥＦＩファームウェア１５０によるブートルーチンが終了すると、ＵＥＦＩアプリケーション１６５、およびＵＥＦＩ＿ＯＳローダー１６３をシステム・メモリ１５にロードする。ここに、システムがコールド・ブートしてからＵＥＦＩファームウェア１５０以外のコードにＣＰＵ１１の制御権が移るまでの動作状態をプリブートという。

【0034】

プリブートは、ＣＲＴＭにより一貫性が検証されたコードを実行する動作状態ということができる。プリブートはあるいはＳＰＩコントローラ１４によりコード領域１０１がライト・ロックされるまでの動作状態ということもできる。プリブートの間は、安全性が確保されたＵＥＦＩファームウェア１５０だけが変数領域１０５のＧＶを改変することができる。ブート・マネージャ１５０ｃは、プリブートが終了してＵＥＦＩファームウェア１５０からＯＳ１６７にＣＰＵ１１の制御権が移る直前に、ＵＥＦＩ＿ＯＳローダー１６３をシステム・メモリ１５に読み出して完全性の検証をすることができる。

【0035】

本明細書でブートとは、電源が起動してからプリブートを経由してＯＳ１６７のロードが完了した状態になるまでの一連の処理をいう。ＵＥＦＩ＿ＯＳローダー１６３には作成者が計算したハッシュ値を秘密鍵で暗号化した電子署名が付されている。ブート・マネージャ１５０ｃは、ＵＥＦＩ＿ＯＳローダー１６３のコードから計算したハッシュ値と、署名データ・ベースから取得した公開鍵で復号して得た電子署名のハッシュ値を比較して、一致していれば完全性が維持されていると判断してＵＥＦＩ＿ＯＳローダー１６３の実行を許可する。

【0036】

セット・アップ・コード１５０ｄは、プリブートの段階でキーボード２９の所定のファンクション・キーが押下されたたときに、ＬＣＤ１９にセット・アップ画面を表示する。ユーザはセット・アップ画面を通じて、ブート・デバイスの優先順位の決定、起動方法の設定、使用デバイスの設定、パスワードの設定およびパワー・マネジメントの設定などをすることができる。

【0037】

セット・アップ・コード１５０ｄは、セット・アップ画面を通じて入力された設定情報を一例として変数領域１０７にＣＶとして書き込む。セット・アップ・コード１５０ｄを通じて行われる保護対象ＧＶの改変は、ＵＥＦＩファームウェア１５０が認識しているのでブートルーチンに問題を生じさせない。また、ＵＥＦＩアプリケーション１６５とＯＳ１６７は、独自の必要性に基づいてＧＶを改変することができる。

【0038】

その結果、保護対象ＧＶ１５３の改変がＵＥＦＩファームウェア１５０のブートルーチンに影響を与える場合があるため、本実施の形態では、ＵＥＦＩアプリケーション１６５やＯＳ１６７による改変から変数領域１０５の保護対象ＧＶ１５３を保護する。他方で、ＯＳ１６７が保護対象ＧＶ１５３を改変しないと意図する動作環境を構築できない場合がある。このような状況に対処するために、セット・アップ画面は、本実施の形態にかかるＧＶの保護機能に対してイネーブル／ディスエーブルの設定をするメニューを含む。イネーブル／ディスエーブルの設定情報は、ファームウェアＲＯＭ１００の所定の場所に記録される。

【0039】

ＧＶ制御コード１５０ｅは、図４〜図７の手順で説明するＧＶの保護のための処理をする。新バリアブル・サービス１５０ｆは図６、図７で説明するように、ＯＳ１６７やＵＥＦＩアプリケーション１６５がＳＭＲＡＭ領域１５ａにコピーした保護対象ＧＶ１５３にアクセスするためのGetVariable、GetNextVariableName、SetVariableなどのファンクションを含む。ＵＥＦＩアプリケーション１６５は、ＵＥＦＩファームウェア１５０の上層で動作し、ＵＥＦＩドライバ１５０ｇは、ＵＥＦＩファームウェア１５０が特定のハードウェアにアクセスするための処理をする。制御リスト１６１は、保護対象ＧＶ１５３の識別子（VendorGuidおよびVariableName）を記述する。

【0040】

［保護対象ＧＶの改変を禁止する手順］
図４〜図７は、ＵＥＦＩファームウェア１５０がＧＶを保護する手順の一例を示すフローチャートである。図４のブロック２０１で、ＰＣ１０の電源が起動してシステムがコールド・ブートを開始する。このとき図２に示すように、変数領域１０５には、保護対象ＧＶ１５３と非保護対象ＧＶ１５５が格納され、変数領域１０７にはＣＶ１５７が格納され、変数領域１０９にはＵＶ１５９が格納され、データ領域１１１には、制御リスト１６１が格納されている。図６で詳細に説明するブロック２１７の手順があるため、変数領域１０５が格納する保護対象ＧＶ１５３は、前回のブートで改変されていないことが保証されている。

【0041】

パワー・オン・リセットしたチップセット１３は、ブロック２０３でＳＰＩコントローラ１４に設定していたファームウェアＲＯＭ１００のコード領域１０１、変数領域１０３、１０７およびデータ領域１１１に対するライト・ロックを解除する。つづいてブロック２０５で初期化コード１５０ａがプリブートに必要なデバイスを初期化すると、ＵＥＦＩファームウェア１５０がシステム・メモリ１５にロードされる。初期化コード１５０ａはつづいて変数領域１０５が格納する保護対象ＧＶ１５３、および変数領域１０７が格納するＣＶ１５７を参照して、必要な範囲でその他のデバイスを初期化する。つづいてＵＥＦＩファーウェア１５０はＰＯＳＴ（Power On Self-Test）を開始する。

【0042】

プリブートの間ブロック２０７でＵＥＦＩファームウェア１５０は、変数領域１０５のＧＶを改変する。ＵＥＦＩファームウェア１５０は、初期化コード１５０ａによって一貫性が検証されているか、ＯＳの動作環境ではＳＰＩコントローラ１５ａのライト・ロックによって保護されているためマルウェアによる汚染の恐れがなく、保護対象ＧＶ１５３が改変されても次回のプリブートに支障をきたすことはない。ブロック２０８で、ユーザはセット・アップ画面を呼び出してＧＶの保護機能をイネーブルまたはディスエーブルに設定することができる。

【0043】

ブロック２０９でＧＶ制御コード１５０ｅは、変数領域１０５が格納するＧＶのなかで保護対象ＧＶ１５３だけを、システム・メモリ１５のＳＭＲＡＭ領域１５ａのような代替メモリにコピーする。システム・メモリ１５は書き込み速度が速いため代替メモリとして望ましいが、退避先をシステム・メモリ１５に限定する必要はない。また、代替メモリにコピーする保護対象ＧＶ１５３は次回のプリブートで使用しないため、代替メモリは揮発性メモリでも不揮発性メモリでもよい。保護対象ＧＶ１５３をコピーするタイミングは、ＵＥＦＩファームウェア１５０による保護対象ＧＶ１５３の改変が終了してからプリブートが終了するまでの間とすることができる。

【0044】

図５は、図４のブロック２０９の手順の一例を示すフローチャートである。ブロック２１３でプリブートの終了のタイミングを認識したＧＶ制御コード１５０ｅはブロック２３３で、オリジナル・バリアブル・サービス１５０ｂのGetNextVariableNameを呼び出して変数領域１０５からＧＶを読み取る。GetNextVariableNameは、システムにおいて利用可能なＧＶ、ＣＶ、ＵＶすべての変数を列挙する関数で、呼び出されたときに保持する変数の次の変数の識別子をＧＶ制御コード１５０ｅに戻す。GetNextVariableNameは、ＧＶ、ＣＶ、ＵＶのすべての識別子を戻したあとにさらに呼び出されたときはエラーを戻す。ブロック２３５でＧＶ制御コード１５０ｅは、オリジナル・バリアブル・サービス１５０ｂからエラーを受け取ったときにＧＶ、ＣＶ、ＵＶのすべての変数を読み取ったと判断してブロック２４１で終了する。

【0045】

オリジナル・バリアブル・サービス１５０ｂから変数の識別子を受け取ったＧＶ制御コード１５０ｅはブロック２３７で、制御リスト１６１を参照して読み出したＧＶが制御リスト１６１に登録された保護対象ＧＶ１５３であるか否かを判断する。保護対象ＧＶ１５３であると判断したときはブロック２３９に移行し、非保護対象ＧＶ１５５であると判断したときはブロック２３３に戻る。ブロック２３９でＧＶ制御コード１５０ｅは、当該保護対象ＧＶ１５３をＳＭＲＡＭ領域１５ａにコピーしてからブロック２３３に戻る。

【0046】

ＧＶ制御コード１５０ｅはブロック２３３でさらにGetNextVariableNameを呼び出して、次の変数の識別子を取得してブロック２３７で保護対象ＧＶ１５３であるか否かを判断する。ブロック２３１〜２４１の手順を実行すると変数領域１０５に格納されたＧＶのなかで、保護対象ＧＶ１５３がすべてＳＭＲＡＭ領域１５ａにコピーされる。

【0047】

ＳＭＲＡＭ領域１５ａへのコピーは、他の方法でも行うことができる。たとえば、変数領域１０５を保護対象ＧＶ１５３だけを格納する記憶ブロックと非保護対象ＧＶ１５５だけを格納する記憶ブロックに区分する。コピーの際には、保護対象ＧＶ１５３だけを格納する記憶ブロックのアドレスを指定する。この方法によれば、制御リスト１６１を利用しないですべての保護対象ＧＶ１５３をコピーすることができる。

【0048】

図４に戻ってブロック２１１でＧＶ制御コード１５０ｅは、プリブートが終了する直前に、コード領域１０１、変数領域１０３、１０７およびデータ領域１１１をライト・ロックするためにチップセット１３のＳＰＩコントローラ１４を設定する。ブロック２１３でプリブートが終了すると、ブロック２１５で、ブート・マネージャ１５０ｃは、コード領域１０１からシステム・メモリ１５０にＵＥＦＩアプリケーション１６５をロードし、ＨＤＤ２１の所定のセクタからＵＥＦＩ＿ＯＳローダー１６３をロードする。

【0049】

やがてＯＳ１６７がロードされてＰＣ１０はＯＳブート状態に移行する。ブロック２１７でＯＳ１６７はＧＶにアクセスすることができる。ブロック２１７の手順の詳細は図６を参照して説明する。ブロック２１９でパワー・オフ状態に遷移したあとに、ブロック２０１に戻って次回のコールド・ブートをする。このときブロック２１７の手順で、変数領域１０３の保護対象ＧＶ１５３が保護されているため次回のプリブートが失敗することはない。

【0050】

図６は、図４のブロック２１７の手順の一例を示すフローチャートである。ブロック２５１でＵＥＦＩファームウェア１５０、ＵＥＦＩアプリケーション１６５、ＯＳ１６７のいずれかに相当するコーラーがGetVariable、またはSetVariableを呼び出してＧＶにアクセスする。ブロック２５３〜２５６は、ＧＶの保護条件の判断に相当する。ブロック２５３でＧＶ制御コード１５０ｅは、アクセスがプリブート中に行われたと判断したときはブロック２６１に移行し、プリブートが終了した後に行われたと判断したときはブロック２５５に移行する。

【0051】

ブロック２５３からブロック２６１に移行するときは、保護対象ＧＶ１５３と非保護対象ＧＶ１５５のいずれかがアクセスの対象になっている。プリブートが終了したあとの動作環境で、変数領域１０５が格納する保護対象ＧＶ１５３の改変を許可すると、次回のブートに問題がでる可能性があるため、ＧＶの保護機能は原則としてイネーブルに設定することが望ましい。しかし、ユーザが保護対象ＧＶ１５３の安全性を考慮した上で、変数領域１０５の保護対象ＧＶ１５３の改変を許可する必要がある場合もある。

【0052】

たとえば、ＯＳ１６７をローカルのブート・デバイスからブートするように保護対象ＧＶ１５３に設定しているときに、ネットワークを経由してＰＸＥブートをしたい場合がある。このとき、ＯＳ１６７が変数領域１０５の保護対象ＧＶ１５３のブート・オーダーを改変しないとリモート・ブートは実現できない。また、ウィルス対策ソフトの中には、プリブートの終了後にＯＳより先にロードして実行するものがある。この場合も、ウィルス対策ソフトによる変数領域１５３の保護対象ＧＶ１５３の改変を許容する必要がある。

【0053】

ＯＳ１６７が変数領域１０５の保護対象ＧＶ１５３を改変する必要があるときにユーザはセット・アップ画面を通じてＧＶの保護機能をディスエーブルに設定する。ブロック２５５でＧＶ制御コード１５０ｅはファームウェアＲＯＭ１００に記録された設定情報からＧＶの保護機能を判断する。ＧＶ制御コード１５０ｅは、ＧＶの保護機能がイネーブルに設定されているときはブロック２５６に移行し、ディスエーブルに設定されているときはブロック２６１に移行する。

【0054】

ブロック２５５からブロック２６１に移行するときは、保護対象ＧＶ１５３と非保護対象ＧＶ１５５のいずれかがアクセスの対象になっている。ブロック２５６でＧＶ制御コード１５０ｅは、制御リスト１６１を参照して、コーラーがアクセスするＧＶが保護対象ＧＶ１５３と判断したときはブロック２５７に移行し、非保護対象ＧＶ１５５と判断したときはブロック２６１に移行する。ブロック２５７でＧＶ制御コード１５０ｅは、新バリアブル・サービス１５０ｆにコーラーから要求されたＧＶの識別子を渡す。

【0055】

ブロック２５９で新バリアブル・サービス１５０ｆは、ＳＭＲＡＭ領域１５ａにコピーされた保護対象ＧＶ１５３にアクセスしてコーラーに識別子を返す。ブロック２６１でＧＶ制御コード１５０ｅは、オリジナル・バリアブル・サービス１５０ｂにコーラーから要求されたＧＶの識別子を渡す。ブロック２６３でオリジナル・バリアブル・サービス１５０ｂは、変数領域１０５の非保護対象ＧＶ１５５にアクセスしてコーラーに戻り値を返す。

【0056】

図６の手順では、ＧＶの保護条件が成立したときは、ＳＭＲＡＭ領域１５ａにコピーされた保護対象ＧＶ１５３はＯＳ１６７によって改変されるが、変数領域１０５の保護対象ＧＶ１５３は改変されない。ＯＳ１６７はアクセス先をＳＭＲＡＭ領域１５ａに指定する必要はなく、オリジナル・バリアブル・サービス１５０ｂにアクセスするのと同じ手順で保護対象ＧＶ１５３を改変しさらに改変した保護対象ＧＶ１５３を読み取って動作することができる。

【0057】

ＯＳ１６７は、保護対象ＧＶ１５３を改変しないと、インストールができない場合がある。たとえば、変数領域１０５の保護対象ＧＶ１５３にＰＸＥブートを第１順位として設定した状態でＯＳ１６７をインストールするときに、ＯＳ１６７は自らをブートの第１順位に設定しないとインストールが失敗することがある。図６の手順によれば、ＯＳ１６７はＳＭＲＡＭ領域１５ａ上でブートの順位を設定してインストールを成功させることができる。しかし変数領域１０５の保護対象ＧＶ１５３は改変されていないため、ＵＥＦＩファームウェア１０５はその後ＰＸＥブートをすることができる。

【0058】

ＯＳ１６７は変数領域１０５に記憶された非保護対象ＧＶ１５５を改変することができるが、非保護対象ＧＶ１５５の改変はシステムの動作に障害をもたらすことはない。図６の手順では、保護対象ＧＶ１５３をＳＭＲＡＭ領域１５ａにコピーする時間が必要になるが、ＳＭＲＡＭ領域１５ａへのコピーは変数領域１０５をデフォルトＧＶ１５１で書き換えるよりも短い時間で終了できるためブート時間の遅延問題は生じない。

【0059】

図４のブロック２１９でパワー・オフ状態に遷移すると、ＳＭＲＡＭ領域１５ａの保護対象ＧＶ１５３は消去される。ＯＳ１６７は、保護対象ＧＶ１５３を改変したつもりでも変数領域１０５の保護対象ＧＶ１５３は改変されなかったことになる。しかし、ＯＳ１６７が変数領域１０５の保護対象ＧＶ１５３を改変したとしても、次回のプリブートでユーザがセット・アップ画面を通じて当該保護対象ＧＶ１５３を改変するかもしれない。

【0060】

ＯＳ１６７は通常、変数領域１０５に格納された保護対象ＧＶ１５３を前回のブートで書き換えていたとしても、確実にみずからの環境設定をするために今回のブートでも保護対象ＧＶ１５３を改変する処理をする。したがって、ＯＳ１６７はブートごとに同じ改変の手順を繰り返すためＳＭＲＡＭ領域１５ａの保護対象ＧＶ１５３が消去されても次回のブートで追加的な処理が発生することはない。

【0061】

図４〜図６の手順では、ＯＳ１６７による変数領域１０５の保護対象ＧＶ１５３の改変を禁止し、非保護対象ＧＶ１５５の改変を許可した。ここでＯＳ１６７による変数領域１０５の非保護対象ＧＶ１５５の改変を禁止することも考えられる。しかし、非保護対象ＧＶ１５５の改変は、ＵＥＦＩファームウェア１５０のブートルーチンに支障がなく、むしろ、ＯＳ１６７が意図する動作環境を維持したほうが望ましいため、本実施の形態では、ＯＳ１６７による非保護対象ＧＶの改変を許可している。

【0062】

また、保護対象ＧＶ１５３と非保護対象ＧＶ１５５を一旦ＳＭＲＡＭ領域１５ａにコピーして、いずれに対する改変もＳＭＲＡＭ領域１５ａで行い、パワー・オフ状態に遷移する際に、改変された非保護対象ＧＶ１５５だけを変数領域１０５に書き込むようにすることも考えられる。このとき、突然電源が遮断してＳＭＲＡＭ領域１５ａのデータが消失したときに、改変した非保護対象ＧＶ１５５が消失するが本実施の形態ではそのような事態が生ずることはない。

【0063】

図４〜図６に示した手順は本発明を説明するための例示であり、すべてが本発明の必須の手順ではない。本発明の必須の手順は特許請求の範囲に記載するとおりである。また、各ブロックの順番も、図４〜図６に示した順番に限定するものではない。たとえば、図６のブロック２５３〜２５６の手順は任意の順番にしてもよい。本発明は、図１に示したハードウェアと図２、図３に示したソフトウェアの協働により構成するハードウェア要素で実現したシステムとして捉えることもできる。

【0064】

これまで本発明について図面に示した特定の実施の形態をもって説明してきたが、本発明は図面に示した実施の形態に限定されるものではなく、本発明の効果を奏する限り、これまで知られたいかなる構成であっても採用することができることはいうまでもないことである。

【符号の説明】

【0065】

１０ ＰＣ
１５ システム・メモリ
１５ａ ＳＭＲＡＭ領域
１００ ファームウェアＲＯＭ
１０１ コード領域
１０３、１０５、１０７、１０９ 変数領域
１５０ ＵＥＦＩファームウェア
１５０ｂ オリジナル・バリアブル・サービス
１５０ｆ 新バリアブル・サービス
１５３ 保護対象ＧＶ
１５５ 非保護対象ＧＶ

【要約】

【課題】ＵＥＦＩファームウェアが参照するＧＶを保護しながらＯＳの動作を確保する。
【解決手段】ファームウェアＲＯＭ１００には、ＵＥＦＩファームウェア１５０、保護対象ＧＶ１５３および非保護対象ＧＶ１５５が格納されている。保護対象ＧＶ１５３および非保護対象ＧＶ１５５は、ＵＥＦＩファームウェアがプリブートをするために参照する。ＯＳはプリブートの終了後にみずからの動作環境を構築するために保護対象ＧＶを改変することができる。ファームウェアＲＯＭに記録された保護対象ＧＶ１５３は、ブートやシステムの構成に関連するデータを含むためＯＳにより改変されると次回のプリブートが失敗することがある。ＵＥＦＩファームウェアは、プリブートが終了する前に保護対象ＧＶをシステム・メモリにコピーする。プリブートの終了後のＯＳによる保護対象ＧＶに対するアクセスはシステム・メモリ上で処理する。
【選択図】図２

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】