UEFI

統合拡張ファームウェアインターフェース

略語	UEFI
状態	公開済み
開始年	2006年[a]
最新バージョン	2.10 2022年8月29日
組織	UEFI フォーラム
関連規格	ACPI、UEFI プラットフォームの初期化
前任者	IBM PC互換機のBIOS [b]
ドメイン	ファームウェア
Webサイト	uefi.org

UEFI 搭載のLenovo ThinkPad T470のブート順序選択メニュー

UEFIの実装は通常、マザーボード上にあるNORベースのフラッシュメモリ^{[1] [2] [3]}に保存されます。さまざまなI/Oプロトコルを使用できますが、最も一般的なのはSPIです。

UEFI（Unified Extensible Firmware Interface、/ ˈ juː ɪ f aɪ /または略称）^[c]は、コンピューティングプラットフォームのファームウェアアーキテクチャの仕様です。コンピューターの電源を入れると、通常、オペレーティングシステムが起動する前に、UEFI実装が最初に実行されます。例としては、AMI Aptio、Phoenix SecureCore、TianoCore EDK II、InsydeH2Oなどがあります。

UEFIは、IBM PC互換機のブートROMに存在していたBIOSに代わるものです。^{[4] [5]}ただし、 CSMブートを使用してBIOSとの下位互換性を提供することもできます。元々 IBMが独自のソフトウェアとして作成した事実上の標準である前身のBIOSとは異なり、UEFIは業界コンソーシアムによって維持されているオープンスタンダードです。

Intel は、オリジナルのExtensible Firmware Interface ( EFI ) 仕様を開発しました。Intel の最後の EFI バージョンは、2005 年にリリースされた 1.10 です。以降のバージョンは、Unified EFI Forumによって UEFI として開発されました。

UEFI はプラットフォームやプログラミング言語に依存しませんが、リファレンス実装 TianoCore EDKII には Cが使用されます。

EFI の元々の動機は、1990 年代半ばのIntel-HP Itaniumシステムの初期開発中に生まれました。BIOSの制限 (16 ビットリアル モード、1 MB のアドレス指定可能なメモリ空間、^[6] アセンブリ言語プログラミング、PC ATハードウェアなど) は、Itanium がターゲットとしていた大規模なサーバー プラットフォームには制限が厳しすぎました。^[7]これらの問題に対処するための取り組みは 1998 年に始まり、当初はIntel Boot Initiativeと呼ばれていました。^{[8]これは後に}Extensible Firmware Interface (EFI)に改名されました。^{[9] [10]}

最初のオープンソースUEFI実装であるTianoは、2004年にIntelによってリリースされました。Tianoはその後EDK ^[11]とEDK II ^[12]に置き換えられ、現在はTianoCoreコミュニティによってメンテナンスされています。^[13]

2005年7月、インテルはEFI仕様のバージョン1.10の開発を中止し、Unified EFI Forumに寄贈しました。Unified EFI Forumは、この仕様をUnified Extensible Firmware Interface (UEFI)として開発しました。元のEFI仕様は、EFIベースの製品のライセンスを独占的に提供するインテルが引き続き所有していますが、UEFI仕様はUEFIフォーラムが所有しています。^{[7] [14]}

UEFI 仕様のバージョン 2.0 は、2006 年 1 月 31 日にリリースされました。暗号化とセキュリティが追加されました。

UEFI 仕様のバージョン 2.1 は、2007 年 1 月 7 日にリリースされました。ネットワーク認証とユーザー インターフェイスアーキテクチャ (UEFI の「ヒューマン インターフェイス インフラストラクチャ」) が追加されました。

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) で定義されている一連の UEFI インターフェイスへの準拠が必要です。多くの Linux および BSD ディストリビューションは、両方のレシピをサポートできます。

2018年12月、マイクロソフトはMicrosoft SurfaceおよびHyper-V製品で使用されているTianoCore EDK IIのフォークであるProject Muを発表しました。このプロジェクトは、ファームウェアをサービスとして推進するものです。^[15]

最新のUEFI仕様バージョン2.10は2022年8月に公開されました。^[16]

EFI仕様で定義されたインターフェースには、プラットフォーム情報を含むデータテーブルと、OSローダーとOSで利用可能なブートおよびランタイムサービスが含まれています。UEFIファームウェアは、BIOSに比べていくつかの技術的な利点があります。^[17]

• GUIDパーティションテーブル（GPT）を使用して、大きなパーティション（ 2TB以上）を含むディスクを起動する機能 ^{[18] [d] [19]}
• ネットワーク機能、GUI、多言語を含む柔軟なプレOS環境
• 32 ビット (例: IA-32、ARM32 ) または 64 ビット (例: x64、AArch64 ) の OS 事前環境
• C言語プログラミング
• UEFI シェル用の Python インタープリターを使用した Python プログラミング
• モジュラー設計
• 後方互換性と前方互換性

UEFIを使用すると、WindowsなどのオペレーティングシステムのプロダクトキーをデバイスのUEFIファームウェアに保存できます。^{[20] [21] [22] Windows 8 [23] [24]}以降を搭載したデバイスにはUEFIが必要です。

オペレーティングシステムがUEFI構成データにアクセスすることも可能です。^[25]

バージョン2.5の時点では、Itanium、x86、x86-64、ARM（AArch32）、ARM64（AArch64）用のプロセッサバインディングが存在します。^[26]リトルエンディアンプロセッサのみサポートされます。^[27] POWERPC64用の非公式UEFIサポートは、リトルエンディアンモードで実行されるOpenPOWER抽象化レイヤーであるOPAL ^[28]上にTianoCoreを実装することにより開発中です。 ^[29]同様のプロジェクトがMIPS ^[30]とRISC-Vにも存在します。^[31] UEFI 2.7の時点で、RISC-Vプロセッサバインディングは32ビット、64ビット、128ビットモードで正式に確立されています。^[32]

標準的な PC BIOS は、16 ビットのIntel 8088プロセッサを使用したIBM 5150をベースにした設計のため、16 ビットのプロセッサ モードと 1 MB のアドレス指定可能なメモリ空間に制限されています。^{[7] [33} ]これに対し、UEFI 環境のプロセッサ モードは、32 ビット ( IA-32、AArch32) または 64 ビット ( x86-64、Itanium、AArch64) のいずれかになります。^{[7] [34]} 64 ビットの UEFI ファームウェア実装はロング モードをサポートしており、プリブート環境のアプリケーションは 64 ビットのアドレッシングを使用してマシンのすべてのメモリに直接アクセスできます。^[35]

