Unified Extensible Firmware Interface





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


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


UEFIを採用したSystem BIOSは「UEFI BIOS」と呼ばれるが、単に「UEFI」と略されることが多い。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]。




目次






  • 1 歴史


  • 2 詳細


    • 2.1 ディスクのサポート


    • 2.2 プロセッサのサポート


    • 2.3 ブートサービス


    • 2.4 プロトコル


    • 2.5 デバイスドライバ


    • 2.6 ブートマネージャー


    • 2.7 セキュアブート


    • 2.8 EFIシェル


    • 2.9 拡張機能




  • 3 実装と採用実績


    • 3.1 Intel Platform Innovation Framework for EFI


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


    • 3.3 オペレーティングシステム（OS）


    • 3.4 仮想化


    • 3.5 コンシューマ市場




  • 4 グラフィックス機能


  • 5 批判


  • 6 脚注


  • 7 関連項目


  • 8 外部リンク





歴史


そもそも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 5150の設計に基づいているため、16ビット・プロセッサモードと1MBのアドレス空間という制限があった[6][16]。一方、UEFIのプロセッサモードは32ビット（x86-32、ARM）または64ビット（x86-64、Itanium）である[6][17]。64ビットのUEFIではロングモードも可能であり、ブート前の環境で64ビットアドレッシングの全メモリに直接アクセス可能である[18]。


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アプリケーションになる）。この場合、ブートセクタを使用せずに済むが、最初にロードすべき標準で定められた名前のファイルを、特殊なパーティションテーブルから参照できるようにしておく必要がある（ファイル名の例：EFIBOOTboot[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から）などのLinuxディストリビューションは、この署名サービスによって署名された軽量ブートローダを用いることでセキュアブートに対応している。セキュアブートへの対応を計画しているFreeBSDもマイクロソフトの署名サービスを利用する計画である[23]。



EFIシェル


EFIコミュニティはオープンソースなシェル環境を作った[24]。これはちゃんとした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パーティションを作って、そのシステムを販売することができる。



実装と採用実績



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


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


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 のホワイトペーパーに採用例が挙げられている[29]。Sandy Bridge PC プラットフォームの多くはUEFIを採用している。



オペレーティングシステム（OS）


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




  • Linuxは2000年初期からeliloというEFIブートローダを使って、EFIを使って起動することができる。以前では、eliloやGRUB[30]はIA-64プラットフォーム上でLinuxを単に起動できるだけであり、x86-64とIA32プラットフォームでも同じことが可能である[31]。現在ではGRUB2のEFI版もある。


  • HP-UXは2002年からIA-64システム上で(U)EFIを使ったブート機構を使用していた。

  • HP OpenVMS の IA-64 版は2003年12月の最初の評価版リリースから(U)EFIを使っている。製品版は2005年1月からリリースされている[32]。


  • マイクロソフトのIA-64用のWindows Server 2003、Windows XP 64bit Edition、Windows Advanced Server, Limited EditionはすべてEFIをサポートしており、DIG64仕様を通じてプラットフォームの要件となっている。

  • アップルは、Macにインテルアーキテクチャを初めて採用した2006年1月以降、一貫してEFIを採用している。

  • マイクロソフトはWindows Server 2008のx64版でUEFIに対応した。Windows Vistaのx64版では、2008年3月19日にWindows Update及びダウンロードセンターで配布が開始されたSP1でEFIに対応した。当初マイクロソフトは市場の関心が64ビットへ向いていることなどを理由に32ビットWindowsへのUEFI実装を行わなかったが[33]、Windows 8の32ビット版ではSecure Bootと共にUEFIへと対応している[34][35]。マイクロソフトは、Andrew RitzとJamie SchwarzがWindows VistaとWindows Server 2008上でUEFIを用いてOS起動前の処理を説明するビデオをリリースした[36]。

  • マイクロソフトは、自作パソコン向けに単体販売されるマザーボードを含むコンピュータ本体に "Designed for Windows 8" のロゴを付ける条件として、UEFIでセキュアブート（英語版）をデフォルトで有効にすることを要求している[37][38]。レッドハットの開発者マシュー・ギャレットはセキュアブートをデフォルトで有効にするという要求に懸念を表明したが、マイクロソフトはそれに対して自身がそれを命令したことはないし、ファームウェア内で後から無効にすることを妨げるつもりもないと応じた[37][38]。



仮想化




  • HP Integrity Virtual Machines（英語版） では、HP IntegrityサーバでのUEFIブートを提供する。UEFI-awareのゲストOSのための仮想UEFI環境も提供する。

  • インテルでは、Sourceforge上でOpen Virtual Machine Firmwareプロジェクトを主催している[39]。

  • Mac OS X向けのVMware Fusion（英語版）は、EFIを使って、Mac OS X Serverの仮想マシンをブートできる。


  • VirtualBox は3.1からUEFIを実装しているが[40]、レガシーBIOSからUEFIへの移行期に開発されたOSの起動に必要となるCSMが実装されていないため、対応OSはUnix/Linux系またはWindows 8以降のx86-64版に限られている（Vistaや7のx64版はUEFI対応不可）[41][42]。


  • QEMU/KVMはEFIと共に利用可能である。


  • VMware vSphereの一部であるVMware ESXi version 5 hypervisorは仮想マシン内のBIOSの代替として仮想化EFIをサポートしている。

  • VMware Workstation 11以降ではEFIを使用した仮想マシンの起動をサポートしている。

  • VMware Workstation 14以降ではSecureBootを使用した仮想マシンの起動をサポートしている。


  • Hyper-Vの第二世代仮想マシンはUEFIをサポートする。



コンシューマ市場


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



グラフィックス機能


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


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


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


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


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


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



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




脚注


[ヘルプ]



  1. ^ ab“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. ^ abcd“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. ^ ab“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. ^ abWindows 10搭載PCにはLinuxなどをインストールできなくなる可能性あり - GIGAZINE


  23. ^ “SecureBoot - FreeBSD Wiki”. FreeBSD. 2016年11月24日閲覧。


  24. ^ Efi-shell.tianocore.org for EFI shell information


  25. ^ “Aptio®: The Complete UEFI Product Solution (PDF)”. American Megatrends, Inc. 2011年1月8日閲覧。


  26. ^ “InsydeH2O Our Flagship BIOS”. Insyde Software Corp. 2011 -01-08閲覧。


  27. ^ “SecureCore Tiano™”. Phoenix Technologies, LTD. 2010年9月14日閲覧。

  28. ^ ab“Intel® Platform Innovation Framework for UEFI Overview”. Intel. 2010年9月14日閲覧。


  29. ^ “Evaluating UEFI using Commercially Available Platforms and Solutions (PDF)”. UEFI (2011‐5). 2012年3月18日閲覧。


  30. ^ http://fedoraproject.org/wiki/Features/EFI


  31. ^ [1] ELILO: EFI Linux Boot Loader


  32. ^ OpenVMS Release History, HP, http://h71000.www7.hp.com/openvms/os/openvms-release-history.html 2008年9月16日閲覧。 


  33. ^ “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.”


  34. ^ “Windows オペレーティング システムでの UEFI のサポートと要件”. Microsoft (2013年4月2日). 2013年8月10日閲覧。 “ARM and 32-bit PCs (Windows 8 only).”


  35. ^ “UEFI と Windows”. Microsoft (2013年4月26日). 2013年8月10日閲覧。 “Windows 8 supports UEFI 2.3.1 or later 32-bit and ARM-based systems.”


  36. ^ “MS Developers Network Channel 9”. Microsoft. 2012年3月18日閲覧。

  37. ^ abJon Brodkin (2011年9月21日). “Windows 8 secure boot could complicate Linux installs”. Arstechnica. 2011年9月23日閲覧。

  38. ^ abDenis Wong (2011年9月22日). “Microsoft clarifies Windows 8 UEFI concerns”. Neowin.net. 2011年9月23日閲覧。


  39. ^ “Open Virtual Machine Firmware”. SourceForge. 2012年3月18日閲覧。


  40. ^ “3.1 Changelog”. VirtualBox. 2012年3月18日閲覧。


  41. ^ “Ticket 7702”. VirtualBox. 2012年3月18日閲覧。


  42. ^ “Forum”. VirtualBox. 2012年3月18日閲覧。


  43. ^ Asus P67 Motherboard Preview, .


  44. ^ Intel shows PC booting Windows with UEFI firmware


  45. ^ “Interview: Ronald G Minnich”. Fosdem (2007年2月6日). 2010年9月14日閲覧。


  46. ^ Cory Doctorow. “The Coming War on General Purpose Computation”. 2012年3月18日閲覧。


  47. ^ “coreboot (aka LinuxBIOS): The Free/Open-Source x86 Firmware”. YouTube (2008年10月31日). 2010年9月14日閲覧。


  48. ^ “Welcome”, TianoCore, SourceForge, http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome 2012年3月18日閲覧。 


  49. ^ Risks, UK: NCL, http://catless.ncl.ac.uk/Risks/26.18.html#subj13 


  50. ^ Garrett, Matthew. “UEFI secure booting”. 2011年9月20日閲覧。


  51. ^ “Protecting the pre-OS Environment with UEFI”. Microsoft (2011年9月22日). 2011年9月24日閲覧。


  52. ^ Gay, Josh. “Will your computer's "Secure Boot" turn out to be "Restricted Boot"?”. www.fsf.org. Free Software Foundation. 2011年10月25日閲覧。


  53. ^ “Stand up for your freedom to install free software”. www.fsf.org. Free Software Foundation. 2011年10月25日閲覧。




関連項目



  • オープンシステム


  • 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 と Windows


  • EFI Architecture Dr. Dobbs Portal Article

  • de Boyne Pollard, Jonathan (2006年). “The EFI boot process”. Frequently Given Answers. 2012年3月18日閲覧。

  • de Boyne Pollard, Jonathan (2006年). “The Windows NT 6 boot process”. Frequently Given Answers. 2012年3月18日閲覧。

  • Will your computer's "Secure Boot" turn out to be "Restricted Boot"?


  • Intel Technology Journal, Volume 15, Issue 01 - "UEFI Today: Bootstrapping the Continuum" (PDF)

  • 2020年、ついにIntelのx86でDOSが動作しなくなる～UEFIからレガシーBIOS互換を削除(2017年11月17日)




-

Popular posts from this blog

CARDNET

Image
CARDNET は日本カードネットワークが運営するクレジット決済ネットワーク。日本カードネットワークの略称としてもCARDNETが使用されている。 事件・事故 2017年4月15日午前11時8分からクレジットカードの決済がしづらくなる障害が発生した。障害は同日午後5時18分に復旧した。原因は、複数あるCARDNETセンターの拠点のうち1つで、2重化してあるL3スイッチの片方が故障し、1系統にトラフィックが集中したことによる輻輳が発生したため。対処としては、故障したL3スイッチ交換とシステム再起動が行われた [1] 。 出典 ^ 金子寛人 ( 2017年4月17日 ). “CARDNETのクレジット決済に6時間強障害、原因はL3スイッチ故障”. 日経コンピュータ. 2018年10月18日 閲覧。 この項目は、コンピュータに関連した 書きかけの項目 です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。 この項目は、経済に関連した 書きかけの項目 です。この項目を加筆・訂正などしてくださる協力者を求めています（ポータル 経済学、プロジェクト 経済）。 This page is only for reference, If you need detailed information, please check here
Read more

Boot-repair Failure: Unable to locate package grub-common:i386

Image
0 I am on a system dual-booting Windows and Debian (usually using the latter), and a recent Windows update appears to have wreaked havoc on the Debian boot system. I managed to boot Windows again, but not Linux. Following online suggestions, I created a Live USB of Ubuntu, and booted from that. Then I have installed and run the boot-repair utility. The utility instructs me to type several lines including sudo chroot "/mnt/boot-sav/sda6" apt-get purge -y grub*-common grub-common:i386 To which I receive the error E: Unable to locate package grub-common:i386 I am given to understand the issue may have to do with having UEFI vs BIOS (I believe I have UEFI), but do not understand this well. In any case I have subsequently run the boot-repair BootInfo Summary utility which created the following file h...
Read more

濃尾地震

Image
濃尾地震 『岐阜市街大地震之図』 歌川国利画 本震 発生日 1891年（明治24年）10月28日 発生時刻 6時38分50秒（JST） 震央 日本 岐阜県本巣郡西根尾村（現・本巣市） 北緯35度35分 東経136度20分（ 地図 ） 規模    マグニチュード（M）8.0 最大震度    震度7： 注1 福井県今立郡鯖江町、愛知県葉栗郡大田島村、東春日井郡勝川村 地震の種類 直下型地震 被害 死傷者数 死者7,273人、負傷者17,175人 注1：当時の震度階級では「激烈」 プロジェクト:地球科学 プロジェクト:災害 テンプレートを表示 濃尾地震 （のうびじしん）は、1891年（明治24年）10月28日に濃尾地方で発生した、日本史上最大の内陸地殻内地震。「 美濃・尾張地震 （みの・おわりじしん）」とも呼ばれている。辛卯の年に発生したことから 辛卯震災 と呼んでいる報告書もある。 目次 1 概要 1.1 震源断層 2 被害 3 各地の震度 4 前兆現象 5 報道 6 学術的な意義 7 地震防災 8 脚注 9 関連項目 10 外部リンク 概要 濃尾地震発生当時の根尾谷断層 濃尾地震を引き起こした根尾谷断層 写真中央を斜めに走る段差が根尾谷断層 濃尾地震は、1891年10月28日6時38分50秒に発生した。震源は、岐阜県本巣郡西根尾村（現・本巣市）、北緯35度35分、東経136度20分付近。河角廣 (1951) は岐阜市付近（北緯35.6度、東経136.6度）に震央を仮定し規模 M K = 7.0 を与え [1] 、マグニチュードは M = 8.4 に換算されているが、明治・大正期の地震については0.5程度大きく見積もられているとされる [2] 。また、震央距離と震度との関係など当時のデータから後にM8.0 [3] とも推定される。アメリカ地質調査所 (USGS) でも8.0としている [4] 。「根尾谷断層帯」が活動した典型的な内陸地殻内地震（いわゆる直下型地震）であり、これは記録が残っている日本の内陸...
Read more