(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】5889933
(24)【登録日】2016年2月26日
(45)【発行日】2016年3月22日
(54)【発明の名称】コンピュータの動作不良を防止する方法、コンピュータ・プログラムおよびコンピュータ
(51)【国際特許分類】
G06F 9/445 20060101AFI20160308BHJP
【FI】
G06F9/06 610D
G06F9/06 610J
【請求項の数】16
【全頁数】17
(21)【出願番号】特願2014-27059(P2014-27059)
(22)【出願日】2014年2月15日
(65)【公開番号】特開2015-153198(P2015-153198A)
(43)【公開日】2015年8月24日
【審査請求日】2015年1月16日
(73)【特許権者】
【識別番号】505205731
【氏名又は名称】レノボ・シンガポール・プライベート・リミテッド
(74)【代理人】
【識別番号】100106699
【弁理士】
【氏名又は名称】渡部 弘道
(74)【代理人】
【識別番号】100132595
【弁理士】
【氏名又は名称】袴田 眞志
(72)【発明者】
【氏名】森重 勇作
(72)【発明者】
【氏名】佐々木 健
(72)【発明者】
【氏名】安藤 教博
【審査官】
石川 亮
(56)【参考文献】
【文献】
国際公開第2012/127522(WO,A1)
【文献】
米国特許出願公開第2012/0260082(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 9/445
(57)【特許請求の範囲】
【請求項1】
コンピュータに、
不揮発性メモリに設定された第1の変数領域と第2の変数領域を認識する機能と、
前記第1の変数領域にプリブートに不可欠な構成データを書き込む機能と、
前記第2の変数領域にシステム・ファームウェアが定義しオペレーティング・システムによる書き換えが可能な公開データを書き込む機能と、
前記オペレーティング・システムからのリクエストに応じて前記第2の変数領域にユーザ・データを書き込む機能と、
前記プリブートを終了したあとの前記第1の変数領域に対する書き込みを制限する機能と
を実現させるためのシステム・ファームウェア。
【請求項2】
前記書き込みを制限する機能が、前記第1の変数領域に接続されたインターフェース・コントローラをライト・ロックする機能を含む請求項1に記載のシステム・ファームウェア。
【請求項3】
前記書き込みを制限する機能が、前記オペレーティング・システムによる前記構成データを更新するためのリクエストを無効にする機能を含む請求項1または請求項2に記載のシステム・ファームウェア。
【請求項4】
前記プリブートの間に前記第2の変数領域の残容量を確認する機能と、
前記残容量が所定値未満になったときに前記第2の変数領域をクリーン・アップすることを示す画面を表示する機能と、
前記クリーン・アップの指示を受け取ったときに前記ユーザ・データを消去する機能と
を有する請求項1に記載のシステム・ファームウェア。
【請求項5】
前記構成データと前記公開データのデフォルト値を格納する第3の変数領域を認識する機能と、
前記プリブートの間に前記構成データおよび前記公開データのそれぞれと前記デフォルト値を比較する機能と、
いずれかの前記構成データまたは前記公開データが消去されたと判断したときに前記デフォルト値を前記第1の変数領域または前記第2の変数領域に書き込む機能と
を有する請求項1に記載のシステム・ファームウェア。
【請求項6】
前記システム・ファームウェアがUEFI規格に適合し、前記公開データは前記UEFI規格が定義するグローバル・バリアブルズである請求項1に記載のシステム・ファームウェア。
【請求項7】
前記プリブートの間に前記第2の変数領域に記録された前記グローバル・バリアブルズのなかでブートに関連するグローバル・バリアブルズのパラメータに対する改変の有無を判断する機能と、
前記パラメータが改変されたと判断したときにデフォルト値を書き込む機能と
を含む請求項6に記載のシステム・ファームウェア。
【請求項8】
前記ブートに関連するグローバル・バリアブルズが、Boot####、BootOrder、Drive####、DriveOrder、およびKey####である請求項7に記載のシステム・ファームウェア。
【請求項9】
前記オペレーティング・システムが、前記UEFI規格に対応してUEFIネイティブ・モードで動作する請求項6に記載のシステム・ファームウェア。
【請求項10】
UEFI規格に適合するシステム・ファームウェアと、プリブートに不可欠なコンフィグレーション・バリアブルズと、前記UEFI規格が定義するグローバル・バリアブルズと、前記UEFI規格に対応するオペレーティング・システムが作成したユーザ・バリアブルズを格納する不揮発性メモリを実装したコンピュータに、
前記コンフィグレーション・バリアブルズ、前記グローバル・バリアブルズ、または前記ユーザ・バリアブルズのいずれかに対する書き換えのリクエストを受け取る機能と、
プリブート中か否かを判断する機能と、
前記プリブート中だと判断したときに前記リクエストを処理する機能と、
前記プリブートが終了したと判断したときに前記コンフィグレーション・バリアブルズの書き換えを無効にする機能と
を実現させるためのシステム・ファームウェア。
【請求項11】
前記プリブートが終了したと判断したときに前記グローバル・バリアブルズおよび前記ユーザ・バリアブルズに対する書き換えのリクエストを処理する機能を含む請求項10に記載のシステム・ファームウェア。
【請求項12】
UEFI規格に適合するシステム・ファームウェアを格納する不揮発性メモリを実装したコンピュータの動作不良を防止する方法であって、
プリブートに不可欠なコンフィグレーション・バリアブルズを前記不揮発性メモリの第1の記録領域に書き込むステップと、
前記UEFI規格が定義するグローバル・バリアブルズを前記不揮発性メモリの第2の記録領域に書き込むステップと、
前記UEFI規格に対応するオペレーティング・システムから受け取ったリクエストに応じてユーザ・バリアブルズを前記不揮発性メモリの第3の記録領域に書き込むステップと、
前記プリブートが終了した後の前記オペレーティング・システムから前記第1の記録領域に対するアクセスを制限するステップと
を有する方法。
【請求項13】
プロセッサと、UEFIコードを格納した不揮発性メモリと、UEFI規格に適合するオペレーティング・システムを格納したディスク・ドライブとを有するコンピュータであって、前記不揮発性メモリが、
プリブートに不可欠な構成データを書き込む第1の記録領域と、
前記UEFI規格が定義するデータと、前記オペレーティング・システムが作成したユーザ・データとを書き込む第2の記録領域と、
前記プリブートが終了した後の前記オペレーティング・システムから前記第1の記録領域に対する書き込みを制限する手段と
を有するコンピュータ。
【請求項14】
前記書き込みを制限する手段が、前記不揮発性メモリのインターフェース・コントローラを含む請求項13に記載のコンピュータ。
【請求項15】
前記第2の記録領域が、前記UEFI規格が定義するデータの記録領域と前記ユーザ・データの記録領域に分割されている請求項13に記載のコンピュータ。
【請求項16】
プロセッサと、UEFI規格に適合するオペレーティング・システムを格納したディスク・ドライブとを有するコンピュータであって、
プリブートに不可欠な構成データを格納する第1の記録領域と、前記UEFI規格が定義するデータを格納する第2の記録領域とを含む第1の不揮発性メモリと、
前記オペレーティング・システムが作成したユーザ・データを書き込む第2の不揮発性メモリと、
前記プリブートが終了した後の前記オペレーティング・システムから前記第1の記録領域に対する書き込みを制限する手段と
を有するコンピュータ。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、コンピュータの動作不良を防止する技術に関し、さらには、UEFI(Unified Extensible Firmware Interface)規格に適合するコンピュータのブートの信頼性を高める技術に関する。
【背景技術】
【0002】
コンピュータのファームウェアは、ハードウェアとオペレーティング・システム(OS)、デバイス・ドライバまたはアプリケーションなどの上位のプログラムとの間のインターフェースを提供するコードである。ファームウェアは、周辺デバイスを専用に制御するデバイス・ファームウェアとシステム全体の動作にかかわるシステム・ファームウェア(プラットフォーム・ファームウェアともいう。)に分けることができる。
【0003】
システム・ファームウェアは通常マザーボードに取り付けられた不揮発性メモリ(NVRAM)に格納されている。BIOSはこれまで多くのコンピュータ・システムに実装されてきたシステム・ファームウェアで、コンピュータの電源が起動してからOSがロードを開始するまでの間にPOST(Power On Self Test)およびパスワード処理をしたり、ハードウェアにアクセスする為のサービスを提供したりする。
【0004】
しかしBIOSは、近年の進化したハードウェアに対する対応が困難になってきたため、非特許文献1に示すように、UEFIフォーラムが、従来のBIOSであるレガシーBIOSに代わる新しいシステム・ファームウェアとしてUEFI規格を策定した。UEFIファームウェアは、レガシーBIOSをエミュレートして互換性を保つための仕組みを取り入れており、ハードウェアとソフトウェアは過去数年かけてレガシーBIOSからUEFIファームウェアに対応できるように段階的に発展してきた。2011年4月には非特許文献1に示す最新バージョンのUEFI規格が策定され、ハードウェアもほぼ対応できるようになってきたこともあって現在のシステムはUEFIファームウェアへの完全移行段階に入ってきている。
【0005】
UEFIファームウェアを実装するシステムではUEFIネイティブ・モードで動作するUEFI対応のOSと、レガシーBIOS互換モードで動作するUEFI非対応のOSのいずれも動作することができる。Windows(登録商標)7はUEFIネイティブ・モードに対応しているが、UEFIファームウェアの高速ブート、セキュア・ブートなどの機能を利用することはできない。Windows(登録商標)8ではUEFIファームウェアに完全移行してその機能を完全に利用できるようになっている。
【0006】
非特許文献1のUEFI仕様には、7.2にバリアブル・サービス(Variable Services)を規定している。バリアブル・サービスでは、不揮発性のメモリにUEFI仕様で定義した変数であるグローバル・バリアブルズ(GV:Global Variables)を格納することにしている。現在ほとんどのパーソナル・コンピュータ(PC)では、UEFIを格納する不揮発性メモリにGVを記録している。UEFI仕様では、ベンダーがUEFI仕様で定義されたGV用のユニークな識別子(VendorGuidおよびVariableName)を使って、当該不揮発性メモリに独自のGVを書き込んでもよいとしている。また、OSがUEFI仕様で定義したGVを書き換えることを許容している。特許文献1はUEFIファームウェアが使用する変数をプロテクトして不揮発性メモリに記憶する発明を記載している。
【先行技術文献】
【特許文献】
【0007】
【特許文献1】特開2010−73193号公報
【非特許文献】
【0008】
【非特許文献1】Unified Extensible Firmware Interface Specification Version 2.3.1 April 6,2011
【発明の概要】
【発明が解決しようとする課題】
【0009】
ところで、レガシーBIOSやUEFIファームウェアなどのシステム・ファームウェアは、ブートの際にデバイスの認識や初期化などの処理をするために、電源の起動直後にアクセスが可能な不揮発性メモリに書き込んだデータを参照する必要がある。以後このようなブートに不可欠なデータ(変数)を、本明細書においてコンフィグレーション・バリアブルズ(CV:Configuration Variables)ということにする。
【0010】
CVはプリブート段階でUEFIがデバイスに設定するデバイスの属性情報およびデバイスに設定するパラメータ、セット・アップ画面を呼び出してユーザが設定したデバイスの種類、デバイスの動作モード、およびデバイスの有効/無効などの設定情報、ブート・イメージが格納されているパーティションのパスやロードするOSの種類などの情報を含む。CVの多くは、従来、ボタン電池で電源をサポートしているCMOSに記録されていたが、近年はUEFIを格納するセキュアな不揮発性メモリにも書き込むようになってきた。
【0011】
また、OS、UEFIアプリケーション、およびOSアプリケーションはその実行に際して、自らをカスタマイズするための環境変数、デバッグ・ログ、またはエラー・ログのようなダンプ・ファイルをUEFIファームウェアの仕様上の制約を受けないで自由に不揮発性メモリに書き込むことができる。このようなOS、UEFIアプリケーション、およびOSアプリケーションが作成したデータを本明細書においてユーザ・バリアブルズ(UV:User Variables)ということにする。
【0012】
図9はシステム・ファームウェアが管理するデータの記録方法の変遷を説明する図である。
図9(A)はシステム・ファームウェアがレガシーBIOSのときに、BIOSコードをファームウェアROM501に格納し、CV、GVをボタン電池による電力のサポートがあるCMOS503、またはセキュアな不揮発性メモリに記録する様子を示している。レガシーBIOSには、UEFIのバリアブル・サービスに対応するサービスがないため、UVはHDDまたはSSDのような外部記憶装置505に記録している。
【0013】
図9(B)は、システム・ファームウェアがUEFIファームウェアのときに、レガシーBIOS互換モードで動作するUEFI非対応のレガシーOSが動作するときの様子を示している。ファームウェアROM501は、UEFIコードを格納するコード領域501aと変数を記録する変数領域501bを含み、コード領域501aにはUEFIコードを格納する。レガシーBIOS互換モードで動作するUEFI非対応のレガシーOSは、UEFI規格が提供するバリアブル・サービスを利用できないため変数領域501bには、UEFIファームウェアによってCV、GVが記録されるだけで、レガシーOSまたはOSアプリケーションが書き込んだUVは、HDDまたはSSDなどの外部記憶装置505に記録される。また、レガシーBIOS互換モードで動作するときは、CPUの動作モードが切り換わってUEFIアプリケーションは動作できなくなるため、UEFIアプリケーションが変数領域501bにUVを書き込むこともない。
【0014】
図9(C)はシステム・ファームウェアがUEFIファームウェアのときに、UEFIネイティブ・モードで動作するUEFI対応のOSが動作するときの様子を示している。UEFIネイティブ・モードで動作するOSは、UEFI規格が提供するバリアブル・サービスを利用できるため変数領域501cにはCV、GVと、UEFIアプリケーション、OS、OSアプリケーションが書き込んだ多量のUVを記録している。
【0015】
いずれのプログラムであっても、バリアブル・サービスを利用して変数領域501cにデータを書き込むためには、UEFIの関数であるSetVariable()を呼び出してパラメータを設定する必要がある。レガシーBIOS互換モードで動作するレガシーOSはバリアブル・サービスを利用することができなかったが、UEFI規格では変数領域501cの利用に制限を設けていないため、UEFIネイティブ・モードで動作するOSおよびOSアプリケーションは、バリアブル・サービスを利用して変数領域501cに自由に多量のUVを書き込むことができる。
【0016】
システム・ファームウェアの動作環境がレガシーBIOSからUEFIに完全に移行して変数領域501cがOSおよびOSアプリケーションに解放されたことに伴って、最近、ブートに関連するいくつかの問題が明らかになってきた。まず、UVを書き込むOSやOSアプリケーションが、SetVariable()に誤ってCVやGVの変数の名称(VariableName)や識別子(VendorGuid)を設定すると、CVやGVが書き換えられてしまうことがある。また、マルウェアによっても意図的にCVやGVが書き換えられたり消去されたりしてしまう危険性がある。CVはプリブートでハードウェアを構成するために不可欠なデータであり、さらにGVもプリブートに関連するデータを含むため、誤って書き換えられるとシステムをブートできなくなりユーザによる復旧作業が困難になる。
【0017】
ここでプリブートとは、システムがACPIに規定するパワー・オフ状態(S5ステート)またはハイバネーション状態(S4)のときに、電源が起動してからOSがロードを開始するまでの間に、プロセッサがシステム・ファームウェアを実行している動作環境でのシステム・ファームウェアの処理をいう。また本明細書でブートとは、電源が起動してからプリブートを経由してOSおよびOSアプリケーションのロードが完了した状態になるまでの処理をいうことにする。
【0018】
UEFI規格では、SetVariable()に設定するパラメータをハッシュして書き込み保護をする認証サービス(Variable Authentication)を提供する。認証サービスを利用すればOSまたはOSアプリケーションによるCVへの上書きを防ぐことはできる。しかし、OSまたはUEFIアプリケーションがコード領域501cにアクセスしているときに電源の瞬断などによって電気的なノイズが発生すると、CVやGVが毀損する可能性がある。
【0019】
またUEFI規格では、OSやOSアプリケーションがGVを書き換えることを許容するため、認証サービスではGVを保護することはできない。GVは、Boot####、BootOrder、Drive####、DriveOrder、Key####などの名称の起動ディスクの種類や優先順位などに関するブート関連データや、Conin、Conoutといった入出力コンソールまでのパスに関するデータを含みUEFI規格で定義している。GVのブート関連データがOSやOSアプリケーションで誤って書き換えられたり、電源ノイズで毀損したりするとブートできなくなることも予想される。
【0020】
さらに、変数領域501cの容量は一例で16MBといったように、HDDやSSDに比べて遙かに小さいため、多量のUVが書き込まれて変数領域501cが容量不足になると、プリブート中にUEFIファームウェアがCVやGVを更新できないため結果としてブート不能に陥ることも予想される。さらに、CVやGVが予期しない原因でOSやOSアプリケーションによって消去されてしまうことも予想される。その場合少なくとも、CVやGVをデフォルト値に戻したり、起動ディスクを変更したりするためのセット・アップ画面まではプリブートが到達できるようにしておくことが望ましい。
【0021】
本発明は、システム・ファームウェアに関する上述の諸問題を解決することを目的とする。そこで本発明の具体的な目的は、システム・ファームウェアが管理するデータに起因するシステムの動作不良を防止する方法を提供することにある。さらに本発明の目的は、UEFIネイティブ・モードで動作するOSの動作環境下で生ずるシステムの動作不良を防止する方法を提供することにある。さらに本発明の目的は、OSおよびマルウェアによるCVの書き換えを防止する方法を提供することにある。さらに本発明の目的は、GVがOSおよびマルウェアによって書き換えられたときに修復する方法を提供することにある。さらに本発明の目的は、そのような方法を実現するコンピュータ・プログラムおよびコンピュータを提供することにある。
【課題を解決するための手段】
【0022】
本発明は、システム・ファームウェアが管理するデータに起因するシステムの動作不良を防止する方法を提供する。システム・ファームウェアが管理するデータは、プリブートに不可欠な構成データ、システム・ファームウェアが定義しOSによる書き換えが可能な公開データおよびOSが作成したユーザ・データで構成されている。システム・ファームウェアは、不揮発性メモリの第1の変数領域に構成データを記録し、第2の変数領域に公開データおよびユーザ・データを記録する。システム・ファームウェアは、プリブートを終了した後の第1の変数領域に対する書き込みを制限する。
【0023】
このような構成によれば、第2の変数領域にユーザ・データを書き込む際にOSが誤って、あるいはマルウェアが故意に第1の変数領域の構成データを書き換える危険性を排除してプリブートの信頼性を向上させることができる。第1の変数領域に対する書き込み制限は、不揮発性メモリのインターフェース・コントローラに対してハードウェア的にライト・ロックをかけて行うことができる。ライト・ロックを施すことで、システム・ファームウェアまたはOSが不揮発性メモリにアクセスする際に、電源が不安定になってノイズが発生しても第1の変数領域の構成データが書き換えてしまう危険性を排除することができる。
【0024】
第1の変数領域に対する書き込みの制限は、第1の変数領域の構成データを更新するためのOSからのリクエストをシステム・ファームウェアが無効にすることでソフトウェア的に行うこともできる。システム・ファームウェアは、プリブートの間に第2の変数領域の残容量を確認し、残容量が所定値未満になったときに第2の変数領域をクリーン・アップすることを示す画面を表示し、クリーン・アップの指示を受け取ったときにユーザ・データを消去することができる。その結果、第2の変数領域がユーザ・データで溢れて、公開データの書き込みまたは更新ができなくなる自体を防ぐことができる。
【0025】
構成データと公開データのデフォルト値を第3の変数領域に格納して、プリブートの間に構成データおよび公開データとデフォルト値を比較し、いずれかの構成データまたは公開データが消去されたと判断したときにデフォルト値を第1の変数領域または第2の変数領域に書き込むことができる。デフォルト値の書き込みは、消去されたデータだけについて行ってもよいし、フラッシュ・メモリの消去ブロックの単位に対して行ってもよい。
【0026】
システム・ファームウェアがUEFI規格に適合する場合は、公開データをUEFI規格が定義するグローバル・バリアブルズとすることができる。このときUEFIは、プリブートの間に第2の変数領域に記録されたグローバル・バリアブルズのなかでブートに関するパラメータに対する改変の有無を判断し、パラメータが改変されたと判断したときにデフォルト値を書き込むことができる。
【0027】
UEFI規格では、OSおよびOSアプリケーションからのグローバル・バリアブルズに対する書き換えを許容するため、構成データのようにライト・プロテクトすることはできないが、ブートに関連するグローバル・バリアブルズのパラメータをデフォルト値に維持しておけば、セット・アップ画面に到達するまでプリブートを進めることができる。セット・アップ画面を表示できれば、起動ディスクを変更したりパラメータをデフォルト値に戻したりできるためユーザが動作不良を回復させることができる。
【0028】
ブートに関するグローバル・バリアブルズは、Boot####、BootOrder、Drive####、DriveOrder、およびKey####とすることができる。このときのパラメータは、ロード・オプション(Load options)とすることができる。OSは、第2の変数領域に自由にユーザ・データを書き込めるUEFIネイティブ・モードで動作することができる。第1の変数領域と第2の変数領域は、システム・ファームウェアを格納する不揮発性メモリに設けることができる。このとき、第2の変数領域は、公開データを記録する領域とユーザ・データを記録する領域にさらに分けることができる。また、公開データを記録する領域とユーザ・データを記録する領域は、構成データを記録する領域とは別のインターフェース・コントローラに接続された不揮発性メモリに設けることができる。
【発明の効果】
【0029】
本発明により、システム・ファームウェアが管理するデータに起因するシステムの動作不良を防止する方法を提供することができた。さらに本発明により、UEFIネイティブ・モードで動作するOSの動作環境下で生ずるシステムの動作不良を防止する方法を提供することができた。さらに本発明により、OSおよびマルウェアによるCVの書き換えを防止する方法を提供することができた。さらに本発明により、GVがOSおよびマルウェアによって書き換えられたときに修復する方法を提供することができた。さらに本発明により、そのような方法を実現するコンピュータ・プログラムおよびコンピュータを提供することができた。
【図面の簡単な説明】
【0030】
【
図1】PC10の主要なハードウェアの構成を示す概略の機能ブロック図である。
【
図2】ファームウェアROM100のデータ構造の一例を示す図である。
【
図3】PC10が実装するソフトウェアの実行状態における階層構造を示す図である。
【
図4】UEFIファームウェア150が変数領域に対するアクセスを制御する手順を示すフローチャートである。
【
図5】変数制御コード150eによる変数領域105、107に対するアクセスを制御する手順を示すフローチャートである。
【
図6】ファームウェアROM100が変数を格納する様子を示す図である。
【
図7】ファームウェアROM100と他の不揮発性メモリ400が変数を記録する様子を示す図である。
【
図8】ファームウェアROM100のUVとGVを記録する領域を区分した状態を示す図である。
【
図9】システム・ファームウェアが管理するデータの記録方法の変遷を説明する図である。
【発明を実施するための形態】
【0031】
[ハードウェアの概略構成]
図1は、ノートブック型またはデスクトップ型のPC10の主要なハードウェアの構成を示す機能ブロック図である。多くのハードウェアの構成は周知であるため、本発明の理解に必要な範囲で説明する。チップセット13はさまざまな規格のインターフェース機能を備えており、CPU11、システム・メモリ15、GPU17、HDD21、USBコネクタ23、有線または無線のLANに接続するためのネットワーク・モジュール25、およびキーボード29などが接続されている。GPU17にはLCD19が接続されている。チップセット13にはさらに、SPI(Serial Peripheral Interface)コントローラにはファームウェアROM100が接続されている。
【0032】
HDD21は起動ディスクで、PC10の、UEFI規格に対応するOSのブート・イメージを格納する。HDD21は、複数のパーティションにそれぞれUEFI非対応のOSも含めて異なるブート・イメージを格納するようにしてもよい。HDD21のブート・セクタは、OSのブート・イメージをロードするためのOSローダーを格納する。
【0033】
USBコネクタ23には、外付けのUSBメモリ、USB_CD、USB_FDD、USB_HDDなどのUSBデバイスを接続することができる。PC10は、USBコネクタ23に接続されたブート・イメージを格納するUSBデバイスからブートすることもできる。PC10は、PXE(Preboot eXecution Environment)などの機能により、ネットワーク・モジュール25を通じてOSのブート・イメージを受け取ってブートすることもできる。
【0034】
[ファームウェアROMのデータ構造]
図2は、ファームウェアROM100のデータ構造を示す図で、
図3はシステム・メモリ15にロードされて実行状態にあるソフトウェアの階層構造を示す図である。ファームウェアROM100は、不揮発性で記憶内容の電気的な書き替えが可能なフラッシュ・メモリで、一例としてコード領域101、デフォルト領域103、変数領域105、107の4ブロックに区分している。
【0035】
本実施の形態では、コード領域101、デフォルト領域103、および変数領域105には、チップセット13のSPIコントローラにおいてライト・ロックが可能な記録領域を割り当てている。ライト・ロックが実行された記録領域に対しては、チップセット13がリセットされるまで書き込みができない。ただし、変数領域107はUEFI規格でOS167またはOSアプリケーション169による書き換えを保証しているGVを記録するためにライト・ロックはできない。
【0036】
コード領域101はUEFIファームウェア150およびUEFIアプリケーション165を格納し、デフォルト領域103はGVとCVのデフォルト値を格納し、変数領域105は最新のCVを記録し、変数領域107はUVと最新のGVを記録する。デフォルト領域103が格納するGVとCVのデフォルト値は、PC10の出荷前またはUEFI150の更新時に書き込まれる。
【0037】
UEFI150は、システムの動作環境の変化に応じてCVを更新する。UEFI規格では、GVをUEFIアプリケーション165、OS167、OSアプリケーション169にGVを参照または更新できるように公開することを規定している。したがって、変数領域105、107が記録するGVおよびCVは当初はデフォルト値であるが、PC10がブートを繰り返す間に書き換えられたり追加されたりする。UEFI150以外のソフトウェアによってCVが意図的にまたは誤って書き換えられると、システムは次回のブートを正常に行うことができなくなる可能性がある。
【0038】
UEFIファームウェア150は、初期化コード150a、ランタイム・サービス150b、ブート・マネージャ150c、セット・アップ・コード150d、変数制御コード150e、レガシーBIOS互換サービス150f、およびUEFIドライバ150gを含む。UEFI150は、書き換えに伴うリスクを軽減するためにブート・ブロック方式を採用しており、初期化コード150aを格納する領域をブート・ブロックに設定している。ブート・ブロックに格納されたコードはTPM(Trusted Platform Module)の仕様書に規定するCRTM(Core Root Of Trust Measurement)として扱われ特別な権限がないと書き換えができないようになっている。
【0039】
CRTMは、プラットフォームの初期化コードの中で完全性が保証されている部分として構成され、プラットフォームのリセット時には必ず最初に実行されなければならない。CRTMは、PC10がACPIに規定するハイバネーション状態(S4ステート)またはパワー・オフ状態(S5ステート)からパワー・オン状態(S0ステート)に遷移するための動作プロセスであるいわゆるコールド・ブートのときに必ず最初に実行される。
【0040】
初期化コード150aは、PC10がコールド・ブートをする際に、システム・メモリ15にUEFIファームウェア150をロードして実行を開始するために必要なCPU11、システム・メモリ15およびその他の基本的なデバイスの検出、検査および初期化を必要な範囲で行う。初期化コード150aはまた、CPU11がリセットしてから、UEFI_OSローダー163に制御が移行するまでの期間にチップセット13のコントローラや周辺デバイスなどの所定のデバイスを初期化して使用できる状態にする。初期化コード150aは、コード領域101が格納する他のコードの一貫性または完全性を検査して改竄を発見した場合はブートを停止する。
【0041】
ランタイム・サービス150bは、本実施の形態に関連するバリアブル・サービス、時刻情報のサービス、および仮想メモリ・サービスなどを提供する。ブート・マネージャ150cは、ブート処理およびパスワード認証処理などを行う。ブート・マネージャ150cは、GVを参照してUEFIアプリケーション165、UEFIドライバ150gおよびUEFI_OSローダー163(レガシーOS173をブートするときはレガシーBIOS_OSローダー171)をシステム・メモリ15にロードする。ブート・マネージャ150cは、プリブートが終了してUEFIファームウェア150からOS167に制御が移る直前に、UEFI_OSローダー163をシステム・メモリ15に読み出して完全性の検証をする。UEFI_OSローダー163には、それらを作成した作成者が計算したハッシュ値を秘密鍵で暗号化した電子署名が付されている。
【0042】
ブート・マネージャ150cは、UEFI_OSローダー163のコードから計算したハッシュ値と、署名データ・ベースから取得した公開鍵で復号して得た電子署名のハッシュ値を比較して、一致していれば完全性が維持されていると判断してUEFI_OSローダー163の実行を許可する。セット・アップ・コード150dは、プリブートの段階でキーボード29の所定のファンクション・キーが押下されたたときに、LCD19にセット・アップ画面を表示する。ユーザはセット・アップ画面を通じて、起動ディスクの優先順位の決定、起動方法の設定、使用デバイスの設定、パスワードの設定およびパワー・マネジメントの設定などをすることができる。
【0043】
セット・アップ・コード150dはセット・アップ画面を通じて入力された設定情報を変数領域105、107およびその他の記憶領域に書き込む。また一方で、セット・アップ・コード150dは、変数制御コード150eから呼び出されたときにLCD19に変数領域107をクリーン・アップするか否かをユーザが判断するためのクリーン・アップ画面を表示する。セット・アップ・コード150dは、変数領域107に書き込まれたUVをユーザの指示でクリーン・アップするための処理をする。
【0044】
セット・アップ・コード150dは、変数制御コード150eがブートに関するGVのパラメータの改変を発見したときに、変数制御コード150eの指示でそれらをデフォルト値に戻す処理をする。変数制御コード150eは、
図4、
図5の手順で説明するように変数領域105、107にCV,GV、UVを書き込む際の処理をする。レガシーBIOS互換サービス150fは、UEFI非対応のレガシーOS173に対するレガシーBIOS互換のインターフェースを提供する。レガシーOS173が、レガシーBIOS互換のインターフェースを利用するときは、INT**の割り込みルーチンを呼び出すが、そこにはバリアブル・サービスに関する割り込みルーチンを含まないため、レガシーOS173はバリアブル・サービスを利用することはできない。したがって、レガシーOS173は、変数領域107にUVを書き込むことはできない。
【0045】
[変数領域の制御手順]
図4、
図5は、UEFIファームウェア150が変数領域105、107に対するアクセスを制御する手順を示すフローチャートである。ブロック211で、PC10の電源が起動してシステムがコールド・ブートを開始する。このとき
図6に示すように、変数領域105にはCVが記録され、変数領域107にはGVとUVが書き込みの順番に応じて混合した状態で記録されている。パワー・オン・リセットしたチップセット13は、ブロック213でSPIコントローラに設定していたファームウェアROM100のコード領域101、デフォルト領域103および変数領域105に対するライト・ロック機能を解除する。
【0046】
変数領域105のライト・ロックが解除されるため、UEFIファームウェア150はCVを追加したり更新したりしてプリブートを進めることができるようになる。つづいてブロック215で初期化コード150aがプリブートに必要なデバイスを初期化すると、UEFIファームウェア150、およびUEFIアプリケーション165がシステム・メモリ15にロードされる。初期化コード150aはつづいて変数領域105のCVを参照して、必要な範囲でその他のデバイスを初期化する。
【0047】
OS167はシステムの変更に応じて新たなGVを書き込む場合がある。またOS167やUEFIアプリケーション165は、新たなUVを変数領域107に書き込む場合がある。したがって、変数領域107の容量が不足すると、UEFIファームウェア150がプリブートのために必要なGVを更新することができなくなってブート不能に陥る場合がある。ブロック219で変数制御コード150eは、変数領域107の容量がたとえば90%といった満杯に近い状態かどうかを判断する。
【0048】
変数制御コード150eが変数領域107の残容量が不足していると判断したときは、ブロック221に移行する。ブロック221で変数制御コード150eは、セット・アップ・コード150dを通じてLCD19にクリーン・アップ画面を表示する。クリーン・アップ画面には、ファームウェアROM100が容量不足に陥っていること、この状態を継続するとブート不能になる可能性があること、すべてのUVを消去するための操作メニュー、UVを消去したときに生ずる問題、およびUVの消去に伴う問題の解決方法などを表示することができる。
【0049】
ブロック223でクリーン・アップ画面をみたユーザは、その時点でUVのバックアップデータをHDD21に保存してからUVのクリーン・アップをしてもよいし、次回以降のブートでクリーン・アップをしてもよい。このとき変数制御コード150eは、後にOS167、UEFIアプリケーション165、およびOSアプリケーション169がUVを取得できるようにするために、消去するUVをHDD21に記録してそのパスをOS167に渡すようにしてもよい。
【0050】
UEFI規格では、公開の必要なGVはライト・プロテクトをすることができないため、OS167およびOSアプリケーション169は誤ってGVを書き換える可能性がある。さらに、UVとGVは同じ変数領域107に記録するため、変数領域107に対するアクセスの際に電源の瞬断でノイズが発生すると変数領域107が記録しているGVが破損する可能性もある。
【0051】
ブロック225で、変数制御コード150eは、変数領域107が記録するGVのなかでブートに関連するBoot####、BootOrder、Drive####、DriveOrder、Key####という名称のGVが指定するロード・オプション(Load options)というパラメータがデフォルト値から変更されていないかどうかを判断する。ロード・オプションは、起動ディスクおよびブート・イメージまでのパスを記述したリスト(FilePathList)を含みこの値が改変されるとブートができなくなる。
【0052】
変数制御コード150eは、デフォルト領域103および変数領域107にそれぞれ記録されたロード・オプションを比較して改変されていると判断したときはブロック227に移行する。ブロック227で変数制御コード150eは、セット・アップ・コード150dに指示して、ブートに関連するすべてのGVのロード・オプションまたは改変されているGVのロード・オプションをデフォルト領域103に記録していたデフォルト値で書き換える。
【0053】
このときセット・アップ・コード150dは、セット・アップ画面においてF9キーに割り当てたSetup DefaultsとF10キーに割り当てたSave & Exitの機能を利用することができる。前回のブートにおいて、ブートに関連するGVが書き換えられても今回のプリブートの間にブートに関連するGVのロード・オプションを必要に応じて修正することで、少なくともセット・アップ画面を表示させることができるようになる。GVの改変によってブートに問題が生じても、セット・アップ画面を表示できればユーザが問題を回復する可能性は高まる。
【0054】
何らかの原因でCV、GVが消去された場合、GetVariable()で参照したときにデータ不存在を示すエラーが発生する。ブロック229で変数制御コード150eは、変数領域105、107に記録していたCV、GVがすべて存在するかどうかを確認する。変数制御コード150eは、デフォルト領域103にあるCV、GVが変数領域105、107に記録されたCV、GVに不存在と判断したときは、ブロック231で変数領域105、107に消去されたCV、GVのデフォルト値を書き込む。
【0055】
ブロック233は、UEFIファームウェア150またはUEFIアプリケーション165が、プリブートの開始から終了までの間に、変数領域105、107に対してCV、GV、UVの書き込みをする場合があることを示している。ブロック235で変数制御コード150eは、コード領域101、デフォルト領域103、および変数領域105をライト・ロックするためにチップセット13のSPIコントローラを設定する。CVはハードウェア的にライト・ロックした変数領域105に格納するため、UEFIアプリケーション165、OS167、またはOSアプリケーション169によって改変されることも、変数領域107に対するアクセスの際に発生する電源のノイズの影響を受けることもない。
【0056】
さらに、変数制御コード150eは、それ以降において、UEFIアプリケーション165、OS167またはOSアプリケーション169からのCVを書き込むための関数であるSetVariable()の呼び出しに対し、エラーで応答することによりソフトウェア的なライト・ロックをする。ソフトウェア的なライト・ロックは、ハードウェア的なライト・ロックとともに、またはハードウェア的なライト・ロックに代えて実行することができる。ソフトウェア的なライト・ロックによっても、CVの改変と電源ノイズの影響を防ぐことができる。なお、ハードウェア的なライト・ロックに代えてソフトウェア的なライト・ロックだけを採用する場合は、プリブートの完了後においてもUEFIファームウェア150にはCVの書き換えを許可することもできる。変数領域105に対する書き込み保護の処理につづいてブロック236でプリブートが終了する。
【0057】
ブロック237で、ブート・マネージャ150cがHDD21の所定のセクタからUEFI_OSローダー163をロードすると、OS167、およびOSアプリケーション169がロードされてPC10はパワー・オン状態に移行し、システムはUEFIネイティブ・モードで動作する。UEFIアプリケーション165、OS167、およびOSアプリケーション169は、UEFIファームウェア150に自由にUVの書き込みの要求をすることができる。
【0058】
ブロック239は、UEFIアプリケーション165、OS167またはOSアプリケーション169が必要に応じて変数領域107にGV、UVの書き込みを行うことを示している。変数領域105はハードウェア・ロックおよびソフトウェ・ロックまたはいずれが行われているため、OS167およびOSアプリケーション169は、GV、UVの書き込みの際に誤ってCVを書き換えることがない。また、GV、UVの書き込みの際に電源の瞬断でノイズが発生しても変数領域105は変数領域107からハードウェア・ロックおよびソフトウェア・ロックで分割されているため影響を受けない。
【0059】
図4に示した手順は本発明を説明するための例示でありすべてが本発明の必須の手順ではない。本発明の必須の手順は特許請求の範囲に記載するとおりである。また、各ブロックの順番も、
図4に示した順番に限定するものではない。たとえば、ブロック219、225、229の手順および関連する手順とともに入れ替えることができる。
【0060】
図5は、変数制御コード150eが変数領域105、107にCV、GVまたはUVを書き込むためのリクエストを受け取ったときの処理をする手順を説明する図である。ブロック301では、
図4のブロック233、239のいずれかでUEFIアプリケーション165、OS167またはOSアプリケーション169がSetVariable()を呼び出して、CV、GV、UVのいずれかを書き込むためのリクエストを発行する。リクエストを受け取った変数制御コード150eはブロック303で、現在プリブートが終了しているか否かを判断する。プロブートが終了しているときはブロック305に移行し、プリブート中のときはブロック309に移行する。
【0061】
ブロック309で変数制御コード150eは、変数の種類がいずれであってもランタイム・サービス150bに書き込みのリクエストを渡す。ランタイム・サービスはSetVariable()で指定された変数のうち、CVは変数領域105に書き込み、GV、UVは変数領域107に書き込む。ブロック305で変数制御コード150eは、SetVariable()に設定されたパラメータのなかで、変数名称(VariableName)およびベンダー識別子(VendorGuid)を参照して、あらかじめ保有しているリストと比較し書き込む変数の種類を判断する。
【0062】
変数がUVまたはGVのときは、変数制御コード150eは、ランタイム・サービスにリクエストを渡す。変数がCVのときは、変数制御コード150eは、ソフトウェア・ロック機能により当該リクエストを無効にする。また、チップセット13をハードウェア的にロックしている場合は、たとえランタイム・サービス150bがリクエストを受け取っても変数領域105にアクセスできないためCVを書き込むことができない。
【0063】
図7、
図8は、変数領域105、107の他の構成方法を説明する図である。
図7の構成が
図6の構成と異なる点は、
図7(A)に示すようにファームウェアROM100の変数領域107にGVだけを記録して、
図7(B)に示すようにUVをインターフェースの異なる別の不揮発性メモリ400に記録するようにした点だけである。こうすることで、変数領域107はUVでオーバーフローする恐れがなくなり、かつ、不揮発性メモリ400にアクセスする際に発生する電源の瞬断でCV、GVが破損する危険性を除去することができる。なお、この場合でも変数領域105はハードウェア・ロックおよびソフトウェア・ロックまたはいずれかをしておく。
【0064】
図8の構成が
図6の構成と異なる点は、ファームウェアROM100に変数領域109を追加した点だけである。
図8の構成では、変数領域107にはGVだけを記録し、変数領域109にはUVだけを記録する。変数領域105にはライト・プロテクトをするが、変数領域107、109にはライト・プロテクトをしない。この場合も
図7の構成と同様に変数領域107のオーバーフローの問題と電源の瞬断の問題を解決することができる。
【0065】
これまで本発明について図面に示した特定の実施の形態をもって説明してきたが、本発明は図面に示した実施の形態に限定されるものではなく、本発明の効果を奏する限り、これまで知られたいかなる構成であっても採用することができることはいうまでもないことである。
【符号の説明】
【0066】
10 PC
100 ファームウェアROM
101 コード領域
103 デフォルト領域
105 CVを記録する変数領域
107 GV、UVを記録する変数領域
109 UVを記録する変数領域
150 UEFIファームウェア
400 ファームウェアROMとは異なる不揮発性メモリ