UEFIでは、ファームウェアとオペレーティングシステムローダー（またはカーネル）のサイズが一致している必要があります。つまり、64ビットのUEFIファームウェア実装は、64ビットのオペレーティングシステム（OS）ブートローダーまたはカーネルのみをロードでき（CSMベースのレガシーブートが使用されない限り）、同じことが32ビットにも当てはまります。システムがブートサービスからランタイムサービスに移行すると、オペレーティングシステムカーネルが引き継ぎます。この時点で、カーネルは必要に応じてプロセッサモードを変更できますが、これによりランタイムサービスの使用が禁止されます（カーネルが再び切り替えない限り）。^{[36] ：セクション2.3.2および2.3.4}バージョン3.15の時点で、Linuxカーネルは、UEFIブートローダーからのUEFIハンドオーバーサポートを要件として、 x86-64 CPU上で実行される32ビットUEFIファームウェア実装で64ビットカーネルを起動することをサポートしています。^[37] UEFIハンドオーバープロトコルは、カーネルとUEFIブートローダー間のUEFI初期化コードの重複を排除し、初期化をLinuxカーネルのUEFIブートスタブによってのみ実行できるようにします。^{[38] [39]}

UEFIは、マスターブートレコード（MBR）を使用する標準的なPCディスクパーティション方式に加えて、 MBRの多くの制限から解放されたGUIDパーティションテーブル（GPT）パーティション方式でも動作します。特に、ディスクパーティションの数とサイズに関するMBRの制限（ディスクあたり最大4つのプライマリパーティション、ディスクあたり最大2TB  （ 2×2 ⁴⁰ バイト））が緩和されています。^[40]より具体的には、GPTでは最大8ZiB  （ 8×2 ⁷⁰バイト）のディスクとパーティションサイズが許可されます。^{[41] [42]}

LinuxでのGPTのサポートは、カーネル構成時にオプションCONFIG_EFI_PARTITION（EFI GUIDパーティションサポート）をオンにすることで有効になります。^[43]このオプションにより、システムファームウェアがシステムの制御をLinuxに渡した後、LinuxはGPTディスクを認識して使用できるようになります。

下位互換性のため、Linux は BIOS ベースのシステムで GPT ディスクをデータ ストレージとブートの両方に使用できます。これは、 GRUB 2と Linux の両方が GPT に対応しているためです。このような設定は通常、BIOS-GPTと呼ばれます。^{[44] [信頼できない情報源? ]} GPT には保護 MBR が組み込まれているため、BIOS ベースのコンピューターは、保護 MBR のブートストラップ コード領域に格納されている GPT 対応ブート ローダーを使用して GPT ディスクからブートできます。^[42] GRUB の場合、 GPT パーティション ディスクには MBR 以降のギャップがないため (GPT のプライマリ ヘッダーとプライマリ パーティション テーブルによって引き継がれます)、このような構成では GRUB が第 2 段階のコードを埋め込むための BIOSブート パーティションが必要になります。通常 1  MBのサイズで、 GPT スキームでのこのパーティションのグローバル一意識別子(GUID) は21686148-6449-6E6F-744E-656564454649であり、BIOS-GPT セットアップでのみ GRUB によって使用されます。GRUB の観点からは、MBR パーティション分割の場合、このようなパーティション タイプは存在しません。システムが UEFI ベースである場合、第 2 段階のコードを埋め込む必要がないため、このパーティションは必要ありません。^{[18] [42] [44]}

UEFI システムは GPT ディスクにアクセスして直接起動できるため、Linux は UEFI ブート メソッドを使用できます。UEFI システムで GPT ディスクから Linux を起動するには、ブートローダー、オペレーティング システム カーネル、ユーティリティ ソフトウェアなどの UEFI アプリケーションを含む EFIシステム パーティション(ESP) を作成する必要があります。 ^{[45] [46] [47] [信頼できない情報源? ]このようなセットアップは通常}UEFI-GPTと呼ばれますが、ESP は互換性を最大限に高めるために、少なくとも 512 MB のサイズで FAT32 ファイルシステムでフォーマットすることが推奨されます。^{[42] [44] [48] [信頼できない情報源? ]}

下位互換性のため、一部のUEFI実装では、レガシーBIOSとの互換性を提供する互換性サポートモジュール（CSM）を介して、MBRパーティションディスクからの起動もサポートしています。^[49]その場合、UEFIシステムでのLinuxの起動は、レガシーBIOSベースのシステムの場合と同じです。

EFIのいくつかの手法とデータ形式はMicrosoft Windowsのものと似ています。^{[50] [51]}

Windows Vista SP1以降 の 64ビットバージョンおよびWindows 8、8.1、10、11の 64 ビット バージョンは、2 TBを超える GPT ディスクから起動できます 。

EFI は、ブート サービスとランタイム サービスの 2 種類のサービスを定義します。ブート サービスは、ファームウェアがプラットフォームを所有している間 (つまり、呼び出し前) のみ使用可能で、さまざまなデバイスのテキスト コンソールとグラフィカル コンソール、およびバス、ブロック、およびファイル サービスが含まれます。ランタイム サービスは、オペレーティング システムの実行中でもアクセス可能で、日付、時刻、 NVRAMExitBootServices()アクセスなどのサービスが含まれます。

グラフィックス出力プロトコル (GOP) サービス

グラフィックス出力プロトコル（GOP）はランタイムサービスを提供します。以下のグラフィックス機能のセクションも参照してください。オペレーティングシステムは、ランタイムモード中にGOPによって提供されるフレームバッファに直接書き込むことができます。^[52]

UEFIメモリマップサービス

SMMサービス

ACPIサービス

SMBIOSサービス

Devicetreeサービス (RISC プロセッサ用)

変動サービス

UEFI変数は、データ、特に不揮発性データを保存する方法を提供します。一部のUEFI変数は、プラットフォームファームウェアとオペレーティングシステム間で共有されます。変数の名前空間はGUIDによって識別され、変数はキーと値のペアです。たとえば、UEFI変数を使用すると、クラッシュ後にクラッシュメッセージをNVRAMに保存して、再起動後にオペレーティングシステムが取得することができます。^[53]

タイムサービス

UEFIは時間サービスを提供します。時間サービスには、タイムゾーンと夏時間フィールドのサポートが含まれており、ハードウェアリアルタイムクロックをローカルタイムまたはUTCに設定できます。^{[54] PC-ATリアルタイムクロックを使用するマシンでは、最新バージョンを使用し、} WindowsレジストリのエントリがUTCの使用を示すように設定されていない限り、デフォルトでは、BIOSベースのWindowsとの互換性のためにハードウェアクロックをローカルタイムに設定する必要があります。^[51]

