Unified Extensible Firmware Interface

ソフトウェアスタックにおけるEFIの位置づけ

Unified Extensible Firmware Interface （ユニファイド・エクステンシブル・ファームウェア・インタフェース、UEFI）はオペレーティングシステム(OS)とプラットフォームファームウェアとの間のソフトウェアインタフェースを定義する仕様である。UEFIはすべてのIBM PC互換機に採用された歴史的に古いSystem BIOSインタフェースのよりセキュアな置き換えを意図している^[1]。遠隔診断やOSがロードされていない状態での修復なども可能とする^[2]。

UEFIの元となる EFI (Extensible Firmware Interface) 仕様は元々インテルとヒューレットパッカードによって開発された。2005年、EFI 1.10に基づいてUEFIへと発展した。UEFI仕様は業界団体Unified EFI Forumの下で開発されている。

UEFIは特定のプロセッサアーキテクチャに限定されるものではなく、古いSystem BIOS実装の上で、あるいはSystem BIOSの代替として動作可能である^[3]。そのため古いSystem BIOS実装の上で単にユーザインタフェースとして被せた構造の場合もある。書籍やウェブサイト上の「UEFI-BIOS」のBIOSは、固有名詞ではなく基本入出力システム(basic input output system)の意味で誤記ではない。UEFIを介するプラットフォームファームウェア設定を「BIOSセットアップ」と呼ぶのは一般用語であって誤用ではない。

歴史

そもそもEFIが開発された動機は、1990年代中盤のインテルとヒューレットパッカードによる初代Itanium機の開発初期にまでさかのぼる。PCのSystem BIOSの制限（16ビットプロセッサモード、1MBのアドレス空間、PC/ATハードウェアへの依存）によって、Itaniumをターゲットとした巨大なサーバプラットフォームには採用できないことが判明した^[4]。これらの課題に対しての最初の成果が、当初1998年に Intel Boot Initiativeと呼ばれ^[5]、後にEFIと名前を変えた^[6]^[7]。

EFI仕様1.02は2000年 12月12日にインテルによってリリースされた（最初に発行されたものはバージョン1.01であったが、法的な不備や商標などのミスによりすぐに取り下げられている）。

EFI仕様1.10は2002年 12月1日にインテルによってリリースされた。それにはバージョン1.02からいくつかの細かい機能強化とEFIドライバモデルが記載されていた。

2005年には、インテルは同仕様の普及を務めるべく設立された Unified EFI Forum へと、権利を移管した。以後は同フォーラムがEFI仕様の開発と普及につとめている。EFIはこれを反映して Unified EFI (UEFI) と名前を変え、多くのドキュメントが両方の用語を同じものとして使うようになった。元々のEFI仕様は依然としてインテルに所有権があり、EFIベースの製品へのライセンスもインテルが提供しているが、UEFI仕様は同フォーラムが所有している^[4]^[8]。

2007年 1月7日、UEFI仕様バージョン2.1がリリースされている。暗号化の改善、ネットワーク認証、ユーザインタフェースのアーキテクチャ（UEFI中にある対人インタフェース）が追加されている。なお、2014年6月現在の最新版は2013年7月の 2.4 である。

インテルによる開発から10年以上たった2011年、2TB以上の容量を持つハードディスクに対応するために、P67, H67, H61, Z68 チップセットを使用したマザーボードでUEFIの採用が本格化した^[9]。

詳細

ファイル:Efi flowchart extended.svg

EFIブートマネージャーとEFIデバイスドライバとの間の関連

EFI仕様によって定義されたインタフェースは、プラットフォーム情報などのデータテーブルを持っている。この情報やEFIの機能はブートローダーやOSが利用できる。UEFIファームウェアには以下のような技術的利点がある^[10]。

2TiBを超える大きなディスクからブート可能^[11]。
より高速なブート
CPUに依存しないアーキテクチャ
CPUに依存しないドライバ
ネットワークも使用可能な柔軟なプレOS環境
モジュール化設計

従来の System BIOS に対しての強化点としてはACPIやSMBIOSはすでにEFIの中にあるので、16ビットで動作するインタフェースに拠らなくても利用できる。

ディスクサポート

