●BIOSからEFIへ

デモされたIA-32用のEFI

　Extensible Firmware Interface(EFI)とは、BIOSに代わる新しいPCシステムのファームウェアである。すでにItanium搭載のIA-64システムでは、EFIが標準のファームウェアとなっているが、IA-32を使うPC(AT互換システム)では、まだ、BIOSが搭載されている。

　BIOSは、IBM PCが登場したときに、システムの起動や基本的な入出力などをDOSなどに対して提供するために作られたもので、いまとなっては最後のレガシー機能でもある。

　EFIは、すでにIA-32用に定義され、利用可能な状態になった。しかし、現在のほとんどのOSは、BIOSからのブートを前提に作られており、いますぐEFIを搭載しても何もメリットのない状態である。MicrosoftのLonghornは、EFIからの起動をサポートしており、Longhorn登場以降は、EFI搭載のメリットが出てくる。つまり2006～2007年には、EFIを搭載したシステムが普及し始めると予想できる。

　ここでは、IDFのセッションの内容などから、EFIやその移行スケジュールなどについて見ていくことにしよう。

●IntelのEFI移行スケジュール

IDFのセッションで示されたEFI移行スケジュール。2005年に移行が開始され、2006年に登場するチップセットでEFIが完全にサポートされる

　EFIへの移行は2世代の製品を経て行なわれる予定。ただし、EFIへ移行したとしても、これに対応したOSがなければ無意味である。MicrosoftのOSでは、LonghornがEFI対応となるため、これをターゲットに計画が進められている。

　今回のセッションでは、EFIへの移行スケジュールも示されたが、このスケジュールは春のIDFからまったく変わっていない。

　このスケジュールによれば、具体的な移行は来年から開始される。Intelのチップセットやマザーボードは、2005年の出荷からEFI対応が始まり、次の世代の製品となる2006年のチップセット、マザーボードでは、完全にEFI対応となる。これで、2006年にLonghornが登場すれば、EFIからブートできるようになるわけだ。

　チップセットがEFI対応へ移行するため、サードパーティのマザーボードなども似たようなスケジュールとなる予定だが、EFIのメリットが出るのはLonghorn以降であり、Microsoftの都合でスタートが遅れることになるかもしれない。

　モバイル用については、2005年からIntelが提供するリファレンスデザインボードがEFI対応となる。つまり、2005年には、ノートブックPCもEFI対応の準備が整うことになる。

●EFIの構成

　EFIは、BIOSの問題点を克服するために開発されたもので、Itanium、IA-32およびPXA(XScale)と、すべてのIntel CPUのファームウェアとなることが想定されている。

　もともとBIOSは、システムの初期化と自己診断、IPL機能と基本入出力ルーチンから構成されていた。しかし、PCの機能の拡張とともにBIOSも拡張されてきた。しかし、BIOS自体は、ROM上に完結したプログラムとして作られているため、容量面で拡張が困難であったり、機能の追加のためにBIOS全体を書き換える必要がある、などの問題がある。

　たとえば、レガシーであるPS/2インターフェースを廃止するには、USBキーボードのサポートをBIOS内で行なう必要があり、そのためには、USB関連の機能をBIOS内に取り込む必要があった。

　しかも、BIOSは、リアルモードで動作しており、利用メモリの場所やサイズに制限がある。もう1つ、BIOSは、DOSなどのリアルモードプログラムから呼び出されることを前提にしており、その互換性のために、エントリポイントレベルでの互換性を保たねばならない。実際には、エントリポイントでのスタックの残りサイズまでを保証するために、その内部はかなり複雑なものとなっている。

　つまり、BIOSは、増築を重ねた温泉旅館のような複雑な構造になっており、その拡張性などについても限界が来ている。これを解決するために作られたのがEFIなのだ。

　EFIは、ファームウェアにデバイスドライバによる機能拡張を持たせ、Cなどの高級言語でのソフトウェア開発を可能にするために開発された。また、テキストレベルの簡単なユーザーインターフェースを持ち、OSを起動せずとも、簡単な処理が可能なモニタなどの利用を可能にする。

　また、EFIは、LaGrandeなどとも関係する。LaGrandeでシステムを保護する場合、OSのブート前にシステム内部の情報を読み出すようなモジュールを組み込まれてしまったり、DOSのようなセキュリティ機能のないOSを起動され、情報を読み出されてしまうおそれがある。こうした事態を防ぐために、EFIでは自身が起動するときに、セキュリティのチェックを行なう。

　また、EFIは、OSのブート後も、OS側に対してRuntimeサポートを提供する。これによってOS側のハードウェア依存度を下げることが可能となる。たとえば、ハイバネーションのサポートやリアルタイムクロック、NVRAM(システム設定用の不揮発性メモリ)のアクセスなどの機能がある。ただし、EFIは、完全なランタイムサポートを行なうわけではなく、パフォーマンスなどが重要な場合には、OSはハードウェアアクセスのためのドライバを持つ必要がある。

　EFIの構造で中心になるのは、デバイスドライバとその実行環境(DXE:Driver eXecution Environment)で、その下にハードウェアアクセスを提供するAPs(Architectual Protocols)がある。また、BIOSとの互換性を提供するCSM(Compatibility Support Module)も提供されDXE内で動作する。