UEFI は、OS をロードするだけでなく、EFI システム パーティションにファイルとして存在するUEFI アプリケーションを実行できます。これらは、UEFI シェル、ファームウェアのブート マネージャー、または他の UEFI アプリケーションから実行できます。UEFIアプリケーションは、 OEM ( Original Equipment Manufacturer )とは独立して開発およびインストールできます。

UEFI アプリケーションの一種に、GRUB、rEFInd、Gummiboot、Windows Boot Managerなどの OS ブートローダーがあります。これらは、一部の OS ファイルをメモリにロードして実行します。また、OS ブートローダーは、実行する別の UEFI アプリケーションを選択できるようにするユーザーインターフェイスを提供することもできます。UEFI Shell などのユーティリティも UEFI アプリケーションです。

EFI は、2 つのバイナリ モジュール間の通信に使用されるソフトウェア インターフェイスのセットとしてプロトコルを定義します。すべての EFI ドライバーは、プロトコルを介して他のドライバーにサービスを提供する必要があります。EFI プロトコルは、BIOS割り込み呼び出しに似ています。

標準の命令セットアーキテクチャ固有のデバイス ドライバーに加えて、 EFI は、 EFI バイト コード( EBC)として不揮発性メモリに保存されるISA に依存しないデバイス ドライバーを提供します。 システム ファームウェアには、EBC イメージのインタープリターがあります。 その意味で、 EBC は、 PowerPCベースのApple MacintoshやSun Microsystems SPARCコンピューターなど で使用されている ISA に依存しないファームウェアであるOpen Firmwareに類似しています。

一部のデバイス タイプ用のアーキテクチャ固有 (非 EFI バイト コード) の EFI ドライバーには、OS が使用するインターフェイスがあります。これにより、オペレーティング システム固有のドライバーがロードされる前、またはロードされた場合、OS は EFI を利用してドライバーが基本的なグラフィックス機能やネットワーク機能を実行できるようになります。

他のケースでは、EFIドライバは、他のタイプのディスクボリュームからの起動を可能にするファイルシステムドライバである可能性があります。例としては、 37ファイルシステム用のefifs （ GRUB2コードに基づく） ^[55]があり、RufusはNTFS ESPのチェーンロードに使用します。 ^[56]

EFI 1.0仕様では、グラフィックス機能をサポートする方法としてUGA（ユニバーサルグラフィックアダプタ）プロトコルが定義されていました。UEFIにはUGAが含まれず、GOP（グラフィックス出力プロトコル）に置き換えられました。^[57]

UEFI 2.1 では、ユーザー入力、ローカライズされた文字列、フォント、およびフォーム ( HTMLの意味) を管理するための「ヒューマン インターフェイス インフラストラクチャ」(HII) が定義されています。これにより、 OEM ( Original Equipment Manufacturer ) または独立系 BIOS ベンダー(IBV) は、プリブート構成用のグラフィカル インターフェイスを設計できます。UEFI は、デフォルトでUTF-16 を使用して文字列をエンコードします。

初期の UEFI ファームウェア実装のほとんどはコンソールベースでした。今日では、多くの UEFI ファームウェア実装は GUI ベースです。

EFI システム パーティション (略して ESP と呼ばれることが多い) は、UEFI 仕様に準拠したコンピュータで使用されるデータ ストレージ デバイスパーティションです。コンピュータの電源投入時に UEFI ファームウェアによってアクセスされ、オペレーティング システムのブート ローダーを含む、UEFI アプリケーションとこれらのアプリケーションの実行に必要なファイルが格納されます。サポートされているパーティション テーブルスキームには、MBRとGPT のほか、光ディスク上のEl Toritoボリュームがあります。 ^{[36] : セクション 2.6.2} ESP で使用するために、UEFI はFAT ファイル システムの特定のバージョンを定義します。これは、UEFI 仕様の一部として維持され、元の FAT 仕様とは独立しており、FAT32、FAT16、およびFAT12ファイル システムが含まれます。^{[36] : セクション 12.3  [58] [59] [60]} ESP は、BIOS の下位互換性の一部としてブート セクター用のスペースも提供します。^[49]

従来のPC BIOSとは異なり、UEFIはブートセクターに依存せず、代わりにUEFI仕様の一部としてブートマネージャーを定義します。コンピューターの電源がオンになると、ブートマネージャーはブート構成をチェックし、その設定に基づいて、指定されたOSブートローダーまたはオペレーティングシステムカーネル（通常はブートローダー^{[61] ）を実行します。ブート構成は、OSローダーまたはOSカーネルへのファイルシステムパスを示す変数を含む、} NVRAMに格納された変数によって定義されます。

OS ブートローダーは UEFI によって自動的に検出されるため、USB フラッシュドライブなどのリムーバブルデバイスから簡単に起動できます。この自動検出は、OS ブートローダーへの標準化されたファイルパスに依存しており、パスはコンピューターのアーキテクチャによって異なります。ファイルパスの形式は、<EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFIと定義されています。たとえば、x86-64システム上の OS ローダーへのファイルパスは\efi\boot\bootx64.efi、^[36]であり、ARM64 アーキテクチャでは \efi\boot\bootaa64.efiです。

GPTパーティションディスクからUEFIシステムを起動することを、一般的にUEFI-GPTブートと呼びます。UEFI仕様ではMBRパーティションテーブルを完全にサポートする必要があるにもかかわらず、^{[36]一部のUEFIファームウェア実装では、ブートディスクのパーティションテーブルの種類に応じてBIOSベースのCSMブートに即座に切り替わり、MBRパーティションディスク上の}EFIシステムパーティションからUEFIブートが実行されることを事実上防止します。^[49]このようなブートスキームは、一般的にUEFI-MBRと呼ばれます。

ブート マネージャーにはテキスト ユーザー インターフェイスが用意されているのも一般的で、ユーザーは利用可能なブート オプションのリストから目的の OS (またはセットアップ ユーティリティ) を選択できます。

下位互換性を確保するために、PCクラスのマシン上のUEFIファームウェア実装は、レガシーBIOS互換性を提供する互換性サポートモジュール（CSM）を介して、MBRパーティションディスクからのレガシーBIOSモードでの起動をサポートできます。このシナリオでは、パーティションテーブルを無視し、ブートセクターの内容に依存することで、レガシーBIOSベースのシステムと同じ方法で起動が実行されます。^[49]