マスターブートレコード (MBR) など標準的なPCのディスクパーティションの処理に加えて、EFIではGUIDパーティションテーブル (GPT) をサポートしている。これによりPCでのディスクパーティションの容量の限界と領域の数の制限は拡張され、時同じくして開発された2TB以上の世代のシリアルATA内部ハードディスクからの起動がサポートされた^[12]。GPTでのディスクとパーティションの最大サイズは9.4ZB（2⁷³バイト）である^[12]^[13]。EFI仕様はファイルシステムそのものには言及していない。たいていのEFIの実装ではファイルシステムとしてFAT32をサポートしている。Windowsで2.2TB以上のディスクからブートできるのは、64ビット版のWindows Vista、Windows 7、Windows 8、Windows Server 2008およびそれ以降と32ビット版のWindows 8、Itanium版のWindows Server 2003とWindows XPである。

プロセッササポート

バージョン2.3では、Itanium、x86、x86_64、ARMアーキテクチャをサポートしている（バインディングが存在する）。

System BIOSは16ビットの Intel 8088 を採用した IBM 5150 の設計に基づいているため、16ビット・プロセッサモードと1MBのアドレス空間という制限があった^[4]^[14]。一方、UEFIのプロセッサモードは32ビット（x86-32、ARM）または64ビット（x86-64、Itanium）である^[4]^[15]。64ビットのUEFIではロングモードも可能であり、ブート前の環境で64ビットアドレッシングの全メモリに直接アクセス可能である^[16]。

UEFIでは、ファームウェアとOSのアドレス空間が一致していなければならない。例えば、64ビットのUEFIからは64ビットのオペレーティングシステムしかブートできない。

サービス

EFIはブートサービスを定義していて、これにはさまざまなデバイス上でテキストおよびグラフィカルなコンソールが利用できる機能や、バスやブロックデバイス、ファイルシステムの機能が含まれる。ブートサービスは "ExitBootServices" を呼び出すまでのファームウェアがプラットフォームを制御している状態でのみ利用可能である。また、OS動作中も利用できるランタイムサービスとしては、日付や時間、NVRAMの管理サービスなどがある。

プロトコル

EFIでは2つのバイナリモジュール間の通信に使うソフトウェアインタフェース群をプロトコルとして定義している。全てのEFIドライバは、このプロトコルに則って他のモジュールにサービスを提供しなければならない。

デバイスドライバ

標準的なアーキテクチャ依存のデバイスドライバに加えて、EFIの仕様ではプロセッサに依存しないデバイスドライバ実行環境を提供していて、EFI Byte Code ないしEBCと呼んでいる。システムのファームウェアは、その環境にロードされたもしくはその環境内にあるEBCイメージ用のインタプリタを実行できることを、UEFI仕様によって要求されている。その点、EBCは Open Firmware に似ている。これはハードウェアに依存しないファームウェアで、PowerPCベースのアップルのMacintoshやサン・マイクロシステムズのSPARCコンピュータなどの間で採用された。

いくつかのアーキテクチャに特化した（非EBCな）EFIデバイスドライバはOSから利用可能なインタフェースを持つことができる。これにより、OSに特化したドライバをロードしなくても、基本的なグラフィックスやネットワーク機能についてはOSがEFIに頼ることができる。

ブートマネージャー

EFIブートマネージャーはまたOSを選択してロードするのにも使うことができる。これにより専用のブートローダ機構は必要がなくなる（OSのブートローダはEFIアプリケーションになる）。するとブートセクタを使用せずに済むが、標準的な名前の最初にロードすべきファイルを特殊なパーティションテーブルから参照できるようにしておく必要がある（\EFI\BOOT\boot[architecture name].efi）。

OSのブートローダーはUEFIアプリケーションの一種となるので、ファームウェアからアクセス可能なファイルシステム上にファイルとして格納しておく。NVRAMに格納されたブート変数で、そのローダーのパスを示す。ブートローダーはファームウェアから自動検出することも可能で、例えばリムーバブル・デバイスからのブートも可能となっている。

EFIシェル

EFIコミュニティはオープンソースなシェル環境を作った^[17]。これはちゃんとしたOSを直接起動するのではなく、なんらかの実装上でユーザがEFIシェルと呼ぶものを起動することができる。このシェルはEFIアプリケーションであり、プラットフォームのROM内に直接焼きこまれているか、ROM内のデバイスドライバが制御できるデバイス内に存在する必要がある。

シェルは他のEFIアプリケーション、例えばシステムの起動やOSのインストール、システムの診断や設定、システムのフラッシュROMのアップデートなどに使われる。このことにより、完全なOSを起動することなしにCDやDVDを再生したり、必要な機能を持つEFIアプリケーションを実行することができる。また、シェルのコマンドを使って、ファームウェアがサポートしているファイルシステム間同士で直接ファイルのコピーや移動を行うこともできる。デバイスドライバは動的にロードとアンロードができ、完全なTCP/IP スタックもまたシェル内から利用することができる。