【EFIの構造】EFIは、デバイスドライバを使うファームウェアで、OSのブートとランタイム機能を提供する。また、HDD上のパーティション(ESP:EFI System Partition)を扱うことも可能。OSローダーに対しては、Boot Serviceを、実行中のOSに対しては、Runtime ServiceをEFI APIを通して提供する	【DXE】EFIの中心になるのは、DXE(Driver eXecution Environmentと呼ばれる部分で、OSローダーに対してハードウェアアクセス機能などを提供する

【APs】DXEは、低レベルのハードウェアアクセスを行なうArchitecural Protocolモジュール(APs)の上にあり、デバイスドライバの実装を簡単に行えるようにしてある	【EFIの起動シーケンス】最初にPEIのセキュリティチェックが行なわれ、その後PEIでシステムを初期化、DXEが起動する。その後ブートマネージャが動き出し、ユーザーの指定などによりOSローダーが選択されOSの起動が行なわれる

　初期起動時には、EFIは、セキュリティチェック後にPEI(Pre EFI Initialization)と呼ばれる状態に入る。ここで、CPUやチップセット、マザーボード上の各種ハードウェアの初期化などを行なう。各ハードウェア用の初期化ルーチンなどはPEIモジュール(PEIM)と呼ばれ、最後にDXEを起動するPEIモジュールが呼び出され、EFIが動作しはじめる。

　EFIは、EFI byte code Engine(EBC Engine)と呼ばれる仮想マシンインタプリタを持っている。これは、IA-32/64、PXAでハードウェアを共通化できるように拡張ボード上のROMに格納するコードを機種依存させないためと、ブートコード(Boot Scriptと呼ばれる)などのセキュリティを確保するためである。インタプリタであれば、ハードウェアアクセスなどを実行前にチェックすることが可能で、不正な動作を防ぐことが可能だ。ただし、ドライバに関しては、EBCによる記述だけでなく、ネイティブコードによる作成も可能になっている。前者は、互換性を優先する場合、後者は、処理効率やスピードを優先する場合に利用する。どちらもプログラミングは、Cで行ない、EBCの場合には、専用のコンパイラを使用する。

　また、EFIは、外部記憶を扱うことが可能で、起動ディスク上にEFI用のパーティション(ESP:EFI System Partition)を持つことができる。ディスクフォーマットとしては、FAT32が採用されている。

　ビデオカードなどは、マザーボードとは別になっていることが多く、また、ユーザーがこれを交換する可能性もある。その他のデバイスについても追加や除去が行なわれる可能性があり、こうしたシステムの変更に対して、拡張ボード上のROMだけでなく、外部記憶装置にデバイスドライバを保存することで対応が可能になるわけだ。

　また、OSをメモリに読み込み、起動するOSローダー(いわゆるブートレコードに記録されているIPLプログラム)についても、EFIパーティションに保存することが可能だ。

　さらにEFIでは、適切なフォントを用意することで、UTF-16による2バイトコード文字の出力も可能になっている。これにより、ロード中であっても、ローカライズされた言語でのエラー表示などが可能になる。また、EFI内部でHTMLレンダリングといった機能を動作させることも不可能ではない。EFIのインプリメントを提供しているinsydeでは、今回のIDFでHTMLを使ったブートマネージャのユーザーインターフェースを提案していた。HTMLを使うことで、グラフィカルな画面の表示が簡単に行なえるようになるわけだ。

●32bit OSとEFI

　Microsoftは、LonghornでEFIをサポートする。ただし、従来のBIOSからの起動についてもサポートされるため、システムにEFIが実装されていることは必須条件ではない。来年に登場するβ1版からEFI対応が実装される予定だという。

　Linuxについては、すでにItaniumサポートが行なわれているため、EFIに対応したブートローダーであるELILO(EFI LInux LOader)が開発されている。ELILOでは、EFIがデバイスドライバを持っているため、デバイス対応が柔軟になる。たとえば、USBメモリからの起動なども可能になるという。

　Longhornが登場していない現在、IA-32システムでは、EFIはまだ無用のものであるが、CSM(Compatibility Support Module)により、現行の非EFI対応OSを起動することは可能である。ただし、これには条件があって、ROMを持つ拡張ボードがEFI対応なのか、BIOS対応なのかの組合せにより、起動できるかどうかが違ってくる。資料によれば、ビデオ、ブートデバイス、その他の拡張ボードのROMがすべてBIOS用(つまり非EFI対応)の場合と、ビデオカードROMだけがEFI対応であるときのみ、非EFI対応のOSの起動が可能になる。逆にOSがEFI対応である場合には、EFI対応、BIOS対応の拡張ボードROMが混在しても起動は可能になっている。

　EFIマザーボード上での既存OSの利用には、こうした制限もあるため、EFIへの移行は、Longhorn登場後になるだろう(もちろん、Linuxの場合には先に移行することも可能だが)。その意味でEFIの普及は、Longhornの登場時期次第ということになる。

□IDF Fall 2004のホームページ(英文)
http://www.intel.com/idf/us/fall2004/systems/
□関連記事
【2003年9月19日】【元麻布】EFIフレームワークの導入で変わるBIOS
http://pc.watch.impress.co.jp/docs/2003/0919/hot280.htm

(2004年9月13日)

[Reported by 塩田紳二]