MBR パーティション ディスクからの BIOS スタイルのブートは、UEFI または従来の BIOS ベースのシステムで実行されるかどうかに関係なく、一般にBIOS-MBRと呼ばれます。さらに、GPT ディスクから従来の BIOS ベースのシステムを起動することも可能であり、このようなブート スキームは一般にBIOS-GPTと呼ばれます。

互換性サポートモジュールにより、 UEFIをサポートしていないレガシーオペレーティングシステムや一部のレガシーオプションROMを引き続き使用できます。 ^[62]また、 UEFI SMMが提供する機能に加えて、 CompatibilitySmmと呼ばれる必要なレガシーシステム管理モード（SMM）機能も提供します。このようなレガシーSMM機能の一例として、従来のPS/2キーボードとマウスをエミュレートすることで、キーボードとマウスにUSBレガシーサポートを提供することが挙げられます。^[62]

2017年11月、インテルは2020年までにクライアントプラットフォーム向けCSMのサポートを段階的に廃止する計画を発表した。^[63]

2022年7月、カスペルスキー研究所は、インテルのH81チップセットと影響を受けるマザーボードの互換性サポートモジュールを搭載したマシン上で悪意のあるコードを連鎖的に起動するように設計されたルートキットに関する情報を公開しました。^[64]

2023年8月、インテルは2024年までにサーバープラットフォーム向けCSMのサポートを段階的に廃止する計画を発表した。^[65]

今日現在、^{[いつ? ]} Intel プラットフォームに基づくすべてのコンピューターは CSM をサポートしていません。^{[引用が必要]}

UEFI仕様には、Preboot eXecution Environment (PXE) を介したネットワーク経由のブートのサポートが含まれています。PXEブートネットワークプロトコルには、インターネットプロトコル( IPv4およびIPv6 )、ユーザーデータグラムプロトコル(UDP)、動的ホスト構成プロトコル(DHCP)、簡易ファイル転送プロトコル(TFTP)、iSCSIなどがあります。^{[36] [66]}

OSイメージは、SANにアクセスするためのプロトコルとしてインターネットスモールコンピュータシステムインターフェイス（iSCSI）とファイバーチャネルオーバーイーサネット（FCoE）を使用して、ストレージエリアネットワーク（SAN）にリモートで保存できます。 ^{[36] [67] [68]}

UEFI仕様のバージョン2.5では、HTTP経由でブートイメージにアクセスするためのサポートが追加されました。^[69]

UEFI 仕様では、セキュア ブートと呼ばれるプロトコルが定義されています。このプロトコルは、許容されるデジタル署名で署名されていない UEFI ドライバーまたは OS ブート ローダーの読み込みを防止することで、ブート プロセスを保護できます。これらのドライバーにどの程度正確に署名するかという機械的詳細は指定されていません。^[70]セキュア ブートを有効にすると、最初は「セットアップ」モードになり、「プラットフォーム キー」(PK) と呼ばれる公開キーをファームウェアに書き込むことができます。キーが書き込まれると、セキュア ブートは「ユーザー」モードになり、プラットフォーム キーで署名された UEFI ドライバーと OS ブート ローダーのみがファームウェアによって読み込まれます。メモリに保存されているデータベースに追加の「キー交換キー」(KEK) を追加して、他の証明書を使用できるようにすることができますが、それらの証明書はプラットフォーム キーの秘密部分に接続している必要があります。^[71]セキュア ブートは「カスタム」モードにすることもでき、秘密キーと一致しない追加の公開キーをシステムに追加できます。^[72]

セキュアブートは、Windows 8および8.1、Windows Server 2012および 2012 R2、Windows 10、Windows Server 2016、2019、2022、Windows 11、VMware vSphere 6.5 ^[73]および、Fedora (バージョン 18 以降)、openSUSE (バージョン 12.3 以降) 、 RHEL (バージョン 7 以降)、CentOS (バージョン 7 ^[74]以降)、Debian (バージョン 10 以降) ^[75] Ubuntu (バージョン 12.04.2 以降)、Linux Mint (バージョン 21.3 以降)、^{[76] [77]}およびAlmaLinux OS (バージョン 8.4 ^{[78]以降) を含む多数の Linux ディストリビューション}でサポートされています。2024 年 1 月現在、FreeBSD のサポートは計画段階にあります。^{[79] [アップデート]}

UEFIはシェル環境を提供しており、これを使用してUEFIブートローダなどの他のUEFIアプリケーションを実行できます。^[47]それ以外にも、UEFIシェルで使用できるコマンドを使用して、メモリマップの取得( memmap)、ブートマネージャ変数の変更( bcfg)、パーティションプログラムの実行( diskpart)、UEFIドライバのロード、テキストファイルの編集( )など、システムやファームウェアに関するさまざまな情報を取得できますedit。^{[80] [信頼できない情報源? ] [81] [82]}

UEFIシェルのソースコードは、 IntelのTianoCore UDK/EDK2プロジェクトからダウンロードできます。 ^[83]ビルド済みのShellBinPkgも利用可能です。^[84] Shell v2はUEFI 2.3+システムで最もよく動作し、それらのシステムではShell v1よりも推奨されます。Shell v1はすべてのUEFIシステムで動作するはずです。^{[80] [85] [86]}

UEFI シェルを起動する方法は、システムマザーボードの製造元とモデルによって異なります。そのうちのいくつかは、起動用のファームウェア セットアップで直接オプションを提供している場合があります<EFI_SYSTEM_PARTITION>/SHELLX64.EFI。たとえば、コンパイルされた x86-64 バージョンのシェルを として利用できるようにする必要があります。他のシステムには、適切なキーの組み合わせを押すことで起動できる UEFI シェルがすでに組み込まれています。^{[87] [信頼できない情報源? ] [88]}他のシステムの場合、解決策は、適切な USB フラッシュ ドライブを作成するか、bcfgコンパイルされたバージョンのシェルに関連付けられたブート オプションを手動で追加することです ( )。^{[82] [87] [89] [信頼できない情報源? ] [90] [信頼できない情報源? ]}

以下はEFIシェルでサポートされているコマンドの一覧です。 ^[81]

UEFI の拡張機能は、コンピューターに接続されているほぼすべての不揮発性ストレージ デバイスから読み込むことができます。たとえば、 OEM ( Original Equipment Manufacturer ) は、ハード ドライブ上にEFI システム パーティションを備えたシステムを配布できます。これにより、マザーボードのROMに保存されている標準の UEFI ファームウェアに追加機能が追加されます。