EFIシェルは.nshの拡張子がついたスクリプトファイルをサポートしていて、DOSのバッチファイルに似ている。

シェルコマンドの名前はDOSのコマンドインタプリタもしくはUNIXのシェルから来ていることがある。そのため、EFIシェルはDOSのコマンドインタプリタを機能的に置き換えることができるようにも見える。

拡張機能

EFIの拡張機能はコンピュータにつけられている、なんらかの不揮発性のストレージデバイスからロードされる。たとえば、マザーボード上のROMに格納されている標準EFIファームウェアに機能を追加するために、OEMがハードディスクにEFIパーティションを作って、そのシステムを売るなどということができる。

実装と採用実績

Intel Platform Innovation Framework for EFI

Intel Platform Innovation Framework for EFI（元々 Tiano というコードネームで呼ばれていた）はEFIサポートを含んでいて、完全でレガシーフリーなファームウェア実装である。それは、compatibility support module (CSM) と呼ばれるものを通してレガシーなSystem BIOSのサポートを可能としている。

特に、このフレームワークは電源投入後のプラットフォームの初期化に必要なすべての処理を含んでいる。これらのファームウェアの内部動作はEFIの仕様には定義されていないが、Platform Initialization Specificationには記載されている。

インテルはこのフレームワークを完全な形でエンドユーザーに提供しているわけではない。アメリカンメガトレンド (AMI)^[18] や Insyde Software^[19] や Phoenix Technologies^[20] など独立BIOSベンダーに対してファームウェアの提供が行われているので、それを通じて利用が可能である。

フレームワークの一部はEFI Developer Kit (EDK) として、TianoCore projectにオープンソースとしてリリースされている。この実装はEFIといくつかのハードウェア初期化コードを含んでいるが、それ自身で完全な機能を持つファームウェアを構成できるわけではない。このコードにはBSDライセンスとEclipse Public Licenseを含むいくつかのライセンスが適用されている。TianoCoreはcorebootのペイロードとしても利用可能である。

EFIおよびこのフレームワークを用いたプラットフォーム

インテルの最初のItaniumワークステーションとサーバは2000年にリリースされ、EFI 1.02を実装している。

ヒューレット・パッカードの最初の Itanium 2 システムは2002年にリリースされ、EFI 1.10を実装している。これらはWindows、Linux、FreeBSD、HP-UXが起動できた。2003年6月には OpenVMS もサポートされている。

DIG64仕様に従ったEFI互換ファームウェアを搭載したすべてのItaniumとItanium2システム。

2003年 11月、ゲートウェイは、Gateway 610 Media Centerに、x86のWindowsベースのコンピュータシステムとしては初めてこのフレームワークをベースとしたファームウェアである、Insyde SoftwareのInsydeH2Oというファームウェアを導入した。このファームウェアではまだWindowsを起動するために、compatibility support moduleを使ってレガシーSystem BIOSを実装していた。

2006年 1月、アップルはインテルアーキテクチャ (IA-32) をベースとした最初のMacintosh (Intel Mac) を出荷した。このシステムは以前のPowerPCベースのシステムに採用していたOpen Firmwareに代わって、EFIを採用していた。2006年4月5日、アップルは Boot Camp と呼ばれるソフトウェアをリリースした。これには Windows XP または Vista をユーザが既存のパーティションを壊さずに簡単にインストールできるツールと、Windows XP用のドライバディスクを提供している。ここでもまたファームウェアアップデートを通じて、EFI実装に加えてレガシーSystem BIOSのサポートが追加された。続くMacintoshの機種ではより新しいファームウェアが入った状態で出荷されている。2014年現在のMacintoshは、Winodows 7以降のみに対応し、Windows XPのようなレガシーSystem BIOSを使ってロードされるOSを起動できない。

非常にメジャーなインテルのマザーボードは、このフレームワークをベースとしたファームウェアを搭載して出荷されている。2005年では、100万台以上インテルのボードがこのフレームワークを搭載して出荷されている^[21]。新型のモバイルやデスクトップ、サーバ製品ではこのフレームワークを用いて2006年に出荷が開始されている。すぐにすべてのIntel 945チップセットを採用しているボードはこのフレームワークを搭載することになるだろう。しかし、製品用のファームウェアはEFIをサポートせず、レガシーSystem BIOSに限定している。

