Unified Extensible Firmware Interface

**Unified Extensible Firmware Interface**（ユニファイド・エクステンシブル・ファームウェア・インタフェース、頭字語: **UEFI**）はオペレーティングシステム（OS）とプラットフォームファームウェアとの間のソフトウェアインタフェースを定義する仕様である。

UEFIの元となる **EFI** (**Extensible Firmware Interface**) 仕様は元々インテルとヒューレットパッカードによって開発された。2005年、EFI 1.10に基づいてUEFIへと発展した。UEFI仕様は業界団体Unified EFI Forumの下で開発されている。UEFI BIOSはIBM PC互換機に採用された古いSystem BIOSのよりセキュアな置き換えを意図している。遠隔診断やOSがロードされていない状態での修復なども可能とする。

UEFI自体は単なる「インタフェースの仕様」であるため、特定のプロセッサに依存しない。これまでのBIOSとは異なり、近代的なソフトウェア開発手法を用いることが推奨されており、C言語で実装したものなどが代表的である。

## 呼称の揺れ
UEFIを採用したSystem BIOSは「UEFI BIOS」と呼ばれ、単に「UEFI」と略されることが多いが、ユーザーがアクセスし設定などを行うGUIはUEFIであっても、PC/AT互換機のアーキテクチャに照らし、原義どおりに依然「BIOS」と呼ばれることも多い。「BIOS（バイオス）」とは異なり、「UEFI」に定着したカタカナ読み（片仮名への音声転写）はない。

## 歴史
そもそもEFIが開発された動機は、1990年代中盤のインテルとヒューレットパッカードによる初代Itanium機の開発初期にまでさかのぼる。IBM PC由来のSystem BIOSなどの制限（16ビットプロセッサモード、1MBのアドレス空間、PC/ATハードウェアへの依存など）によって、従来の各種スキームはItaniumの（当初の）ターゲットである巨大なサーバプラットフォームには採用できなかった。その課題に対する最初の成果が、1998年に**Intel Boot Initiative**と呼ばれ、後にEFIと名前を変えた。

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

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

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

2007年1月7日、UEFI仕様バージョン2.1がリリースされた。暗号化の改善、ネットワーク認証、ユーザインタフェースのアーキテクチャ（UEFI中にある対人インタフェース）が追加されている。2026年2月18日時点の最新版は、2024年12月に発表されたバージョン2.11である。

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

2017年、インテルは2020年までに Compatibility Support Module (CSM) を廃止する意向を発表した。CSM は Legacy BIOS の互換機能を提供していた。

## 詳細

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

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

従来のSystem BIOSに対する強化点としては、ACPIやSMBIOSがすでにEFIの中にあるため、16ビットで動作するインタフェースに依存せずに使用できることが挙げられる。

### ディスクのサポート
レガシーなMBRパーティションテーブルに加えて、EFIではGUIDパーティションテーブル（GPT）をサポートしている。これによりPCでのディスクパーティションの容量の限界と領域の数の制限は拡張され、同じ時期に開発された2TB以上のシリアルATA接続の内蔵ハードディスクからの起動がサポートされた。GPTでのディスクとパーティションの最大サイズは9.4ZB（273バイト）である。EFI規格ではファイルシステムには言及していないが、UEFI規格ではFAT12、FAT16、FAT32のサポートを必須としている。

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

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

UEFIでは、基本的に、ファームウェアとOSのアドレス空間が一致していなければならない。たとえば、64ビットのUEFIからは64ビットのOSしかブートできない。

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

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

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

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

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

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

また、特定のハードウェアやオペレーティングシステムに依存しないように、UEFIアプリケーションのバイナリコードの記述には、マイクロソフトが開発した、ハードウェアやOSに依存しないバイナリフォーマットであるPortable Executable（PE）フォーマットを用いることが定められている。

### セキュアブート
UEFIセキュアブートは、起動対象のオペレーティングシステムの電子署名を検証して正当なソフトウェアであることが確認できた場合にのみブート処理を継続する。

WindowsマークのあるマシンではセキュアブートにMicrosoftの電子署名が使われており、Windows 8以降はセキュアブート電子署名が付与されている。一方で、Windows 7以前のオペレーティングシステムやほとんどのLinuxディストリビューションは電子署名が付与されていないため、セキュアブートが有効なUEFIブートローダーでは起動できない。

マイクロソフトがリリースしたWindows 8 OEM製品のハードウェア認定に関する文書によれば、x86およびx86-64を採用した全デバイスはセキュアなUEFIを有効にしなければならないが、カスタム・セキュアブート・モードでユーザーがシグネチャを追加できる手段を提供すると記述されている。一方、Windowsの動作するARMデバイスでは、セキュアブートを無効にできる実装を禁止しているため、カスタム・セキュアブート・モードへの移行もセキュアブートの無効化も不可能である。Windows 10のハードウェア認定要件ではセキュアブートの無効化手段の提供はオプションとなった。