UEFIカプセルは、ファームウェアからOSへのファームウェア更新インターフェースを定義し、最新かつ安全であると宣伝されています。^[91] Windows 8、Windows 8.1、Windows 10、^{[92] Linux用の}FwupdはそれぞれUEFIカプセルをサポートしています。

BIOSと同様に、UEFIはシステムハードウェアコンポーネントを初期化してテストし（例：​​メモリトレーニング、PCIeリンクトレーニング、一般的なx86システムでのUSBリンクトレーニング）、次に大容量ストレージデバイスまたはネットワーク接続を介してブートローダをロードします。x86システムでは、UEFIファームウェアは通常、マザーボードのNORフラッシュチップに保存されます。 ^{[93] [94]一部のARMベースのAndroidデバイスでは、UEFIブートローダは}eUFSフラッシュメモリに保存されます。

UEFIマシンは、UEFIへの移行を容易にするために使用された以下のクラスのいずれかを持つことができます。^[95]

• クラス 0: レガシー BIOS
• クラス 1: CSM インターフェイスがあり、外部 UEFI インターフェイスがない UEFI。UEFI インターフェイスはファームウェア内部のみにあります。
• クラス 2: CSM と外部 UEFI インターフェイスを備えた UEFI (例: UEFI ブート)。
• クラス 3: CSM インターフェイスがなく、外部 UEFI インターフェイスを備えた UEFI。
• クラス3+: セキュアブートが有効になっているUEFIクラス3。^[96]

第 10 世代 Intel Core 以降、Intel はiGPU ( Intel Graphics Technology ) 用のレガシービデオ BIOS を提供しなくなりました。これらの CPU でのレガシー ブートにはレガシー ビデオ BIOS が必要ですが、これはビデオ カードによって引き続き提供されます。^{[引用が必要]}

これは UEFI ブートの最初のステージですが、その前にプラットフォーム固有のバイナリ コードが存在する場合があります (例: Intel ME、AMD PSP、CPUマイクロコード)。これは、特定のアーキテクチャ用にアセンブリ言語で記述された最小限のコードで構成されます。一時メモリ (多くの場合、CPU キャッシュ アズ RAM (CAR) または SoC オンチップ SRAM) を初期化し、ハンドオフ前に PEI を検証するオプションを備えたシステムのソフトウェア ルート オブ トラストとして機能します。

UEFI ブートの第 2 段階は、依存関係を認識するディスパッチャで構成され、PEI モジュール (PEIM) をロードして実行し、メイン メモリの初期化 (メモリ コントローラとDRAM の初期化) やファームウェア回復操作などの初期のハードウェア初期化タスクを処理します。さらに、現在のブート モードの検出と多くの ACPI S3 操作の処理も担当します。ACPI S3 再開の場合、多くのハードウェア レジスタをスリープ前の状態に復元する役割を担います。PEI は CAR も使用します。この段階での初期化には、メモリ内にデータ構造を作成し、これらの構造内に既定値を確立することが含まれます。^[97]

このステージはCモジュールと依存関係を考慮したディスパッチャで構成されています。メインメモリが利用可能になると、CPU、チップセット、マザーボード、その他のI/OデバイスがDXEとBDSで初期化されます。このステージでの初期化には、マザーボードに接続されたハードウェアにEFIデバイスパスを割り当て、構成データをハードウェアに転送することが含まれます。^[98]

BDSはDXEの一部です。^{[99] [100]}この段階では、ブートデバイスが初期化され、UEFIドライバまたはPCIデバイスのオプションROMがシステム構成に従って実行され、ブートオプションが処理されます。

これは、ブート デバイスの選択と OS への引き渡しの間の段階です。この時点で、UEFI シェルに入るか、OS ブート ローダーなどの UEFI アプリケーションを実行することができます。

ExitBootServices()が実行されると、UEFI はオペレーティングシステム(OS)に引き継ぎます。UEFI 互換の OS は、ブート サービスを終了してファームウェアをトリガーし、不要になったコードとデータをすべてアンロードして、SMMやACPIなどのランタイム サービス コード/データのみを残す責任を負います。^{[101] [検証失敗]一般的な最新の OS は、ハードウェア デバイスを制御するために独自のプログラム (}カーネル ドライバーなど) を使用することを好みます。

レガシー OS が使用されている場合、CSM はこの呼び出しを処理し、システムがレガシー BIOS の期待と互換性があることを確認します。

IntelのEFI実装はIntel Platform Innovation Frameworkで、コードネームはTianoです。TianoはIntelのXScale、Itanium、IA-32、x86-64プロセッサで動作し、プロプライエタリソフトウェアですが、コードの一部はBSDライセンスまたはEclipse Public License (EPL)の下でTianoCore EDK IIとしてリリースされています。TianoCoreはcorebootのペイロードとして使用できます。^[102]

Phoenix TechnologiesのUEFI実装は、SecureCore Technology (SCT)としてブランド化されています。^[103] American Megatrendsは、Aptioとして知られる独自のUEFIファームウェア実装を提供しています。^[104] Insyde SoftwareはInsydeH2Oを提供しています。^[105] ByosoftはByoCoreを提供しています。

2018年12月、マイクロソフトはSurfaceラインのTianoCore EDK2ベースのUEFI実装のオープンソース版であるProject Muをリリースした。^[106]

UEFI APIの実装は、2017年にユニバーサルブートローダー（Das U-Boot）に導入されました。 ^[107] ARMv8アーキテクチャのLinuxディストリビューションでは、ブートにGNU GRUBと組み合わせてU-Boot UEFI実装を使用しています（例：SUSE Linux ^[108]）。OpenBSDでも同様です。^[109] iSCSIからのブートには、U-BootによってロードされたUEFIアプリケーションとしてiPXEを使用できます。 ^[110]

2000 年にリリースされたIntelの最初のItaniumワークステーションとサーバーは、EFI 1.02 を実装しました。

2002 年にリリースされたHewlett-Packardの最初のItanium 2システムには EFI 1.10 が実装されており、Windows、Linux、FreeBSD、HP-UXを起動できました。OpenVMSは2003 年 6 月に UEFI 機能を追加しました。