2005年以来、EFIはXScaleをベースとする組み込みシステムのようなPC以外のアーキテクチャにも実装されている^[21]。

NT32を含むEDKによってWindowsアプリケーション内でEFIファームウェアおよびEFIアプリケーションを動作させることができるようになった。ただし、EDK NT32 では直接的なハードウェアアクセスは許されていない。つまり、EDK NT32 のターゲットとしてどんなEFIアプリケーションも実行できるわけではない。2007年、ヒューレット・パッカードはEFI互換ファームウェアを用いた高機能プリンタ8000シリーズをリリースした。

2008年、x86-64 システムでのUEFI採用が増えた。その多くは Compatibility Support Module (CSM) を使ったBIOSベースのOSのブートしか許していないが（従ってユーザーにはUEFIベースであることが明示されていない）、UEFIベースのOSのブートを許すシステムも出てきている。例えば、IBM x3450 サーバ、ClickBIOSを搭載したMSI製マザーボード、HP EliteBook やタブレットPC、HP Compaq ノートPCなどがある。

2009年、IBMはUEFIを搭載した System x マシンや BladeCenter マシンを出荷した。デルもUEFIを搭載したサーバを出荷している。他にも UEFI のホワイトペーパーに採用例が挙げられている^[22]。Sandy Bridge PC プラットフォームの多くはUEFIを採用している。

オペレーティングシステム (OS)

(U)EFI仕様において、(U)EFIからブートできるOSを "(U)EFI-aware OS" と呼ぶ。ここで「(U)EFIからブートできる」とは、任意のストレージデバイスに格納された(U)EFIのOSローダーを使って直接ブートできることを意味する。OSローダーのデフォルトの位置は \EFI\BOOT\boot[architecture name].efi で、"architecture name" は例えば IA32, X64, IA64 などである。一部OSベンダーは独自のOSローダーを持っている。ブート位置を変更している場合もある。

Linuxは2000年初期からeliloというEFIブートローダを使って、EFIを使って起動することができる。eliloはIA-64プラットフォーム上でLinuxを単に起動できるだけであり、IA-32とx86-64プラットフォームでも同じことが可能である^[23]。最近ではGRUBのEFI版もある^[24]。
HP-UXは2002年からIA-64システム上で(U)EFIを使ったブート機構を使用していた。
HP OpenVMS の IA-64 版は2003年12月の最初の評価版リリースから(U)EFIを使っている。製品版は2005年1月からリリースされている^[25]。
マイクロソフトのIA-64用のWindows Server 2003、Windows XP 64bit Edition、Windows2000 Advanced Serverのうち、ItaniumプロセッサファミリーをサポートするものはすべてEFIをサポートしており、DIG64仕様を通じてプラットフォームの要件となっている。
アップルは、インテルアーキテクチャベースのMacで一貫してEFIを採用している。
マイクロソフトはWindowsサーバであるWindows Server 2008のx64版でUEFIに対応した。Windows Vistaのx64版では、2008年 3月19日にWindows Update及びダウンロードセンターで配布が開始されたSP1でEFIに対応した。当初マイクロソフトは市場の関心が64ビットへ向いていることなどを理由に32ビットWindowsへのUEFI実装を行わなかったが^[26]、Windows 8の32ビット版ではSecure Bootと共にUEFIへと対応している^[27]^[28]。マイクロソフトは、Andrew RitzとJamie SchwarzがWindows VistaとWindows Server 2008上でUEFIを用いてOS起動前の処理を説明するビデオをリリースした^[29]。
マイクロソフトはコンピュータに "Designed for Windows 8" のロゴを付ける条件として、UEFIでテンプレート:仮リンクをデフォルトで有効にすることを要求している^[30]^[31]。レッドハットの開発者マシュー・ギャレットはセキュアブートをデフォルトで有効にするという要求に懸念を表明したが、マイクロソフトはそれに対して自身がそれを命令したことはないし、ファームウェア内で後から無効にすることを妨げるつもりもないと応じた^[30]^[31]。

仮想化

