Loading article…
| 統合拡張ファームウェアインターフェース | |
|---|---|
 | |
| 略語 | UEFI |
| 状態 | 公開済み |
| 年が始まった | 2006年[ a ] |
| 最新バージョン | 2.11 [ 1 ] 2024年12月16日 |
| 組織 | UEFIフォーラム |
| 関連規格 | |
| 前任者 | IBM PC互換コンピュータのBIOS [ b ] |
| ドメイン | ファームウェア |
| Webサイト | uefi.org |
Unified Extensible Firmware Interface、略してUEFI [ c ] [ d ]は、コンピューティングプラットフォームのファームウェアアーキテクチャの仕様です。コンピュータの電源を入れると、通常はオペレーティングシステムやその他のプログラムがロードされる前に、UEFIの実装が最初に実行されます。例としては、 AMI Aptio、Phoenix SecureCore、TianoCore EDK II、InsydeH2Oなどがあります。
UEFIは、IBM PC互換のすべてのパーソナルコンピュータのブートROMに存在していたBIOSを置き換えるものですが、[ 3 ] [ 4 ] CSMブートを使用してBIOSとの下位互換性を提供することもできます。元々IBMが独自アーキテクチャとして開発したBIOSとは異なり、UEFI仕様は業界コンソーシアムによって管理されています。どちらの製品版ファームウェア実装も、ほとんどが独自仕様のままです。
Intelは、オリジナルの拡張ファームウェアインターフェース（EFI）仕様を開発しました。IntelによるEFIの最終バージョンは、2005年にリリースされた1.10です。それ以降のバージョンは、UEFIフォーラムによってUEFIとして開発されています。
UEFIはプラットフォームやプログラミング言語に依存しないが、リファレンス実装であるTianoCore EDKIIではC言語が使用されている。
EFI の本来の動機は、1990 年代半ばの最初の Intel–HP Itaniumシステムの初期開発中に生まれました。BIOSの制限が、Itanium が対象としていた大型サーバー プラットフォームには制約が大きすぎました。[ 5 ]これらの懸念に対処する取り組みは 1998 年に始まり、当初はIntel Boot Initiativeと呼ばれていました。[ 6 ]後にExtensible Firmware Interface (EFI)に改名されました。[ 7 ] [ 6 ]
最初のオープンソースUEFI実装であるTianoは、2004年にIntelによってリリースされました。Tianoはその後EDK [ 8 ]およびEDK II [ 9 ]に取って代わられ、現在はTianoCoreコミュニティによって維持されています[ 10 ] 。
2005 年 7 月、インテルは EFI 仕様をバージョン 1.10 で開発を中止し、Unified EFI Forum に提供しました。Unified EFI Forumは、この仕様をUnified Extensible Firmware Interface (UEFI) として開発しました。オリジナルの EFI 仕様はインテルが所有しており、EFI ベースの製品のライセンスを独占的に提供していますが、UEFI 仕様は UEFI Forum が所有しています。[ 5 ] [ 11 ]
UEFI仕様のバージョン2.0は2006年1月31日にリリースされました。暗号化とセキュリティが追加されました。
UEFI仕様のバージョン2.1は、2007年1月7日にリリースされました。このバージョンでは、ネットワーク認証とユーザーインターフェースアーキテクチャ（UEFIでは「ヒューマンインターフェースインフラストラクチャ」と呼ばれる）が追加されました。
UEFI仕様のバージョン2.3.1は、2011年4月6日にリリースされました。このバージョンでは、セキュアブート機能とARMアーキテクチャのサポートが追加されました。
2018 年 10 月、Arm は、標準的なオペレーティングシステムとハイパーバイザーが Arm ベースのサーバーで動作することを保証することを目的としたコンプライアンス認証プログラムである Arm ServerReady を発表しました。このプログラムでは、システム ファームウェアが Server Base Boot Requirements (SBBR) に準拠する必要があります。SBBR では、UEFI、ACPI 、およびSMBIOS への準拠が求められます。2020 年 10 月、Arm は、このプログラムをエッジおよびIoT市場に拡張することを発表しました。新しいプログラム名はArm SystemReadyです。Arm SystemReady は、Base Boot Requirements ( BBR ) 仕様を定義しており、現在 3 つのレシピを提供しています。そのうち 2 つは UEFI に関連しています。1) SBBR: Windows、Red Hat Enterprise Linux、VMware ESXi などのエンタープライズ レベルのオペレーティング 環境に適した UEFI、ACPI、および SMBIOS への準拠が求められます。2) EBBR: Yocto などの組み込み環境に適した Embedded Base Boot Requirements ( EBBR )で定義されている 1 つの UEFI インターフェイスへの準拠が求められます。多くの Linux および BSD ディストリビューションは、両方のレシピをサポートできます。
2018年12月、マイクロソフトは、 Microsoft SurfaceおよびHyper-V 製品で使用されているTianoCore EDK IIのフォークであるProject Muを発表しました。このプロジェクトは、サービスベースのファームウェア配信モデルを採用しています。[ 12 ]
最新のUEFI仕様であるバージョン2.11は、2024年12月に公開されました。[ 13 ]
UEFIは32ビット以上のプロセッサアーキテクチャをサポートしています。ただし、リトルエンディアンモードのプロセッサのみがサポートされます。[ 13 ]：セクション1.9.1 UEFI仕様バージョン2.11には、以下のプロセッサアーキテクチャに関する公式ドキュメントがあります。[ 13 ]：セクション3.5.1.1
非公式のUEFIサポートは、 OpenPOWER抽象化レイヤーであるOPALの上にTianoCore EDK IIを実装することでPOWERPC64向けに開発中であり、リトルエンディアンモードで動作している。[ 14 ] [ 15 ] MIPS向けにも、オリジナルのEDKに基づいた非公式プロジェクトが存在する。[ 16 ] [ 17 ]しかし、両プロジェクトはそれぞれ2016年11月と2015年9月に放棄された。
UEFI は、プロセッサがより小さいまたは大きいビット幅をサポートしている場合でも、ファームウェアのビット幅に一致する UEFI アプリケーションの実行のみを許可します。たとえば、プロセッサが 32 ビット プロセッサ モードを備えていても、64 ビット UEFI ファームウェアは 64 ビット UEFI アプリケーションのみを実行できます。[ 13 ] :セクション 2.3.2 および 2.3.4一部のローエンド コンピュータは、64 ビット CPU 上で動作する 32 ビット UEFI ファームウェアを搭載して出荷されています。[ 18 ] UEFI アプリケーションがブート サービスを終了し、システムに対する完全な制御権を取得すると、プロセッサの実行モードを変更できるようになります。[ 13 ] :セクション 2.3.2 および 2.3.4ただし、ランタイム サービスを呼び出すには、すぐに元のプロセッサ モードに戻す必要があります。[ 19 ]ランタイム サービスは、ファームウェアの実装と同じプロセッサ モードからのみ呼び出すことができるためです。[ 13 ] :セクション 2.3.2 および 2.3.4
Linuxカーネルはバージョン3.15以降、 x86-64 CPUを搭載した32ビットUEFIファームウェア実装上で64ビットカーネルを起動するサポートを追加し、UEFIブートローダーがEFIハンドオーバープロトコルをサポートすることを要求しました。 [ 20 ] EFIハンドオーバープロトコルにより、UEFIブートローダーはUEFI初期化をカーネルのEFIブートスタブに委ねることができ、カーネルのみがUEFI初期化を実行します。[ 21 ] [ 22 ] [ 23 ]
UEFI は、マスター ブート レコード(MBR)を使用する標準的な PC ディスク パーティション スキームに加えて、 MBRの多くの制限から解放されたGUID パーティション テーブル(GPT) パーティション スキームにも対応しています。特に、ディスク パーティションの数とサイズに関する MBR の制限 (ディスクごとに最大 4 つのプライマリ パーティション、ディスクごとに最大 2 TB (2 × 2 40バイト) ) が緩和されています。より具体的には、GPT では、 512 バイト セクタで最大 8 ZiB (8 × 2 70バイト)のディスクおよびパーティション サイズが可能です。 [ 24 ] UEFI 仕様では、 GPT または MBR ディスク上のFAT12 / 16 / 32 [ 13 ] :セクション 13.3パーティションとEl Toritoフォーマットの光ディスクのみをサポートしています。[ 13 ] :セクション 13.3.2 GPT は UEFI 標準の一部ですが、BIOS PC がオペレーティングシステムを起動するためにも使用できます。[ 24 ] [ 25 ]
Linuxでの GPT のサポートは、カーネル構成中にオプションCONFIG_EFI_PARTITION(EFI GUID パーティション サポート) を有効にすることで実現されます。[ 26 ]このオプションにより、システム ファームウェアがシステムの制御を Linux に渡した後、Linux は GPT ディスクを認識して使用できるようになります。
下位互換性のために、Linux はGRUB 2と Linux の両方が GPT に対応しているため、BIOS ベースのシステムで GPT ディスクをデータ ストレージとブートの両方に使用できます。このような構成は通常BIOS-GPTと呼ばれます。GPTは保護 MBR を組み込んでいるため、BIOS ベースのコンピュータは、保護 MBR のブートストラップ コード領域に格納されている GPT 対応ブート ローダーを使用して GPT ディスクからブートできます。[ 24 ] GRUB の場合、 GPT パーティション ディスクにはポスト MBR ギャップがないため (GPT のプライマリ ヘッダーとプライマリ パーティション テーブルが引き継ぐため)、このような構成では GRUB が第 2 段階のコードを埋め込むために BIOS ブート パーティションが必要です。通常1MBのサイズであるこのパーティションのGPTスキームにおけるグローバル一意識別子（GUID）は21686148-6449-6E6F-744E-656564454649であり、GRUBはBIOS-GPTセットアップでのみ使用します。GRUBの観点からは、MBRパーティショニングの場合、このようなパーティションタイプは存在しません。システムがUEFIベースの場合、第2ステージコードの埋め込みは不要なため、このパーティションは必要ありません。[ 25 ] [ 24 ]
UEFI システムは GPT ディスクにアクセスしてそこから直接起動できるため、Linux は UEFI ブート方式を使用できます。UEFI システムで GPT ディスクから Linux を起動するには、ブートローダー、オペレーティングシステム カーネル、ユーティリティ ソフトウェアなどの UEFI アプリケーションを含むEFI システム パーティション(ESP) を作成する必要があります。 [ 27 ] [ 28 ]このような設定は通常UEFI-GPTと呼ばれ、ESP は互換性を最大限に高めるために、少なくとも 512 MB のサイズで FAT32 ファイルシステムでフォーマットすることが推奨されます。[ 24 ]
下位互換性のために、一部のUEFI実装では、従来のBIOSとの互換性を提供する互換性サポートモジュール（CSM）を介して、MBRパーティションディスクからの起動もサポートしています。この場合、UEFIシステムでのLinuxの起動は、従来のBIOSベースのシステムでの起動と同じです。
Windows 11 、 Windows Vista SP1 /SP2および7の64ビット版、そしてWindows 8、8.1、10の32ビット版と64ビット版は、2TBを超えるGPTディスクから起動できます。
EFIは、ブートサービスとランタイムサービスの2種類のサービスを定義しています。ブートサービスは、ファームウェアがプラットフォームを所有している間（つまり、ExitBootServices()呼び出し前）のみ利用可能で、さまざまなデバイス上のテキストコンソールやグラフィカルコンソール、バスサービス、ブロックサービス、ファイルサービスなどが含まれます。ランタイムサービスは、オペレーティングシステムが実行中もアクセス可能で、日付、時刻、NVRAMへのアクセスなどのサービスが含まれます。
UEFIは、EFIシステムパーティションにファイルとして保存されているUEFIアプリケーションと呼ばれる独立したプログラムを実行します。これらのプログラムは、UEFIシェル、ファームウェアブートマネージャ、またはその他のUEFIアプリケーションを介して起動でき、機器メーカー（OEM）とは独立して開発される場合があります。
UEFIアプリケーションの一種として、GRUB、rEFInd、systemd-boot、Windows Boot ManagerなどのOSブートローダーが挙げられます。これらはOSファイルをメモリにロードして実行します。また、OSブートローダーは、実行する別のUEFIアプリケーションを選択できるユーザーインターフェースを提供することもできます。UEFIシェルなどのユーティリティもUEFIアプリケーションです。
EFIは、プロトコルを2つのバイナリモジュール間の通信に使用されるソフトウェアインターフェースのセットとして定義しています。すべてのEFIドライバは、プロトコルを介して他のドライバにサービスを提供する必要があります。EFIプロトコルは、BIOSの割り込み呼び出しに似ています。
EFIは、標準的な命令セットアーキテクチャ（ISA）固有のデバイスドライバに加えて、不揮発性メモリにEFIバイトコード（EBC）として格納されたISA非依存のデバイスドライバを提供します。システムファームウェアには、EBCイメージのインタープリタが備わっています。この点において、EBCは、PowerPCベースのApple MacintoshやSun Microsystems SPARCコンピュータなどで使用されているISA非依存のファームウェアであるOpen Firmwareに類似しています。
一部のデバイスタイプ向けのアーキテクチャ固有の（EFIバイトコードではない）EFIドライバには、OSが使用できるインターフェースが含まれている場合があります。これにより、OSは、OS固有のドライバがロードされる前、またはロードされた場合に、基本的なグラフィックス機能やネットワーク機能を実行するためのドライバとしてEFIを利用できるようになります。
その他の場合、EFI ドライバは、他のタイプのディスク ボリュームからの起動を可能にするファイルシステム ドライバである可能性があります。例としては、 37 ファイルシステム用のefifs ( GRUB2コードに基づく) や、 RufusがNTFS ESP をチェーン ローディングするために使用するものなどがあります。 [ 32 ] [ 33 ]
EFI 1.0仕様では、グラフィック機能をサポートする方法としてUGA（Universal Graphic Adapter）プロトコルが定義されていました。UEFIにはUGAは含まれておらず、代わりにGOP（Graphics Output Protocol）が採用されています。[ 34 ]
UEFI 2.1では、ユーザー入力、ローカライズされた文字列、フォント、フォーム（HTMLの意味での）を管理するための「ヒューマンインターフェースインフラストラクチャ」（HII）が定義されました。これにより、OEM（相手先ブランド製造業者）やIBV（独立系BIOSベンダー）は、起動前設定用のグラフィカルインターフェースを設計できます。UEFIはデフォルトでUTF-16を使用して文字列をエンコードしますが、UEFI 2.4以降では、ASCIIのみの文字列をエンコードするためにASCIIを使用できるようになりました。
初期のUEFIファームウェアの実装のほとんどはコンソールベースだった。今日では、多くのUEFIファームウェアの実装はGUIベースになっている。
EFI システム パーティション (ESP と略されることが多い) は、 UEFI 仕様に準拠するコンピュータで使用されるデータ ストレージ デバイスパーティションです。コンピュータの電源投入時に UEFI ファームウェアによってアクセスされ、UEFI アプリケーションと、オペレーティングシステムブート ローダーを含む、これらのアプリケーションの実行に必要なファイルが格納されます。サポートされているパーティション テーブルスキームには、 MBRとGPT、および光ディスク上のEl Toritoボリュームが含まれます。 [ 13 ] :セクション 2.6.2 ESP で使用するために、UEFI はFAT ファイルシステムの特定のバージョンを定義しており、これは UEFI 仕様の一部として維持され、元の FAT 仕様とは独立しており、FAT32、FAT16 、およびFAT12ファイルシステムを含みます。[ 13 ] :セクション 13.3 [ 35 ] ESP は、BIOS の下位互換性の一部としてブート セクタ用のスペースも提供します。
コンピュータはブートと呼ばれるプロセスによって起動されます。コンピュータはハードウェアに組み込まれた非常に小さなプログラムによってオペレーティングソフトウェアをロードし、通常はさらに小さなプログラムを読み込んでオペレーティングシステム（OS）をロードして起動します。
従来のPC BIOSとは異なり、UEFIはコンピュータのデータストレージ上のブートセクタに依存せず、代わりにUEFI仕様の一部としてブートマネージャを定義します。コンピュータの電源がオンになると、ブートマネージャはブート構成を確認し、その設定に基づいて指定されたOSブートローダーまたはオペレーティングシステムカーネルを実行します。ブート構成は、コンピュータの永続的なNVRAMストレージに格納されている変数によって定義され、これにはOSローダーまたはOSカーネルへのファイルシステムパスを示す変数が含まれます。
OS ブート ローダーは UEFI によって自動的に検出されるため、USB フラッシュ ドライブなどのリムーバブル デバイスから簡単に起動できます。この自動検出は、OS ブート ローダーへの標準化されたファイル パスに依存しており、パスはコンピュータのアーキテクチャによって異なります。ファイル パスの形式は、<EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFIと定義されています。たとえば、x86-64システム上の OS ローダーへのファイル パスは\efi\boot\bootx64.efiであり、[ 13 ] :セクション 3.5.1.1およびARM64 アーキテクチャ上の\efi\boot\bootaa64.efiです。
GPT パーティション ディスクから UEFI システムを起動することは、一般的にUEFI-GPT ブートと呼ばれますが、UEFI 仕様では MBR パーティション テーブルが完全にサポートされる必要があります。[ 13 ] :セクション 13.3.2一部の UEFI ファームウェア実装では、ブート ディスクのパーティション テーブルの種類に応じて、BIOS ベースの CSM ブートにすぐに切り替わり、MBR パーティション ディスク上のEFI システム パーティションからの UEFI ブートを事実上防止します。このようなブート スキームは、一般的にUEFI-MBRと呼ばれます。
ブートマネージャには、ユーザーが利用可能なブートオプションのリストから目的のOS（またはセットアップユーティリティ）を選択できるように、テキストベースのユーザーインターフェースを備えているのが一般的です。
PCプラットフォームでは、UEFIブートをサポートするファームウェアは「UEFI BIOS」と呼ばれることが多いが、一部の新しいx86プラットフォームではCSMのサポートが完全に除外されている。
下位互換性を確保するため、PCクラスのマシンにおけるUEFIファームウェアの実装では、レガシーBIOSとの互換性を提供する互換性サポートモジュール（CSM）を介して、MBRパーティション化されたディスクからのレガシーBIOSモードでのブートをサポートすることができます。このシナリオでは、パーティションテーブルを無視し、ブートセクタの内容に依存することで、レガシーBIOSベースのシステムと同様の方法でブートが実行されます。
互換性サポートモジュールにより、UEFI をサポートしていないレガシー オペレーティングシステムや一部のレガシーオプション ROM を引き続き使用できるようになります。 [ 36 ]また、UEFI SMM が提供する機能に加えて、必要なレガシーシステム管理モード(SMM) 機能 (CompatibilitySmm)も提供します。このようなレガシー SMM 機能の一例として、従来のPS/2キーボードとマウスをエミュレートすることで、USB レガシー キーボードとマウスのサポートを提供することが挙げられます。[ 36 ]
2017年11月、インテルはクライアントプラットフォーム向けCSMのサポートを2020年までに段階的に終了する計画を発表した。[ 37 ]
2022年7月、カスペルスキーラボは、インテルのH81チップセットと影響を受けるマザーボードの互換性サポートモジュールを使用するマシン上で悪意のあるコードを連鎖的に起動するように設計されたルートキットに関する情報を公開しました。[ 38 ]
2023年8月、インテルは2024年までにサーバープラットフォームのCSMサポートを段階的に廃止する計画を発表した。[ 39 ]
UEFI 仕様には、Preboot Execution Environment (PXE) を介したネットワークブートのサポートが含まれています。PXE ブートのネットワークプロトコルには、インターネットプロトコル( IPv4およびIPv6 )、ユーザーデータグラムプロトコル(UDP)、動的ホスト構成プロトコル(DHCP)、Trivial File Transfer Protocol (TFTP)、iSCSIが含まれます。[ 13 ] : 924–1509 [ 40 ]
OSイメージはストレージエリアネットワーク（SAN）にリモートで保存でき、 SANへのアクセスにはインターネットスモールコンピュータシステムインターフェイス（iSCSI）とファイバーチャネルオーバーイーサネット（FCoE）がサポートプロトコルとして使用できます。 [ 13 ] [ 41 ] [ 42 ]
UEFI 仕様では、適切なデジタル署名で署名されていない UEFI ドライバや OS ブート ローダーの読み込みを防止することでブート プロセスを保護できるセキュア ブートが定義されています。セキュア ブートが有効になると、最初は「セットアップ」モードになり、「プラットフォーム キー」（PK）と呼ばれる公開鍵をファームウェアに書き込むことができます。鍵が書き込まれると、セキュア ブートは「ユーザー」モードになり、プラットフォーム キーで署名された UEFI ドライバと OS ブート ローダーのみがファームウェアによって読み込まれます。メモリに格納されているデータベースに「鍵交換キー」（KEK）を追加することで、他の証明書を使用できるようになりますが、それでもプラットフォーム キーの秘密鍵部分と関連付けられている必要があります。[ 44 ]セキュア ブートは「カスタム」モードにも設定でき、秘密鍵と一致しない追加の公開鍵をシステムに追加できます。[ 45 ]
セキュアブートは、Windows 8および8.1、Windows Server 2012および2012 R2、Windows 10、Windows Server 2016、2019、2022 、 Windows 11 、 VMware vSphere 6.5 [ 46 ]、およびFedora（バージョン18以降）、openSUSE （バージョン12.3以降）、RHEL（バージョン7以降）、CentOS（バージョン7以降[ 47 ] ）、Debian（バージョン10以降） [ 48] 、Ubuntu（バージョン12.04.2以降）、Linux Mint（バージョン21.3以降）[49][50]、AlmaLinux OS （バージョン8.4以降[ 51 ] ）を含むいくつかのLinuxディストリビューションでサポートされています。2025年1月現在 FreeBSDのサポートは計画段階にある。[ 52 ]
UEFI は、 UEFIブートローダーを含む他の UEFI アプリケーションを実行するために使用できるシェル環境を提供します。それとは別に、UEFI シェルで使用できるコマンドは、メモリ マップの取得 ( )、ブートマネージャ変数の変更 ( )、パーティショニング プログラムの実行( )、 UEFI ドライバのロード、テキスト ファイルの編集 ( ) など、システムまたはファームウェアに関するさまざまな情報を取得するために使用できます。[ 53 ] [ 54 ]memmapbcfgdiskpartedit
UEFI シェルのソースコードは、 IntelのTianoCore UDK/EDK2 プロジェクトからダウンロードできます。 [ 55 ]事前にビルドされた ShellBinPkg も利用可能です。[ 56 ] Shell v2 は UEFI 2.3 以降のシステムで最適に動作し、これらのシステムでは Shell v1 よりも推奨されます。Shell v1 はすべての UEFI システムで動作するはずです。[ 57 ] [ 58 ]
UEFI シェルを起動する方法は、システムマザーボードの製造元とモデルによって異なります。一部のシステムでは、ファームウェア セットアップで直接起動するオプションが既に用意されています<EFI_SYSTEM_PARTITION>/SHELLX64.EFI。たとえば、コンパイル済みの x86-64 バージョンのシェルを として利用可能にする必要があります。他のシステムでは、適切なキーの組み合わせで起動できる UEFI シェルが既に組み込まれています。[ 59 ]他のシステムでは、適切な USB フラッシュ ドライブを作成するか、bcfgコンパイル済みのバージョンのシェルに関連付けられたブート オプションを手動で追加するかのいずれかです。[ 54 ]
UEFIの拡張機能は、コンピュータに接続されたほぼすべての不揮発性ストレージデバイスからロードできます。例えば、OEM（相手先ブランドによる製品製造）メーカーは、ハードドライブにEFIシステムパーティションを備えたシステムを配布することができ、これにより、マザーボードのROMに格納されている標準のUEFIファームウェアに機能を追加できます。
UEFI Capsule はファームウェアから OS ファームウェアへの更新インターフェースを定義します。[ 60 ] Windows 8、Windows 8.1、Windows 10、[ 61 ]およびLinux 用のFwupd はそれぞれ UEFI Capsule をサポートしています。
BIOSと同様に、UEFI はシステム ハードウェア コンポーネントを初期化およびテストし、その後、大容量ストレージ デバイスまたはネットワーク接続を介してブート ローダーをロードします。x86 システムでは、 UEFI ファームウェアは通常マザーボードのNOR フラッシュチップに格納され、ブート プロセスは、たとえばPCI Expressデバイスの検出と初期化など、より複雑になります。[ 62 ] [ 63 ]一部の ARM ベースの Android および Windows Phone デバイスでは、UEFI ブート ローダーはeMMCまたはeUFSフラッシュ メモリに格納されます。
UEFI マシンは、UEFI への移行を容易にするために使用された以下のクラスのいずれかを持つことができます。[ 64 ]
第10世代Intel Coreプロセッサー以降、IntelはiGPU（Intel Graphics Technology ）向けのレガシービデオBIOSを提供しなくなりました。これらのCPUでレガシーブートを行うにはレガシービデオBIOSが必要ですが、これはビデオカードによって提供される場合があります。
これはUEFIブートの最初の段階ですが、その前にプラットフォーム固有のバイナリコードが存在する場合があります（例：Intel ME、AMD PSP、CPUマイクロコード）。これは、特定のアーキテクチャ向けにアセンブリ言語で記述された最小限のコードで構成されています。一時メモリ（多くの場合、CPUキャッシュ・アズ・RAM（CAR）またはSoCオンチップブートプロセッサ）を初期化し、ハンドオフ前にPEIを検証するオプションを備えた、システムのソフトウェアの信頼の基点として機能します。
UEFI ブートの第 2 段階は、依存関係を認識するディスパッチャで構成され、メイン メモリの初期化 (メモリ コントローラとDRAM の初期化) やファームウェアのリカバリ操作などの初期ハードウェア初期化タスクを処理する PEI モジュール (PEIM) をロードして実行します。さらに、現在のブート モードの検出と多くの ACPI S3 操作の処理も担当します。ACPI S3 レジュームの場合、多くのハードウェア レジスタをスリープ前の状態に復元する責任があります。PEI は CAR も使用します。この段階での初期化には、メモリ内にデータ構造を作成し、これらの構造内にデフォルト値を設定することが含まれます。[ 2 ]
この段階には、PEI基盤、PEIM、PPIなど、いくつかの構成要素があります。この段階では利用できるリソースが少ないため、この段階は最小限にとどめ、より豊富なリソースを持つ次の段階であるDXEに向けた準備も最小限にとどめる必要があります。
SECフェーズの引き継ぎ後、プラットフォームの責任はPEI財団が引き継ぎます。その責任範囲は以下のとおりです。
このコンポーネントは、PEIMを呼び出し、その依存関係を管理する役割を担います。
これらは、永続メモリ、CPU、チップセット、マザーボードなどのハードウェアコンポーネントの初期化を担当する最小限のPEIドライバです。各PEIMは単一の役割を担い、単一の初期化に特化しています。これらのドライバは、さまざまなベンダーから提供されています。
これはGUIDポインタのペアで構成されるデータ構造です。PPIはPEIサービスを介してPEIMによって検出されます。
DXEのシステム初期化が最小限に完了した後、PEI基盤はDXEを特定し、制御をDXEに渡します。PEI基盤は、IPL（初期プログラムロード）と呼ばれる特別なPPIを介してDXE基盤に信号を送信します。
このステージは、C モジュールと依存関係を認識するディスパッチャで構成されています。メイン メモリが使用可能になると、CPU、チップセット、メインボード、その他の I/O デバイスが DXE と BDS で初期化されます。このステージでの初期化には、マザーボードに接続されたハードウェアへの EFI デバイス パスの割り当てと、構成データのハードウェアへの転送が含まれます。[ 2 ]
BDS は DXE の一部です。[ 66 ] [ 67 ]この段階では、ブート デバイスが初期化され、NVRAMと呼ばれるアーキテクチャ定義変数に従って PCI デバイスのUEFI ドライバまたはオプション ROMが実行され、オペレーティングシステムのブート ローダー( Windows Boot Managerなど) が起動されます。
これは、ブートデバイスの選択からOSへの引き渡しまでの段階です。この時点で、UEFIシェルに入ったり、OSブートローダーなどのUEFIアプリケーションを実行したりできます。
ExitBootServices()の実行後、 UEFI はオペレーティングシステム(OS)に処理を引き継ぎます。UEFI 互換の OS は、ブート サービスを終了し、ファームウェアに不要になったすべてのコードとデータをアンロードさせ、SMMやACPIなどのランタイム サービス コード/データのみを残す責任を負います。[ 68 ]一般的な最新の OS は、ハードウェア デバイスを制御するために独自のプログラム (カーネル ドライバなど) を使用することを好みます。
旧バージョンのOSを使用する場合、CSMはこの呼び出しを処理し、システムが旧バージョンのBIOSの要件と互換性があることを保証します。
Intel の EFI 実装は、コードネームTianoと呼ばれるIntel Platform Innovation Frameworkです。Tiano は Intel のXScale、Itanium、IA-32、x86-64プロセッサで動作し、独自のソフトウェアですが、コードの一部はTianoCore EDK IIとしてBSD ライセンスまたはEclipse Public License (EPL)の下でリリースされています。TianoCore はcorebootのペイロードとして使用できます。[ 69 ]
Phoenix Technologiesの UEFI 実装は SecureCore Technology (SCT) というブランド名で販売されています。[ 70 ] American Megatrends はAptio という独自の UEFI ファームウェア実装を提供しており、[ 71 ] Insyde Software はInsydeH2O を提供しており、[ 72 ] Byosoft は ByoCore を提供しています。
2018年12月、マイクロソフトはSurfaceシリーズ向けのTianoCore EDK2ベースのUEFI実装のオープンソース版であるProject Muをリリースした。[ 73 ]
UEFI API の実装は、2017 年にユニバーサル ブート ローダー ( Das U-Boot ) に導入されました。 [ 74 ] ARMv8アーキテクチャでは、Linuxディストリビューションは、ブートにGNU GRUBと組み合わせて U-Boot UEFI 実装を使用します(例: SUSE Linux [ 75 ] )。OpenBSD も同様です。[ 76 ] iSCSI からのブートには、 U-Boot によってロードされる UEFI アプリケーションとしてiPXE を使用できます。[ 77 ]
2000年に発売されたインテル初のItaniumワークステーションおよびサーバーは、EFI 1.02を実装していた。
ヒューレット・パッカードが2002年にリリースした最初のItanium 2システムは、EFI 1.10を実装していました。これらのシステムは、 Windows、Linux、FreeBSD、およびHP-UXを起動することができました。OpenVMSは2003年6月にUEFI機能を追加しました。
2006 年 1 月、Apple Inc. はIntel ベースの Macintosh コンピュータを初めて出荷しました。これらのシステムは、以前の PowerPC ベースのシステムで使用されていたOpen Firmwareの代わりに EFI を使用しました。 [ 78 ] 2006 年 4 月 5 日、Apple はBoot Camp を初めてリリースしました。Boot Campは、Windows ドライバ ディスクと非破壊パーティション ツールを生成し、Mac OS X (現在の macOS) を再インストールすることなく Windows XP または Vista をインストールできるようにします。ファームウェア アップデートもリリースされ、EFI 実装に BIOS 互換性が追加されました。以降の Macintosh モデルには、新しいファームウェアが搭載されて出荷されました。[ 79 ]
2005年には、100万台以上のIntel製システムがIntelのUEFI実装を搭載して出荷されました。[ 80 ] IntelのUEFI実装を使用した新しいモバイル、デスクトップ、サーバー製品が2006年に出荷開始されました。たとえば、Intel 945チップセットシリーズを使用するボードは、IntelのUEFIファームウェア実装を使用しています。
2005年以降、EFIはXScaleコアをベースとした組み込みシステムなどの非PCアーキテクチャにも実装されている。[ 80 ]
EDK（EFI開発キット）にはNT32ターゲットが含まれており、これによりWindowsアプリケーション内でEFIファームウェアとEFIアプリケーションを実行できます。ただし、EDK NT32ではハードウェアへの直接アクセスは許可されていません。つまり、EDK NT32ターゲットで実行できるEFIアプリケーションとドライバは限られています。
2008年には、より多くのx86-64システムがUEFIを採用しました。これらのシステムの多くは、互換性サポートモジュール（CSM）を介してBIOSベースのOSのみを起動できるため（ユーザーにはUEFIベースとは認識されません）、UEFIベースのOSを起動できるシステムも登場しました。例えば、IBM x3450サーバー、 ClickBIOSを搭載したMSIマザーボード、HP EliteBookノートブックPCなどが挙げられます。
2009年、IBMはUEFI機能を搭載したSystem xマシン（x3550 M2、x3650 M2、iDataPlex dx360 M2）とBladeCenter HS22を出荷した。DellはUEFI機能を搭載したPowerEdge T610、R610、R710、M610、M710サーバーを出荷した。その他の市販システムについては、UEFIホワイトペーパーに記載されている。[ 81 ]
2011年、主要ベンダー（ ASRock、Asus、Gigabyte、MSIなど）は、Intel 6シリーズLGA 1155チップセットとUEFI搭載のAMD 9シリーズAM3+チップセットを使用したコンシューマー向けマザーボードをいくつか発売した。[ 82 ]
2012 年 10 月に Windows 8 がリリースされたことにより、Microsoft の認証要件では、コンピューターに UEFI 仕様を実装するファームウェアを含めることが求められるようになりました。さらに、コンピューターが Windows 8 の「コネクテッド スタンバイ」機能 (デバイスがスマートフォンと同等の電源管理を行い、スタンバイ モードからほぼ瞬時に復帰できる機能) をサポートしている場合、ファームウェアに互換性サポート モジュール (CSM) を含めることは許可されていません。そのため、コネクテッド スタンバイをサポートするシステムでは、レガシー BIOS オペレーティングシステムを起動することができません。[ 83 ] [ 84 ]
2017年10月、インテルはUEFIクラス3を優先するため、2020年までにすべての製品から従来のPC BIOSサポートを削除すると発表した。 [ 85 ] 2019年までに、インテルプラットフォームをベースにしたすべてのコンピュータは、従来のPC BIOSサポートを持たなくなった。
(U)EFI から起動できるオペレーティングシステムは、(U)EFI 仕様で定義されている (U)EFI 対応オペレーティングシステムと呼ばれます。ここで、(U)EFI から起動するという用語は、任意のストレージ デバイスに保存されている (U)EFI オペレーティングシステム ローダーを使用してシステムを直接起動することを意味します。オペレーティングシステム ローダーのデフォルトの場所は であり、マシン タイプの短い名前は、、、、またはに<EFI_SYSTEM_PARTITION>/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFIなります。[ 13 ] :セクション 3.5.1.1オペレーティングシステム ベンダーによっては、独自のブート ローダーを持っている場合があります。また、デフォルトの起動場所を変更する場合もあります。IA32X64IA64ARMAA64
UEFI の実装上の欠陥が悪用され、永続性を獲得し、システムの再起動、オペレーティングシステムの再インストール、さらには破損した PCI 永続フラッシュストレージなどの物理的な部品の部分的な交換後でも、侵害されたシステムへの悪意のあるアクセスを維持する能力が獲得されました。セキュア ブートが有効になっている場合でも、2023 年に脆弱性がありました。[ 127 ] 2023 年に、マイクロソフトはBlackLotus UEFI マルウェアに関する警告を公開しました。 [ 128 ]
EDK2アプリケーション開発キット（EADK）を使用すると、UEFIアプリケーションで標準Cライブラリ関数を使用できます。EADKは、 IntelのTianoCore UDK / EDK2 SourceForgeプロジェクトから無料でダウンロードできます。例として、EADKを使用してPythonインタープリタのポートをUEFIアプリケーションとして提供できます。[ 129 ] .UDK2015以降、開発はGitHubに移行しました。[ 130 ]
多くのデジタル権利活動家がUEFIに抗議している。corebootの共同著者であるロナルド・G・ミニッチとデジタル権利活動家のコーリー・ドクトロウは、UEFIはユーザーがコンピュータを真に制御する能力を奪おうとする試みだと批判している。[ 131 ] [ 132 ] corebootの共同著者であるロナルド・G・ミニッチなどの批判者は、UEFIはほとんどのハードウェアでファームウェア用とオペレーティングシステム用の2つの別々のドライバを必要とするという歴史的な構成を維持していると主張している。[ 133 ]
オープンソースプロジェクトのTianoCoreもUEFIを提供しています。[ 134 ] TianoCoreにはチップセット機能を初期化する専用のファームウェアドライバやモジュールがありませんが、TianoCoreはcorebootの多くのペイロードオプションの1つです。corebootの開発には、初期化ドライバの開発に必要な仕様を提供するチップセットメーカーとの協力が必要です。
2011年、マイクロソフトは、Windows 8オペレーティングシステムを実行するために認定されたコンピュータは、マイクロソフトの公開鍵が登録され、セキュアブートが有効になっている状態で出荷されなければならないと発表しました。これは、これらのデバイスにはUEFIの使用が必須であることを意味しています。[ 135 ] [ 136 ]この発表後、フリーソフトウェア財団を含む批評家やフリーソフトウェア/オープンソースの擁護者は、マイクロソフトがUEFIのセキュアブート機能を使用してLinuxなどの代替オペレーティングシステムのインストールを制限する可能性があると懸念を表明しました。マイクロソフトは、セキュアブートの要件がロックインの一種として機能することを意図したものではないと否定し、要件を明確にするために、Windows 8用に認定されたx86ベースのシステムではセキュアブートをカスタムモードにするか無効にする必要があるが、ARMアーキテクチャを使用するシステムではそうではないと述べました。[ 45 ] [ 137 ] Windows 10では、OEMがx86システムのユーザーがセキュアブートを管理できるかどうかを決定できます。[ 138 ]
他の開発者たちは、一般的にLinuxシステムでセキュアブートのサポートを実装する際の法的および実際的な問題について懸念を表明した。元Red Hat開発者のMatthew Garrett氏は、 GNU General Public Licenseバージョン 3の条件により、ディストリビューションの開発者が秘密鍵を公開しない限りGNU GRand Unified Bootloaderの使用が妨げられる可能性があると指摘した（ただし、 Free Software Foundationはその後、鍵を提供する責任はハードウェアメーカーにあると立場を明確にした）[ 139 ] [ 88 ]。また、高度なユーザーが自己署名せずにセキュアブートを有効にして動作するカスタムカーネルを構築することも難しいだろうとも指摘した。 [ 137 ]他の開発者たちは、別の鍵で署名されたLinuxビルドを提供することを提案したが、OEMにMicrosoftキーと一緒に必要な鍵をコンピュータに同梱するよう説得するのは難しいだろうと指摘した。[ 4 ]
いくつかの主要な Linux ディストリビューションは、セキュア ブートのさまざまな実装を開発してきました。ギャレット自身は、シムと呼ばれる最小限のブートローダーを開発しました。これは、Linux ディストリビューションが提供するキーをユーザーが個別に信頼できるようにする、事前にコンパイルされ署名されたブートローダーです。[ 140 ] Ubuntu 12.10 は、ブートローダーのみを検証し、署名されていないカーネルのロードを許可するCanonical独自のキーで使用するために事前構成された古いバージョンのシムを使用しています。開発者は、信頼できるカーネルはユーザー スペースのみを保護するのに効果的であり、セキュア ブートが保護を追加するように設計されている起動前の状態を保護するのに効果的ではないため、ブートローダーのみに署名する方が実現可能であると考えました。これにより、ユーザーはシステムを再構成する必要なく、独自のカーネルをビルドしてカスタムカーネル モジュールを使用することもできます。 [ 88 ] [ 141 ] [ 142 ] Canonical は、オペレーティングシステムを実行する認定 OEM コンピュータにプリロードされた Ubuntu のインストールに署名するための独自の秘密鍵も保持しており、セキュア ブート要件も強制する予定です。つまり、ファームウェアに Canonical キーと Microsoft キー (互換性の理由) の両方を含める必要があります。Fedoraもshim を使用しますが、カーネルとそのモジュールの両方に署名する必要があります。[ 141 ] shim には、ローカルでコンパイルされたカーネルやディストリビューション メンテナによって署名されていないその他のソフトウェアに署名するために使用できるマシン オーナー キー (MOK) があり、セキュア ブート モードをセットアップ モードに変更する必要はありません。[ 143 ] [ 144 ]
オペレーティングシステムのカーネルとそのモジュールも署名する必要があるかどうかについては議論があり、UEFI 仕様では要求されていませんが、Microsoft は契約上の要件として必要であり、システムのセキュリティを侵害する可能性のあるコードの署名に使用される証明書を取り消す権利を留保していると主張しています。[ 142 ] Windows では、セキュア ブートが有効になっている場合、すべてのカーネル ドライバはデジタル署名されている必要があり、WHQL 以外のドライバはロードが拒否される場合があります。2013 年 2 月、別の Red Hat 開発者が、Microsoft が署名したPEファイルに埋め込まれたマスターX.509キーを使用して Microsoft の Authenticode 署名を解析できるようにする Linux カーネルへのパッチを提出しようとしました。しかし、この提案は、Red Hat がセキュア ブート インフラストラクチャに対する Microsoft の制御に迎合していると主張する Linux の生みの親である Linus Torvalds によって批判されました。[ 145 ]
2013年3月26日、スペインのフリーソフトウェア開発グループHispalinuxは、OEMシステムにおけるマイクロソフトのセキュアブート要件が「妨害的」かつ反競争的であるとして、欧州委員会に正式な苦情を申し立てた。 [ 146 ]
2013年8月のBlack Hatカンファレンスで、セキュリティ研究者グループが、セキュアブートを悪用するために使用できるUEFIの特定のベンダー実装における一連のエクスプロイトを発表しました。[ 147 ]
2016年8月、2人のセキュリティ研究者が、Microsoftがオペレーティングシステムの署名に使用している「ゴールデンキー」セキュリティキーを発見したと報告されました。[ 148 ]技術的には、キー自体は公開されていませんが、そのキーで署名された悪用可能なバイナリが公開されました。これにより、ソフトウェアはMicrosoftによって署名されたかのように実行できるようになり、ルートキットやブートキット攻撃の潜在的なリスクが生じます。また、パッチを署名済みの悪用可能なバイナリに置き換えることでダウングレードされる可能性があるため、修復作業も複雑になります。Microsoftは、この脆弱性はARMアーキテクチャとWindows RTデバイスのみに影響すると述べ、2つのアップデートをリリースしましたが、脆弱性を完全に解決するにはエンドユーザーのファームウェアでキーの置き換えが必要になるため、これらのアップデートでは悪用を完全に防ぐことはできないと報告されています。
2023年3月1日、ESETの研究者らは、以前のセキュリティアップデートの制限を悪用してUEFIセキュアブートをバイパスできる最初のアクティブUEFIブートキットである「BlackLotus」を発見したと報告した。[ 149 ] [ 150 ]
2024 年 8 月、Windows 11およびWindows 10 のセキュリティ更新プログラムにより、デバイスの UEFI NVRAM に Secure Boot Advanced Targeting (SBAT) 設定が適用され、一部の Linux ディストリビューションがロードに失敗するようになりました。SBAT は、 Windows Boot Managerおよび shim の新しいバージョンでサポートされているプロトコルで、バグのある、または脆弱な中間ブートローダー (通常は Windows Boot Manager およびGRUBの古いバージョン) がブート プロセスでロードされるのを拒否します。この変更は翌月に元に戻されました。[ 151 ]
2025年6月、LWN.netは、Microsoft UEFI CA 2011証明書が2026年6月27日に期限切れとなり、セキュアブートが有効になっている場合、一部のLinuxの起動が拒否される可能性があると報告した。[ 152 ] [ 153 ]しかし、TianoCore EDK IIや多くの商用UEFI実装（AMI Aptioなど）では、セキュアブート証明書のタイムスタンプチェックは通常デフォルトで無効になっている。[ 153 ]
2025年1月現在、多くのLinuxディストリビューションがUEFIセキュアブートをサポートしています。 例えば、RHEL (RHEL 7 以降)、CentOS (CentOS 7 以降[ 154 ] )、Ubuntu、Fedora、Debian (Debian 10 以降[ 155 ] )、OpenSUSE、SUSE Linux Enterprise [ 156 ]など。
市販デバイスにおけるUEFIファームウェアの特定の実装に関して、多くの技術的な問題が報告されている。[ 157 ]
2012 年 10 月に Windows 8 がリリースされた後、セキュア ブートを搭載した一部のLenovo製コンピュータ モデルでは、UEFI が UEFI でサポートされているオペレーティングシステムの説明文字列に「 Windows Boot Manager」または「Red Hat Enterprise Linux」が存在するかどうかをチェックし、存在しない場合はロードを拒否することが判明しました。[ 158 ]セキュア ブートの動作に必要な特定のファームウェア証明書が欠落しているいくつかのToshiba製ノートパソコン モデルでも同様の運用上の問題が報告されています。[ 157 ]
2013 年 1 月、特定のSamsung 製ノートパソコンの UEFI 実装に関するファームウェアの問題が公表され、Linux ディストリビューションを UEFI モードでインストールするとデバイスが完全に動作不能になることが判明しました。当初の報告では、この問題は Samsung 製ノートパソコンのシステム機能にアクセスするために設計されたカーネル モジュールとの競合が原因であるとされていました (カーネル メンテナが安全対策として UEFI システムでモジュールを無効にするよう促す)。しかし、Matthew Garrett による分析では、この状態は、過剰な UEFI 変数を不揮発性メモリに保存することによって引き起こされ、これは Windows 内の特定の条件下でも発生する可能性がある動作であることが示されました。彼の分析では、関連するカーネル モジュールがカーネル メッセージ ダンプをファームウェア ストレージ領域に書き込むようにし、障害状態を実行したと結論付けています。[ 30 ] [ 159 ] [ 160 ]
Q: EFIとUEFIの関係は何ですか？ A: UEFI仕様は、Intelが公開したEFI 1.10仕様に基づいており、Unified EFI Forumが修正と変更を管理しています。IntelはEFI 1.10仕様の著作権を保持していますが、フォーラムが仕様を進化させられるようにフォーラムに提供しています。EFI仕様の今後のバージョンは提供されませんが、ライセンスを取得している顧客は、Intelからのライセンス条件に基づいて引き続き使用できます。Unified EFI仕様のライセンスは、Intelではなくフォーラムから提供されています。
... プラットフォームは UEFI クラス 3 である必要があります (定義については、UEFI 業界グループ、「市販のプラットフォームとソリューションを使用した UEFI の評価」バージョン 0.3 を参照)。互換性サポート モジュールがインストールされていないか、インストールできない状態である必要があります。BIOS エミュレーションと従来の PC/AT ブートは無効にする必要があります。
は、主流の 64 ビット コンピューティングとプラットフォーム コストの現状から、ベンダーがネイティブ UEFI 32 ビット ファームウェアの製造に興味を持たないだろうと判断しました。そのため、Microsoft は当初、32 ビット UEFI 実装のサポートを出荷しませんでした。