マイクロソフトは、実費でマイクロソフトの鍵によって署名を行うサービスを提供している。Fedora、openSUSE、Ubuntu、RHEL（RHEL 7から）、CentOS（CentOS 7から）、Debian（Debian 10から）などのLinuxディストリビューションは、この署名サービスによって署名された軽量ブートローダを用いることでセキュアブート（の鍵配布と鍵インストールに纏わる問題）に対応している。セキュアブートへの対応を計画しているFreeBSDもマイクロソフトの署名サービスを利用する計画である。

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

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

EFIシェルにはスクリプトファイルの機能があり、拡張子には .nsh を使う。バッチファイルに似ており、コマンドにはUnixまたはDOSのコマンドに類似したものがある。

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

### ハードウェア
BIOSと同様に、UEFIはシステムハードウェアを初期化してテストし（Power On Self Test）、大容量記憶装置またはネットワークブートからブートローダーをロードする。x86システムでは、UEFIファームウェアは通常マザーボードのNORフラッシュチップに格納される。

## 実装と採用実績
### Intel Platform Innovation Framework for EFI
Intel Platform Innovation Framework for EFI（元々*Tiano*というコードネームで呼ばれていた）はEFIサポートを含み、完全でレガシーフリーなファームウェア実装である。これは、**Compatibility Support Module**（CSM）と呼ばれるものを通してレガシーなSystem BIOSのサポートが可能である。

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

インテルはこのフレームワークを完全な形でエンドユーザーに提供しているわけではない。アメリカンメガトレンド（AMI）やInsyde Software、Phoenix Technologiesなど、独立した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万台以上インテルのボードがこのフレームワークを搭載して出荷されている。新型のモバイルやデスクトップ、サーバ製品ではこのフレームワークを用いて2006年に出荷が開始されている。すぐにすべてのIntel 945チップセットを採用しているボードはこのフレームワークを搭載することになるだろう。しかし、製品用のファームウェアはEFIをサポートせず、レガシーSystem BIOSに限定している。

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

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などがある。

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

組み込みシステムやシングルボードコンピュータ向けのファームウェアであるDas U-Bootは、2018年頃までにEFI APIを実装し、EFIアプリケーションの実行をサポートした。