テンプレート:仮リンクでは、HP Integrity サーバでのUEFIブートを提供する。UEFI-awareのゲストOSのための仮想UEFI環境も提供する。
インテルでは、Sourceforge 上で Open Virtual Machine Firmware プロジェクトを主催している^[32]。
Mac OS X 向けのテンプレート:仮リンクは、EFIを使って Mac OS X Server の仮想機械をブートできる。
VirtualBox は3.1からUEFIを実装しているが^[33]、対応OSはUnix/Linux系に限られている（Windowsのx64版はUEFI対応不可）^[34]^[35]。
QEMUはEFIと共に利用可能である。
VMware vSphere の一部である VMware ESXi version 5 hypervisor は仮想機械内のBIOSの代替として仮想化EFIをサポートしている。

コンシューマ市場

2011年、ASRock、ASUSTeK、GIGABYTE、MSI 、BIOSTARなどがインテルの6-series LGA 1155 チップセットおよびAMDの 9 series チップセットを使ったコンシューマ向けマザーボードでEFIを採用している^[36]。

グラフィックス機能

AptioやGreat WallのUEFI実装では、メニューなどにグラフィックス要素が使われている^[37]。

EFI仕様では、2つのグラフィックス表示プロトコルが定義されている。1つは UGA (Universal Graphic Adapters) で、もう1つはGOP (Graphic Output Protocol) である。2つはよく似ている。UGAはEFI 1.1かそれ以前でのみ動作する。EFIはユーザインタフェースを定義していない。従ってその見た目や操作方法はSystem BIOSベンダーに一任されている。今テンプレート:いつのところ多くのEFI実装では、System BIOSのようなテキストモードのユーザインタフェースを採用している。

批判

coreboot開発者の1人Ronald G. MinnichとSF作家でデジタル権利活動家のコリイ・ドクトロウはEFIについて、ユーザーが自身のコンピュータを真に制御する能力を疎外することで知的所有権を守ろうとする試みだとして批判している^[38]^[39]。EFIは、BIOS最大の懸案事項である、ファームウェア用とOS用に別々のドライバが必要だという点を全く解決していない^[40]。

TianoCoreはUEFIに基づく完全にフリーなファームウェアを作るツールを提供するオープンソースプロジェクトだが^[41]、チップセット初期化のための特殊なドライバが含まれておらず、チップセットベンダーからの追加の機能提供を必要としている。TianoCoreはcorebootのペイロード・オプションであり、チップセット初期化コードも含んでいる。

UEFIは従来のSystem BIOSよりもネットワークブートの柔軟性が高いため、その点でセキュリティ的に懸念する見方もある^[42]。

セキュアブート

レッドハットの開発者マシュー・ギャレットは記事 "UEFI secure booting" で、UEFIのセキュアブートがLinuxに影響を与えるかもしれないという懸念を表明した（Windows 8 のロゴをつけたマシンでは、セキュアブートが有効化された状態で出荷され、キーコードのないLinuxではブートできない）^[43]。これに対してマイクロソフトは、顧客がセキュアブートを後から無効にすることは可能だと応じた^[1]^[44]。しかし、一部OEMがそのような設定変更できるファームウェア機能を省くのではないかという懸念が残っている。後に、マイクロソフトがARMシステムでのセキュアブートを無効にするための実装を禁じたと見られるとの報道がなされた^[45]^[46]。

フリーソフトウェア財団 (FSF) のジョシュア・ゲイはUEFIでのセキュアブート実装について懸念を表明し、FSFは次のような声明を発表した。

（下に署名する）我々は、フリーソフトウェアのOSをインストール可能にする形でいわゆる「セキュアブート」をUEFIに実装するよう全コンピュータメーカーに求める。ユーザーの自由を尊重し真のユーザーセキュリティを守るため、メーカーはコンピュータ所有者がブート制限を無効にできるようにするか、フリーソフトウェアのOSを自由にかつ絶対確実にインストールして利用できる手段を提供しなければならない。我々はそのような重大な自由を妨げるコンピュータを購入しないし勧めない。また、我々のコミュニティの人々にそのようなシステムを購入しないよう呼びかけていく。^[47]^[48]

マイクロソフトがリリースしたOEM製品のハードウェア認定に関する文書によれば、x86およびx86-64を採用した全デバイスはセキュアなUEFIを有効にしなければならないとあるが、カスタム・セキュアブート・モードでユーザーがシグネチャを追加できる手段を提供するとある。しかし、Windowsの動作するARMデバイスでは、カスタム・セキュアブート・モードへの移行もセキュアブートの無効化も不可能である^[45]。この文書は "Windows Hardware Certification Requirements" と呼ばれており^[49]、Windows 8 の動作するARMベースのマシンでは別のOSが動作する可能性を排除することが記されている。