2006年1月、アップル社は初のインテルベースのMacintoshコンピュータを出荷した。これらのシステムは、以前のPowerPCベースのシステムで使用されていたOpen Firmwareの代わりにEFIを使用した。 ^[111] 2006年4月5日、アップルは初めてBoot Campをリリースした。これは、Mac OS X（現在のmacOS）を再インストールせずにWindows XPまたはVistaをインストールできるようにするWindowsドライバディスクと非破壊パーティションツールを生成する。ファームウェアアップデートもリリースされ、EFI実装にBIOS互換性が追加された。その後のMacintoshモデルは、より新しいファームウェアで出荷された。^[112]

2005年には、100万台以上のIntelシステムがIntelのUEFI実装を搭載して出荷された。^{[113] [検証失敗]} IntelのUEFI実装を使用した新しいモバイル、デスクトップ、サーバー製品は、2006年に出荷が開始された。たとえば、Intel 945チップセットシリーズを使用するボードは、IntelのUEFIファームウェア実装を使用している。

2005年以降、EFIはXScaleコアをベースにした組み込みシステムなど、PC以外のアーキテクチャにも実装されるようになりました。^[113]

EDK (EFI 開発キット) には、Windowsアプリケーション内で EFI ファームウェアと EFI アプリケーションを実行できる NT32 ターゲットが含まれています。ただし、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ホワイトペーパーに記載されている。^[114]

2011年には、大手ベンダー（ ASRock、Asus、Gigabyte、MSIなど）が、UEFI対応のIntel 6シリーズ LGA 1155チップセットとAMD 9シリーズAM3+チップセットを搭載した消費者向けマザーボードをいくつか発売した。^[115]

2012年10月のWindows 8のリリースに伴い、マイクロソフトの認定要件では、コンピューターにUEFI仕様を実装したファームウェアが含まれていることが求められています。さらに、コンピューターがWindows 8の「コネクテッドスタンバイ」機能（デバイスがスマートフォンに匹敵する電源管理が可能になり、スタンバイモードからほぼ瞬時に復帰できる）をサポートしている場合、ファームウェアに互換性サポートモジュール（CSM）を含めることは許可されません。そのため、コネクテッドスタンバイをサポートするシステムは、レガシーBIOSオペレーティングシステムを起動できません。^{[116] [117]}

2017年10月、Intelは2020年までにすべての製品からレガシーPC BIOSのサポートを削除し、UEFIクラス3に移行すると発表しました。 ^[118] 2019年までに、Intelプラットフォームに基づくすべてのコンピューターは、レガシーPC BIOSのサポートを終了します。

(U)EFI から起動できるオペレーティングシステムは、(U)EFI 仕様で定義されている (U)EFI 対応オペレーティングシステムと呼ばれます。ここで、(U)EFI から起動するという用語は、任意のストレージデバイスに格納されている (U)EFI オペレーティングシステムローダーを使用してシステムを直接起動することを意味します。オペレーティングシステムローダーのデフォルトの場所は です<EFI_SYSTEM_PARTITION>/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI。ここで、マシンタイプの短縮名はIA32、X64、IA64、ARMまたはですAA64。^[36]一部のオペレーティングシステムベンダーは独自のブートローダーを持っている場合があります。また、デフォルトのブート場所を変更する場合もあります。

• Linuxカーネルは2000年代初頭から起動時にEFIを使用することができ、^[119] elilo EFIブートローダー、または最近ではGRUBのEFIバージョンを使用しています。^[120] Grub + Linuxは、UEFIなしでGUIDパーティションテーブルからの起動もサポートしています。^[18] Ubuntuディストリビューションは、バージョン12.10からUEFIセキュアブートのサポートを追加しました。^[121]さらに、Linuxカーネルは、EFIブートスタブ機能を通じて、単独でEFIブートローダーとして実行するオプションを使用してコンパイルできます。
• HP-UX は2002 年からIA-64システムのブート メカニズムとして (U)EFI を使用しています。
• OpenVMSは、2003年12月の最初の評価リリース以来、IA-64上でEFIを使用しており、2005年1月からは製品リリースでも使用しています。 ^[122] x86-64上のOpenVMSもオペレーティングシステムの起動にUEFIを使用しています。^[123]
• AppleはIntelベースのMacシリーズにEFIを採用している。Mac OS X v10.4 TigerとMac OS X v10.5 Leopardは、新しい64ビットCPUでも32ビットモードでEFI v1.10を実装しているが、OS X v10.8 Mountain Lionで完全サポートされた。^[124]
• Windows 2000の Itanium バージョン( Advanced Server Limited Edition および Datacenter Server Limited Edition。プレリリース版のWindows Server 2003コードベースに基づく) は、2002 年に EFI 1.10 を実装しました。Windows XP 64-bit Edition、Windows 2000 Advanced Server Limited Edition (プレリリース版の Windows Server 2003)、およびWindows Server 2003 for IA-64はすべて Intel Itaniumファミリのプロセッサ用であり、 DIG64仕様を通じてプラットフォームの要件である EFI を実装しています。^[125]
• マイクロソフトは、 Windows Vista SP1 ^[126]およびWindows Server 2008でx64 Windowsオペレーティングシステム用のUEFIを導入しましたが、サポートされているのはUGA (Universal Graphic Adapter) 1.1またはLegacy BIOS INT 10hのみで、Graphics Output Protocol (GOP)はサポートされていません。したがって、64ビットバージョンのWindows Vista SP1、Windows Vista SP2、Windows 7、Windows Server 2008、およびWindows Server 2008 R2を実行しているPCは、UEFI Class 2と互換性があります。^{[127] [128] 32ビットUEFIは当初サポートされていませんでした。これは、} 64ビットコンピューティングが主流であったため、ベンダーがネイティブの32ビットUEFIファームウェアを作成することに関心がなかったためです。^[129] Windows 8では最終的に、Graphics Output Protocol (GOP)のサポート、^[130]起動の高速化、32ビットUEFIのサポート、セキュアブートのサポートなど、UEFIシステムのさらなる最適化が導入されました。^{[131] [132]} Windows 8以降、 ACPIプロトコルを備えたUEFIファームウェアはARMベースのMicrosoft Windowsオペレーティングシステムの必須要件です。MicrosoftはWindows 11でWindowsを実行するためにUEFIを要求し始めましたが、^[133] Windows 11のIoT Enterpriseエディションのバージョン24H2以降ではこの要件が免除されています。^[134]
• 2013年3月5日、FreeBSD Foundationは、FreeBSDカーネルとブートローダにUEFIサポートを追加しようとしている開発者に助成金を授与しました。 ^[135]変更は当初、FreeBSDソースコードの個別のブランチに保存されていましたが、2014年4月4日にメインラインソースに統合されました（リビジョン264095）。変更にはインストーラのサポートも含まれます。^[136] amd64のUEFIブートサポートはFreeBSD 10.1で初めて登場し、arm64はFreeBSD 11.0で登場しました。^[137]
• Oracle Solaris 11.1以降では、UEFIファームウェアバージョン2.1以降を搭載したx86システムのUEFIブートをサポートしています。x86ではGRUB 2がブートローダーとして使用されます。^[138]
• OpenBSD 5.9 ^{[139] では、}独自のカスタムローダーを使用して64ビットx86システムのUEFIブートサポートが導入され、OpenBSD 6.0ではそのサポートがARMv7に拡張されました。^[140]
• ArcaOSは5.1リリース以降、UEFIブートをサポートしています。^[141] ArcaOSのUEFIサポートは、オペレーティングシステムが依存する特定のBIOS機能（特に割り込みINT 10HとINT 13H）をエミュレートします。^{[142] [143]}