### オペレーティングシステム
(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やGRUBはIA-64プラットフォーム上でLinuxを単に起動できるだけであり、x86-64とIA32プラットフォームでも同じことが可能である。現在ではGRUB2のEFI版もある。Linux 3.3より、カーネルイメージ自体をEFIアプリケーションにして、ブートローダーを使用せずにブート可能にする機能が追加された。この機能はEFI ブートスタブ (EFI Boot Stub)と呼ばれる。
* HP-UXは2002年からIA-64システム上で(U)EFIを使ったブート機構を使用していた。
* HP OpenVMS の IA-64 版は2003年12月の最初の評価版リリースから(U)EFIを使っている。製品版は2005年1月からリリースされている。
* マイクロソフトのIA-64用のWindows Server 2003、Windows XP 64bit Edition、Windows Advanced Server, Limited EditionはすべてEFIをサポートしており、DIG64仕様を通じてプラットフォームの要件となっている。
* アップルは、Intel MacでUEFIを採用している。
* マイクロソフトはWindows Server 2008のx64版でUEFIに対応した。Windows Vistaのx64版では、2008年3月19日にWindows Update及びダウンロードセンターで配布が開始されたSP1でEFIに対応した。当初マイクロソフトは市場の関心が64ビットへ向いていることなどを理由に32ビットWindowsへのUEFI実装を行わなかったが、Windows 8の32ビット版ではSecure Bootと共にUEFIへと対応している。マイクロソフトは、Andrew RitzとJamie SchwarzがWindows VistaとWindows Server 2008上でUEFIを用いてOS起動前の処理を説明するビデオをリリースした。
* マイクロソフトは、自作パソコン向けに単体販売されるマザーボードを含むコンピュータ本体に "Designed for Windows 8" のロゴを付ける条件として、UEFIでをデフォルトで有効にすることを要求している。レッドハットの開発者マシュー・ギャレットはセキュアブートをデフォルトで有効にするという要求に懸念を表明したが、マイクロソフトはそれに対して自身がそれを命令したことはないし、ファームウェア内で後から無効にすることを妨げるつもりもないと応じた。

### 仮想化
*  では、HP IntegrityサーバでのUEFIブートを提供する。UEFI-awareのゲストOSのための仮想UEFI環境も提供する。
* インテルでは、Sourceforge上でOpen Virtual Machine Firmwareプロジェクトを主催している。
* Mac OS X向けのVMware Fusionは、EFIを使って、Mac OS X Serverの仮想マシンをブートできる。
* VirtualBox は3.1からUEFIを実装しているが、レガシーBIOSからUEFIへの移行期に開発されたOSの起動に必要となるCSMが実装されていないため、対応OSはUnix/Linux系またはWindows 8以降のx86-64版に限られている（Vistaや7のx64版はUEFI対応不可）。
* QEMU/KVMはOVMFと共に利用可能である。
* VMware vSphereの一部であるVMware ESXi 5は仮想マシン内のBIOSの代替として仮想化EFIをサポートしている。
* VMware Workstation 11以降ではEFIを使用した仮想マシンの起動をサポートしている。
* VMware Workstation 14以降ではSecure Bootを使用した仮想マシンの起動をサポートしている。
* Hyper-Vの第二世代仮想マシンはUEFIをサポートする。

### コンシューマ市場での普及と世間での認知
自作パソコンやBTOパソコン市場で大きなシェアを持つマザーボードメーカーのASRock、ASUSTeK、GIGABYTE、MSI 、BIOSTARなどは、2011年1月発売のインテル製6-series（搭載の主力はLGA 1155チップセットのSandy BridgeマイクロアーキテクチャCPU）やAMDの 9 seriesチップセットを使ったマザーボードで、UEFIとレガシーBIOSを（CSM モードも付けた上で）優先順位付けて併用可能な実装をし、UEFIの採用・実装をした商品の発売を開始してWindows 8対応に備え始めた（但しこの頃のマザーボードではTPM（Trusted Platform Module）チップ用のソケット実装はあったものの、あらかじめ実装されていたものは少なく、TPMチップは別売りでバージョンはTPM1.xに対応する製品であった）。

更に、2012年4月発売のインテル製Intel 7 Series（搭載の主力はLGA 1155チップセットのIvy BridgeマイクロアーキテクチャCPU）でもUEFIとレガシーBIOSを（CSM モードも付けた上で）優先順位付けて併用可能な実装を踏襲してWindows 8, Windows 8.1, Windows 10に以降・対応可能であるマザーボードの供給を進めた（この頃のマザーボードでもTPMチップ用のソケット実装はあったものの、あらかじめ実装されていたものは少なく、TPMチップは別売りでバージョンはTPM2.0に対応する製品であった）。

Windows 10用ドライバはインテル製のCPUは2011年1月から生産された第2世代CoreプロセッサであるSandy Bridgeマイクロアーキテクチャ以前のハードウェアに対する提供を終了し、ビデオカードメーカーもGPUドライバを提供しなくなった。

更に2016年8月末から生産を開始したIntel 100 Series第7世代Intel CoreプロセッサKaby Lakeマイクロアーキテクチャについて、マイクロソフトは2016年1月15日にWindows 7, 8, 8.1には対応せず、Windows 10のみである旨の声明を出し、同年4月には、2016 年7月28 日以降、Windows 10 では（一部の例外としてTPM 1.2を許容するものの）原則的にはTPM 2.0への準拠が義務づけることが告知された。

このためインテル製のCPUでWindows 10を稼働させるためにはUEFIに対応し、かつ、TPM 2.0チップを実装したマザーボード上で、2012年4月から生産された第3世代のIvy Bridgeマイクロアーキテクチャ以降のCPUを搭載していなければ、事実上、動作しない。Windows 7, 8.1, 10のいずれをも動作させられるインテル製のCPUは（公式には）
Ivy Bridge, HaswellとHaswell Refresh, Broadwell, Skylakeに限られることになる（当然、各マザーボードの仕様、特にUFEIの実装状況、TPMチップ実装の有無、TPMのバージョン、CSM モードの有無、使用するOSがx64かx86か、それに応じた各種デバイスドライバの提供が継続されているか、などに左右される）。

## グラフィックス機能
AMI AptioのUEFI実装では、メニューなどにグラフィックス要素が使われている。

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

## 批判

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

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

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

レッドハットの開発者マシュー・ギャレットは記事「UEFI secure booting」で、UEFIのセキュアブートがLinuxに影響を与えるかもしれないという懸念を表明した（Windows 8 のロゴをつけたマシンでは、セキュアブートが有効化された状態で出荷され、キーコードのないLinuxではブートできない）。これに対してマイクロソフトは、顧客がセキュアブートを後から無効にすることは可能だと応じた。しかし、指定以外のOSをインストールできなくすることでユーザーサポートにかかるコストを削減したいと考えている一部のハードウェアベンダーがセキュアブートを無効にできない実装のファームウェアを搭載した機器を販売し始めるのではないかという懸念が残っている。

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


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


## 脚注

### 注釈

### 出典

## 関連項目
* オープンシステム
* Advanced Configuration and Power Interface (ACPI)
* Basic Input/Output System (BIOS)
* ブート
* Coreboot
* プログラム仕様
* Open Firmware
* SMBIOS
* システムマネジメントモード (SMM)
* Unified EFI Forum
* Trusted Platform Module (TPM)

## 外部リンク

* UEFI FORUM 
* Intel's EFI page 
* ブートおよび UEFI
* EFI Architecture Dr. Dobbs Portal Article
* 
* 
* Will your computer's "Secure Boot" turn out to be "Restricted Boot"?
* 
* 2020年、ついにIntelのx86でDOSが動作しなくなる～UEFIからレガシーBIOS互換を削除(2017年11月17日)