Unified Extensible Firmware Interface

ウィキペディアから無料の百科事典

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

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

UEFIを採用したSystem BIOSは「UEFI BIOS」と呼ばれ、単に「UEFI」と略されることが多いが、ユーザーがアクセスし設定などを行うGUIはUEFIであっても「BIOS」と呼ばれる事が多い。UEFI BIOSはIBM PC互換機に採用された古いSystem BIOSのよりセキュアな置き換えを意図している[1]。遠隔診断やOSがロードされていない状態での修復なども可能とする[2]。「BIOS（バイオス）」とは異なり、「UEFI」の読みは特に定められていない。

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

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

歴史[編集]

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

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仕様は同フォーラムが所有している[6][10]。

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

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

詳細[編集]

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

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

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

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

ディスクのサポート[編集]

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

プロセッサのサポート[編集]

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

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

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に似ている。これはハードウェアに依存しないファームウェアで、PowerPCベースのAppleのMacintoshやサン・マイクロシステムズのSPARCコンピュータなどの間で採用された。

いくつかのアーキテクチャに特化した（非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セキュアブートは、起動対象のオペレーティングシステムの電子署名を検証して正当なソフトウェアであることが確認できた場合にのみブート処理を継続する[19]。

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

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

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

EFIシェル[編集]

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

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

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

拡張機能[編集]

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

ハードウェア[編集]

BIOSと同様に、UEFIはシステムハードウェアを初期化してテストし、大容量記憶装置またはネットワークブートからブートローダーをロードする。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）[27]やInsyde Software[28]、Phoenix Technologies[29]など、独立した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万台以上インテルのボードがこのフレームワークを搭載して出荷されている[30]。新型のモバイルやデスクトップ、サーバ製品ではこのフレームワークを用いて2006年に出荷が開始されている。すぐにすべてのIntel 945チップセットを採用しているボードはこのフレームワークを搭載することになるだろう。しかし、製品用のファームウェアはEFIをサポートせず、レガシーSystem BIOSに限定している。

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

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

仮想化[編集]

  • HP Integrity Virtual Machines（英語版） では、HP IntegrityサーバでのUEFIブートを提供する。UEFI-awareのゲストOSのための仮想UEFI環境も提供する。
  • インテルでは、Sourceforge上でOpen Virtual Machine Firmwareプロジェクトを主催している[44]。
  • Mac OS X向けのVMware Fusionは、EFIを使って、Mac OS X Serverの仮想マシンをブートできる。
  • VirtualBox は3.1からUEFIを実装しているが[45]、レガシーBIOSからUEFIへの移行期に開発されたOSの起動に必要となるCSMが実装されていないため、対応OSはUnix/Linux系またはWindows 8以降のx86-64版に限られている（Vistaや7のx64版はUEFI対応不可）[46][47]。
  • 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チップセットを使ったマザーボード[48]で、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用ドライバはIntel 製の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への準拠が義務づけることが告知された。

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

以上の事情から、コンシューマ市場では、2016 年夏以降にUFEIやTPMについて注意が払われるようになり、広く一般のユーザが認知するようになったのはWindows 7のサポート期限切れである2020年1月前後を期としたものであったと言える。

グラフィックス機能[編集]

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

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について、ユーザーが自身のコンピュータを真に制御する能力を阻害することで知的所有権を守ろうとする試みだとして批判している[50][51]。EFIは、BIOS最大の懸案事項である、ファームウェア用とOS用に別々のドライバが必要だという点を全く解決していない[52]。

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

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

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

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

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

脚注[編集]

