左側の図は、Intel社のサイトに掲載されているUEFIのイメージ図です。(http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-homepage-general-technology.html)。ただ、シンプル過ぎて、これだけではちょっと分かりにくいと思うので、右側には、もう少し情報を付与した簡略図を作図してみました。

『ん?』と疑問に思われる方も少なくないのではないかと思います。BIOSに代わる新しいPCのファームウェアがUEFIだと思っていたのに、こんな図を見かけたら、疑問に思う人がいても不思議はありません。
どうして、『むむむ』と思う状況が生まれるかというと、一般論的に語られるUEFIと、仕様定義上のUEFIの意味が違っているからなんです。そして、この辺りのお話は、UEFIの特徴を知るのに、良い材料になるので、今回は一般論的UEFIと仕様定義上のUEFIについて書きたいと思います。

 

図1 UEFIの構成イメージ
図1 UEFIの構成イメージ

一般論的なUEFI

『UEFIはBIOSに代わる新しいファームウェア』といった説明がされることが多いですよね。
そもそも、WindowsやLinuxといったOSを使うPC/AT互換機では、長い間、ファームウェアはBIOSでした。
BIOSは16bit時代からの遺物、リアルモードで動作するため制限も厳しく、OSを起動するまでの間、プラットフォームに対して、必要不可欠、最低限の機能しか提供できません。
PCのプラットフォームとは、そのPCが動作できるようになる基本的な設定や環境全般をさします。かつては、プラットフォームの低レベルでの処理を行うのがBIOSであり、OSをロードするのもBIOSの役割だった。
ところが、UEFIはBIOSとは事情が違います。リアルモードの呪縛から解放され、実現できることも多くなりました。実際、多機能化するわけですが、機能が増えるということは、それぞれの機能を分けえて考えるという視点が必要になります。

『今まで漠然とBIOS、あるいはファームウェアと呼ばんできたソフトウェアが多機能になり、それぞれの機能に名称がつきました』と言われても、世のなかのPCユーザーの大半は開発サイドの人間ではありません。一般ユーザー向けに、おのおのの機能を別個の名称で呼ぶような真似をすれば、ユーザーの多くは混乱するだけです。第一、プラットフォームに必要不可欠な設定をしたり、OSを起動する役割を担うソフトウェアが、ファームウェアであるという一般常識は変わりないのですから、OS起動前に動作するプログラムを、まとめてファームウェアと呼ぶのは誤りではありません。

『UEIFIをBIOSに代わるファームウェアだ』と説明する記事のなかに、上のような図が掲載されていたり、UEFIがファームウェアだという認識を持っていたのに、仕様定義上のUEFIを説明した記事を見つけたりすると、『あれれ~、UEFIはファームウェアじゃないの?』と疑問に思うのも、無理はないと思います。ファームウェア全体をさして、『UEFI/EFI』と呼ぶようになってしまったので、仕様定義上、厳密な意味での『UEFI/EFI』と、言葉がごっちゃで、混乱する、わかりにくいのだと思います。特定の役割を持つUEFIに対応することで、他の機能も付随してくるので、ファームウェア全体をさしても『UEFI/EFI』という名称が使われるようになったんだと思いますが。

それでは、仕様上のUEFIとは、いったいどんなものなので、どうしてファームウェアと区別されているのか見ていきたいと思います。

 

突然ですが、OSのお話です

さて、突然ですが、少しOSのお話をしたいと思います。もちろん、今日のテーマに必要になるからです。
『BIOS/UEFI(EFI)って何だ?』というテーマが終わったら、『OSって何だ?』というテーマについて書こうと思っているのですけれど、まだOSのことはぜんぜん、お話してないので、必要な部分だけピックアップして簡単に触れておこうと思います。

図2 PC構成イメージ図
図2 PC構成イメージ図

前回お話しましたが、リアルモードで動作するBIOSは16bit時代からの遺物で、プラットフォームに必要不可欠、言い換えれば必要最低限の機能しか提供できませんでした。そのため、OSを起動したあとは、OS上からデバイス制御を行うために、デバイスドライバというソフトウェアを組み込む必要があります。つまり、デバイスドライバはOS依存のものでした。

またOSにはデバイス制御のほかにも、アプリケーションの実行環境を整えるという重要な役割があります。詳しいことは、いずれ『OSって何んだ?』で書くことにしますが、アプリケーションはOS側が提供するプログラムを呼び出して動作していますし、マルチタスク環境を実現するために、OSは複数のアプリケーション問題なく動けるよう、メモリやデバイスドライバの管理したり、ファイルの管理をしたり、ファイルとアプリケーションの関連付けを行ったり、さまざまな役割を果たしています。

 

図2を一部目隠ししてみると・・・・・・UEFIってOSっ!?

さて、図2を確認して、OSの働きをざっと頭に入れた上で、一部を目隠した図3を見てください。

図3 一部目隠し
図3 一部目隠し

 