• HP Integrity Virtual Machines は、HP Integrity サーバー上で UEFI ブートを提供します。また、ゲスト UEFI 対応 OS 用の仮想化された UEFI 環境も提供します。
• IntelはSourceForgeでOpen Virtual Machine Firmwareプロジェクトをホストしています。^[144]
• Mac OS X 用のVMware Fusion 3 ソフトウェアは、UEFI を使用して Mac OS X Server 仮想マシンを起動できます。
• VMware Workstationバージョン 11 より前は非公式に UEFI をサポートしていますが、.vmx ファイルを編集して手動で有効にすることができます。^[145] VMware Workstationバージョン 11 以降は、物理ホスト システムが UEFI ベースであるかどうかに関係なく、UEFI をサポートしています。VMware Workstation 14 (および Fusion 10) では、UEFI のセキュア ブート機能のサポートが追加されています。^{[146] [147]}
• VMware ESXi 5.0ハイパーバイザーはUEFIを正式 にサポートしています。バージョン6.5ではセキュアブートのサポートが追加されました。^{[148] [149]}
• VirtualBoxは3.1以降UEFIを実装しているが^[150] 、 Unix/LinuxオペレーティングシステムとWindows 8以降に限定されている（Windows Vista x64およびWindows 7 x64では動作しない）。^{[151] [152]}
• QEMU / KVMはTianoCoreが提供するOpen Virtual Machine Firmware (OVMF)で使用できます。^[153]
• Microsoft Hyper-V仮想マシンの第2世代は仮想化UEFIをサポートしています。^[154]
• Google Cloud Platform Shielded VMは仮想化UEFIをサポートし、セキュアブートを可能にします。^[155]

EDK2アプリケーション開発キット（EADK）は、UEFIアプリケーションで標準Cライブラリ関数を使用することを可能にします。EADKは、 IntelのTianoCore UDK / EDK2 SourceForgeプロジェクトから無料でダウンロードできます。例として、 EADKを使用することで、 PythonインタープリターのポートがUEFIアプリケーションとして利用可能になります。^[156] UDK2015以降、開発はGitHubに移行しました。^[157]

EADK を使用して記述された最小限の「hello, world 」C プログラムは、通常の C のプログラムと似ています。

#include <Uefi.h> #include <Library/UefiLib.h> #include <Library/ShellCEntryLib.h> 
 
 

EFI_STATUS EFIAPI ShellAppMain ( IN UINTN Argc , IN CHAR16 ** Argv ) { Print ( L "hello, world \n " ); return EFI_SUCCESS ; }       

    
     

多くのデジタル権利活動家がUEFIに抗議している。corebootの共著者であるロナルド・G・ミンニッチとデジタル権利活動家のコリー・ドクトロウは、UEFIはユーザーがコンピューターを実際に制御する能力を奪おうとする試みだと批判している。^{[158] [159]}ほとんどのハードウェアに対してファームウェア用とオペレーティングシステム用の2つの異なるドライバーを必要とするというBIOSの長年の課題は解決されない。^[160]

オープンソースプロジェクトTianoCoreもUEFIを提供しています。^[161] TianoCoreにはチップセット機能を初期化する専用ドライバーがありませんが、代わりにcorebootによって提供され、TianoCoreはその多くのペイロードオプションの1つです。corebootの開発には、初期化ドライバーの開発に必要な仕様を提供するためにチップセットメーカーの協力が必要です。

2011年、マイクロソフトは、Windows 8オペレーティングシステムを実行することが認定されたコンピューターは、マイクロソフトの公開キーが登録され、セキュアブートが有効になっている状態で出荷する必要があると発表しました。これは、UEFIの使用がこれらのデバイスの要件であることを意味します。^{[162] [163]}この発表の後、同社は、UEFIのセキュアブート機能を使用して、Linuxなどの代替オペレーティングシステムのインストールを妨害または完全に防止しようとしているとして、批評家やフリーソフトウェア/オープンソース支持者（フリーソフトウェア財団を含む）から非難されました。マイクロソフトは、セキュアブートの要件がロックインの一形態として機能することを意図していたことを否定し、Windows 8の認定を受けたx86ベースのシステムでは、セキュアブートをカスタムモードにするか無効にする必要があるが、 ARMアーキテクチャを使用するシステムではそうではないと述べて、その要件を明確にしました。^{[72] [164]} Windows 10では、 OEMがx86システムのユーザーがセキュアブートを管理できるかどうかを決定できます。^[165]

他の開発者は、Linux システム全般にセキュア ブートのサポートを実装することに関する法的および実際的な問題について懸念を表明した。元Red Hat開発者のMatthew Garrett は、 GNU 一般公衆利用許諾書バージョン 3の条件により、ディストリビューションの開発者が秘密鍵を公開しない限り、GNU GRand Unified Bootloaderを使用できない可能性がある(ただし、 Free Software Foundation はその後、鍵を公開する責任はハードウェア製造元にあると明確にし、立場を明確にした) と指摘した。 ^{[166] [121]}また、上級ユーザーが自己署名せずにセキュア ブートを有効にして機能するカスタムカーネルを構築することも難しいだろう。 ^[164]他の開発者は、別の鍵で署名された Linux ビルドを提供できると提案したが、Microsoft の鍵と一緒に必要な鍵をコンピュータに同梱するよう OEM を説得するのは難しいだろうと指摘した。^[5]