[脚注の使い方]
  1. ^ a b “MS denies secure boot will exclude Linux”. The Register (2011年9月23日). 2011年9月24日閲覧。
  2. ^ Sandro Villinger (2011年7月19日). “The 30-year-long Reign of BIOS is Over: Why UEFI W... - Input Output”. ヒューレット・パッカード. 2013年6月26日時点のオリジナルよりアーカイブ。2012年3月6日閲覧。
  3. ^ “Overview”. UEFI Forum. 2017年4月26日閲覧。 “One typical implementation is done in high-level C programming language, which is fundamentally different than the Legacy BIOS by encouraging the use of modern software practices.”
  4. ^ ROM内のコードによるマシン初期化手順、ディスクパーティション、OSのブートに繋げる手順、等
  5. ^ 新規アーキテクチャであり、またその高機能に由来する高コストに加え、開発コストの回収の必要から当初は高価格の商品となるため、エンタープライズが当初の（結果としてはその後も）Itaniumのターゲットであった。
  6. ^ a b c d “Emulex UEFI Implementation Delivers Industry-leading Features for IBM Systems” (PDF). Emulex. 2010年9月14日閲覧。[リンク切れ]
  7. ^ “Extensible Firmware Interface (EFI) and Unified EFI (UEFI)”. Intel. 2010年1月5日時点のオリジナルよりアーカイブ。2012年3月17日閲覧。
  8. ^ Wei, Dong (2006), “foreword”, Beyond BIOS, Intel Press, ISBN 978-0-9743649-0-2 
  9. ^ “Extensible Firmware Interface”. Intel. 2012年3月17日閲覧。
  10. ^ “Overview”. Unified EFI Forum. 2012年3月18日閲覧。 “Q: What is the relationship between EFI and UEFI? A: The UEFI specification will be based on the EFI 1.10 specification published by Intel with corrections and changes managed by the Unified EFI Forum. Intel still holds the copyright on the EFI 1.10 specification, but has contributed it to the Forum so that the Forum can evolve it. There will not be any future versions of the EFI specification, but customers who license it can still use it under the terms of their license from Intel. The license to the Unified EFI Specification will come from the Forum, not from Intel”
  11. ^ UEFI Today: Bootstrapping the Continuum, Intel Press, http://www.intel.com/technology/itj/2011/v15i1/index.htm 
  12. ^ “UEFI and Windows”. Microsoft (2009年9月15日). 2010年9月14日閲覧。
  13. ^ GUIDパーティションテーブルを使う場合のみ
  14. ^ a b “FAQ: Drive Partition Limits” (PDF). UEFI Forum. 2010年6月9日閲覧。
  15. ^ Bill Boswell (2002年7月1日). “FAQ: Drive Partition Limits”. Redmond Mag. 2010年6月9日閲覧。 “GPT disks also support very large partitions thanks to a 64-bit Logical Block Address scheme. A logical block corresponds to one sector, or 512 bytes, yielding a maximum theoretical capacity of eight zettabytes.”
  16. ^ Ben Hardwidge (2010年6月1日). “LBA explained — Solving the 3TB Problem?”. bit-tech. 2010年6月18日閲覧。
  17. ^ Brian Richardson (2010年5月10日). “Ask a BIOS Guy: "Why UEFI"”. Intel Architecture Blog. 2010年6月18日閲覧。
  18. ^ Gary Simpson. “UEFI Momentum — The AMD perspective” (PPTX). AMD. 2010年6月18日閲覧。
  19. ^ “Secure Boot Overview”. Microsoft. 2016年2月18日閲覧。
  20. ^ http://download.microsoft.com/download/A/D/F/ADF5BEDE-C0FB-4CC0-A3E1-B38093F50BA1/windows8-hardware-cert-requirements-system.pdf
  21. ^ “Microsoft confirms UEFI fears, locks down ARM devices - SFLC Blog - Software Freedom Law Center”. Softwarefreedom.org (2012年1月12日). 2012年3月6日閲覧。
  22. ^ a b Windows 10搭載PCにはLinuxなどをインストールできなくなる可能性あり - GIGAZINE
  23. ^ Matthew Garrett (2012年5月30日). “Implementing UEFI Secure Boot in Fedora” (英語). mjg59. 2019年10月21日閲覧。
  24. ^ Steve Langasek (22 June 2012). "UEFI Secure Boot and Ubuntu - implementation". ubuntu-devel (Mailing list) (英語). 2019年10月21日閲覧。
  25. ^ “SecureBoot - FreeBSD Wiki”. FreeBSD. 2016年11月24日閲覧。
  26. ^ Efi-shell.tianocore.org for EFI shell information
  27. ^ “Aptio®: The Complete UEFI Product Solution” (PDF). American Megatrends, Inc. 2011年1月8日閲覧。
  28. ^ “InsydeH2O Our Flagship BIOS”. Insyde Software Corp. 2011 -01-08閲覧。
  29. ^ “SecureCore Tiano™”. Phoenix Technologies, LTD. 2010年9月14日閲覧。
  30. ^ a b “Intel® Platform Innovation Framework for UEFI Overview”. Intel. 2010年9月14日閲覧。
  31. ^ “Evaluating UEFI using Commercially Available Platforms and Solutions” (PDF). UEFI (2011‐5). 2012年3月18日閲覧。
  32. ^ http://fedoraproject.org/wiki/Features/EFI
  33. ^ [1] ELILO: EFI Linux Boot Loader
  34. ^ “Linux_3.3 1.10. EFI boot support” (英語). Linux Kernel Newbies. 2020年7月19日閲覧。
  35. ^ “The EFI Boot Stub” (英語). The Linux Kernel documentation. 2020年7月19日閲覧。
  36. ^ OpenVMS Release History, HP, http://h71000.www7.hp.com/openvms/os/openvms-release-history.html 2008年9月16日閲覧。 
  37. ^ “Intelプロセッサ搭載Macのブートプロセス”. Apple Support. 2022年8月16日閲覧。 “iBootはT2チップ上でカーネルとカーネル拡張機能のコードを確認してから、Intel UEFIファームウェアを確認します。”
  38. ^ “Unified Extended Firmware Interface support in Windows Vista”. Microsoft (2006年10月26日). 2010年6月12日閲覧。 “Microsoft determined that vendors would not have any interest in producing native UEFI 32-bit firmware because of the current status of mainstream 64-bit computing and platform costs. Therefore, Microsoft has chosen not to ship support for 32-bit UEFI implementations.”
  39. ^ “Windows オペレーティング システムでの UEFI のサポートと要件”. Microsoft (2013年4月2日). 2013年8月10日閲覧。 “ARM and 32-bit PCs (Windows 8 only).”
  40. ^ “UEFI と Windows”. Microsoft (2013年4月26日). 2013年8月10日閲覧。 “Windows 8 supports UEFI 2.3.1 or later 32-bit and ARM-based systems.”
  41. ^ “MS Developers Network Channel 9”. Microsoft. 2012年3月18日閲覧。
  42. ^ a b Jon Brodkin (2011年9月21日). “Windows 8 secure boot could complicate Linux installs”. Arstechnica. 2011年9月23日閲覧。
  43. ^ a b Denis Wong (2011年9月22日). “Microsoft clarifies Windows 8 UEFI concerns”. Neowin.net. 2011年9月23日閲覧。
  44. ^ “Open Virtual Machine Firmware”. SourceForge. 2012年3月18日閲覧。
  45. ^ “3.1 Changelog”. VirtualBox. 2012年3月18日閲覧。
  46. ^ “Ticket 7702”. VirtualBox. 2012年3月18日閲覧。
  47. ^ “Forum”. VirtualBox. 2012年3月18日閲覧。
  48. ^ Asus P67 Motherboard Preview
  49. ^ Intel shows PC booting Windows with UEFI firmware
  50. ^ “Interview: Ronald G Minnich”. Fosdem (2007年2月6日). 2010年9月14日閲覧。
  51. ^ Cory Doctorow. “The Coming War on General Purpose Computation”. 2012年3月18日閲覧。
  52. ^ “coreboot (aka LinuxBIOS): The Free/Open-Source x86 Firmware”. YouTube (2008年10月31日). 2010年9月14日閲覧。
  53. ^ “Welcome”, TianoCore, SourceForge, http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome 2012年3月18日閲覧。 
  54. ^ Risks, UK: NCL, http://catless.ncl.ac.uk/Risks/26.18.html#subj13 
  55. ^ Garrett, Matthew. “UEFI secure booting”. 2011年9月20日閲覧。
  56. ^ “Protecting the pre-OS Environment with UEFI”. Microsoft (2011年9月22日). 2011年9月24日閲覧。
  57. ^ Gay, Josh. “Will your computer's "Secure Boot" turn out to be "Restricted Boot"?”. www.fsf.org. Free Software Foundation. 2011年10月25日閲覧。
  58. ^ “Stand up for your freedom to install free software”. www.fsf.org. Free Software Foundation. 2011年10月25日閲覧。

関連項目[編集]

外部リンク[編集]

「https://ja.wikipedia.org/w/index.php?title=Unified_Extensible_Firmware_Interface&oldid=98923626」から取得