『プレブートアプリ』というのは、OSが起動する前、要はUEFI上で動作するアプリケーションです。
自作ユーザー向けのUEFI対応マザーボードのなかには、UEFIの画面上で出来るゲームソフト添付していた製品が販売されていたのを見かけたことがありますが、ゲームなんて、実にアプリケーションらしいアプリケーションですよね。プレブートアプリが開発できるメリットは、決してゲーム云々というお話ではないのですが、それについてはあとで触れることにして、お話の先を急ぎます。

図3を下から、『ハードウェア』、『ファームウェア』、『ドライバ』、『UEFI』、『(プレブート)アプリ』と、眺めていると、図2と同じ階層構造じゃんということに気付くと思います。そう気づくと、『UEFIの正体は、OSなんじゃね?』と思えてくるわけです。

一般的にはファームウェアと一括りにしている内部を、機能ごとにと分けて階層構造で表現する。図2ではOSとファームウェアは同じ役割のソフトウェアではないから別の階層に描かれていましたね。この場合も同じで、厳密な意味でのUEFIの機能と、ファームウェアの機能は同じ役割ではないから、別の階層に描かれているということなんです。
たとえば、ファームウェアはプラットフォームに対して必要不可欠な処理を行う。UEFIフォーラムや、事実上フォーラムを仕切っているIntelの定義上では、その部分だけを『プラットフォームファームウェア』(もしくはファームウェア)と表記し、OSをロードする役割を担っているのはUEFI/EFIだから、両者を別々に描いているわけです。

UEFIは、OSを起動するという機能のほかにも、デバイスドライバやアプリに対応するという機能も提供されています。少なくとも、後者の機能をクローズアップすると、OSと同じ機能をもっているんだとわかるわけですね。だから、UEFIに関する記事のなかには、『UEFIはミニOSといったほうが良い機能を提供し・・・・・・』、『UEFIはそれ自体が小型OSともいえる機能を備え・・・・・・』といった記述も散見されます。

 

定義上では、『プラットフォームファームウェアとOS繋ぐインターフェース』

仕様上の定義では、UEFIとは、『プラットフォームファームウェアとOSを繋ぐインターフェース』です。
OSを起動するという、一般的なOSにはない役割を担い、ユーザーがふつうのOSとして使うために開発されたソフトウェアでもなく、本人が『私、インターフェースって名前です』と言っているものを、OSとは言えません。そのため、『ミニOS』とか『小型OS』と明言するのも憚られる。だから、『ミニOSといったほうが良い機能』とか、『それ自体が小型OSとでもいうべき機能』とか、ビミョーな表現が使われることになるのでしょうね。

さて、インターフェースというのは、顔と顔を付き合わせる的な意味合いで、何かと何かを繋ぐものというイメージを持って貰えればいいと思います。たとえば、PCの操作画面は、ユーザーとPCを繋ぐ窓口だから『ユーザーインターフェース』と呼ばれるし、USBやSATAなどデバイスを接続する規格も、『インターフェース』と総称されます。
つまり、UEFIは、ハードウエア寄りのソフトウエア(プラットフォームフォームファクタ)とOSを繋ぐソフトウェアということになります。
では、どうして、UEFIは、OSを起動するだけではなく、ドライバを組み込んだり、対応アプリを開発できるミニOS的な機能を持つことになったのでしょう?

たとえば、BIOSはNTFSでフォーマットされたハードディスクのデータにアクセスすることはできません。でも、UEFIならファイルシステムドライバを組み込めるし、対応のアプリケーションも開発できるので、ハードディスクのデータにアクセスすることもできるようになります。
個人ユーザーレベルのお話だと、復旧用のディスクとか、CD-ROMとか、見たことがあるという方も多いと思うのですが、あれらのなかには、復旧作業用のOSと、復旧作業に必要なドライバやアプリケーションが入っている。だから、OSが起動しなくても、PCを操作し、復旧作業ができるのです。
もちろん、個人ユーザーなら、メディアを使った作業でも、大した問題ではないんですが、そもそもEFIが開発される発端になった経緯を鑑みると、どうしてUEFIがミニOS化したのか、理由が見えて来ると思います。

 

UEFIミニOS化のメリット

前回、EFIの開発が始まったのは、大規模サーバープラットフォーム向け64bitCPUが登場したことに端を発していると書きましたよね。
今は、遠隔地からネットワーク経由でサーバーを保守管理したり、トラブルに対応したりという状況が当たり前の時代です。
一分一秒でも早く復旧させなければならないというのに、OSは完全にダウン。そういう状況に対応できるソフトを使い、ネットワーク経由で、障害を特定しようとしたり、リカバリーしようとしたりしても、BIOSの起動処理の低速度っぷりや、低機能っぷりに足を引っ張られ、復旧作業は遅延してしまうなんて状況もありました。そのため、上位のOSの起動とは関係なく、パッパと起動してくれて、障害に対応できるドライバやアプリを開発できる環境があるに越したことないのです。BIOSではできなかったことを実現してくれるのが、UEFI/EFIの主要な役割の一つということですね。

 

長くなりましたので、今回はここまで。次回は、今回触れることができなかった目隠した部分のお話です。
OS起動のお話になりますので、BIOS時代からのMBR(マスターブートレコード)、2TiB(テビバイト)以上のディスク管理に関わるGPT(GUIDパーティションテーブル)などの項目が登場します。