いくつかの主要なLinuxディストリビューションは、セキュアブートの異なる実装を開発してきました。ギャレット自身が開発した最小限のブートローダはshimと呼ばれ、これはプリコンパイルされた署名済みのブートローダで、ユーザーがLinuxディストリビューションによって提供されるキーを個別に信頼できるようにします。^[167] Ubuntu 12.10は、 Canonical独自のキーで使用するために事前構成された古いバージョンのshim ^{[ which? ]}を使用しています。これはブートローダのみを検証し、署名されていないカーネルのロードを許可します。信頼されたカーネルはユーザー空間のみを保護するのに効果的であり、セキュアブートが保護を追加するように設計されているプリブート状態を保護するのには効果的ではないため、開発者はブートローダのみに署名する慣行の方が実現可能であると信じていました。これにより、ユーザーはシステムを再構成することなく、独自のカーネルを構築し、カスタムカーネルモジュールを使用することもできます。^{[121] [168] [169]} Canonicalは、Ubuntuがプリロードされた認定OEMコンピュータにインストールされたオペレーティングシステムに署名するための独自の秘密鍵も保持しており、セキュアブート要件も強制する予定です。つまり、CanonicalキーとMicrosoftキー（互換性のため）の両方をファームウェアに含める必要があります。Fedoraもshimを使用していますが、^{[どちらですか？ ]}カーネルとそのモジュールの両方に署名する必要があります。^[168]

オペレーティングシステムのカーネルとそのモジュールも署名する必要があるかどうかについては議論がある。UEFI仕様では要求されていないが、マイクロソフトは契約上の要件では要求されており、システムのセキュリティを侵害する可能性のあるコードの署名に使用された証明書を取り消す権利を留保していると主張している。^[169] Windowsでは、セキュアブートが有効になっている場合、すべてのカーネルドライバーはデジタル署名されている必要があり、WHQL以外のドライバーは読み込みを拒否される場合があります。2013年2月、別のRed Hat開発者が、Microsoftが署名したPEファイルに埋め込まれたマスターX.509キーを使用してMicrosoftのAuthenticode署名を解析できるようにするLinuxカーネルへのパッチを提出しようとした。しかし、この提案はLinuxの作成者であるLinus Torvaldsによって批判され、Red Hatはセキュアブートインフラストラクチャに対するMicrosoftの制御を支持していると非難された。^[170]

2013年3月26日、スペインのフリーソフトウェア開発グループHispalinuxは、OEMシステムに対するMicrosoftのセキュアブート要件が「妨害的」かつ反競争的であると主張し、欧州委員会に正式な苦情を申し立てた。^[171]

2013年8月のブラックハットカンファレンスでは、セキュリティ研究者のグループが、セキュアブートを悪用するために使用できるUEFIの特定ベンダー実装における一連のエクスプロイトを発表しました。^[172]

2016 年 8 月、2 人のセキュリティ研究者が、Microsoft がオペレーティング システムの署名に使用しているセキュリティ キー「ゴールデン キー」を発見したと報告されました。^[173]技術的には、キーは公開されていませんが、キーで署名された悪用可能なバイナリは公開されています。これにより、任意のソフトウェアが Microsoft によって真に署名されているかのように実行され、ルートキットやブートキットの攻撃を受ける可能性があります。また、この脆弱性を修正することは不可能です。なぜなら、任意のパッチが (署名された) 悪用可能なバイナリに置き換えられる (ダウングレードされる) 可能性があるからです。Microsoft は声明で、この脆弱性はARM アーキテクチャとWindows RTデバイスにのみ存在すると回答し、2 つのパッチをリリースしました。ただし、このパッチでは脆弱性は削除されません (削除できません)。この脆弱性を修正するには、エンド ユーザーのファームウェアでキーを置き換える必要があります。^[要出典]

2023年3月1日、ESETサイバーセキュリティファームの研究者は、公開分析結果の中で「UEFIセキュアブートを回避する最初のUEFIブートキット」を報告し、「脆弱性を除去しない（除去できない）」パッチを悪用するメカニズムの背後にある理論を説明しました。^{[174] [175]}

2024年8月、Windows 11およびWindows 10のセキュリティ更新プログラムにより、デバイスのUEFI NVRAMにSecure Boot Advanced Targeting（SBAT）設定が適用され、一部のLinuxディストリビューションの読み込みに失敗する可能性があります。SBATは、Windows Boot Managerとshimの新しいバージョンでサポートされているプロトコルで、バグや脆弱性のある中間ブートローダ（通常はwinload.efiとGRUB）がブートプロセスで読み込まれることを拒否します。^[176]

現在、RHEL（RHEL 7以降）、CentOS（CentOS 7以降^[177]）、Ubuntu、Fedora、Debian（Debian 10以降^[178]）、OpenSUSE、SUSE Linuxなど、多くのLinuxディストリビューションがUEFIセキュアブートをサポートしています。^[179]

デバイスにおけるUEFIファームウェアの重要性が増すにつれ、それぞれの実装に起因する多くの技術的な問題も発生しています。^[180]

2012年後半のWindows 8のリリース後、セキュアブートを搭載した一部のLenovoコンピュータモデルに、他の設定に関係なく「 Windows Boot Manager」または「Red Hat Enterprise Linux 」という名前の実行ファイルのみをロードするようにハードコードされたファームウェアが搭載されていることが判明しました。[181] また、セキュアブートを搭載したいくつかの東芝ラップトップモデルでは、適切な動作に必要な特定の証明書が欠落しているという問題が発生しました。 [ ^{180 ]}

2013 年 1 月、一部のSamsungラップトップの UEFI 実装に関するバグが公表され、UEFI モードで Linux ディストリビューションをインストールした後に、それらのラップトップが動作しなくなった。当初は、Samsung ラップトップのシステム機能にアクセスするために設計されたカーネル モジュールとの潜在的な競合が原因とされたが (カーネルのメンテナーは安全対策として UEFI システムでモジュールを無効にするよう促された)、Matthew Garrett は、このバグは実際にはメモリに UEFI 変数を大量に保存することで発生し、特定の条件下では Windows でもこのバグが発生する可能性があることを発見した。結論として、彼は問題のカーネル モジュールによってカーネル メッセージ ダンプがファームウェアに書き込まれ、バグが発生したと判断した。^{[53] [182] [183]}

• ブートローダー
• オープンBIOS
• UEFI プラットフォーム初期化(UEFI PI)
• ACPI (高度な構成と電源インターフェイス)
• システム管理 BIOS (SMBIOS)
• トラステッド プラットフォーム モジュール(TPM)
• UEFIツール
• ムーンバウンス
• UEFI シェル用 Python インタープリター