UEFIについて
一、
昨年秋にPCを組んで、X79のマザーボードにi7-3930Kを載せ、Windows7 Professional SP1 x64をインストールすることにした。初めてのUEFIであった。
UEFIについては、従来のBIOSをグラフィカルにし、マウスでも操作できるように改良したものといった程度の理解であった。UEFIの概略する知らなかった。
そのような認識のまま、いつものようにセットアップを進めた。SSD2台をRAID0としてWindowsを入れてみたが、Trimが機能しないなどSSDでRAIDを組む不都合を考えて、一旦RAIDを解き、AHCIに変更してSSD1台にWindowsを入れ直すことにした。この時、何らかの手違いがあったようで、Boot Manager（Bootmgr）やBoot Configuration Database（BCD）といったファイルが、意図しない別のHDDにインストールされたしまい、面倒なことになってしまった。その際、UEFIの基本的な知識がないためにうろたえてしまった。
OSのインストール時には、やはり、安全を考慮して関係のないHDDやSSDは接続しない方がよいようである。
とはいえ、UEFIの大要を改めて確認することにした。
二、
UEFIの本家であるUnified EFI Forumのサイトを覗いてみる。
FAQsの「UEFIとは何か」に対して、「UEFI (Unified Extensible Firmware Interface) とは、プリブート環境（すなわち、システムに電源を入れた後、OSが始動する前の環境）のためのシステム・コントロールをWindowsやLinuxといったOSに手渡すことを手助けするインターフェイスを詳細に規定する仕様をいう。UEFIはOSと起動時のプラットフォーム・ファームウェアとの十全なインターフェイスを提供し、アドインカードを初期化するためのアーキテクチャに依存しないメカニズムをサポートするものである。」と回答されている。
当初、EFIはIntelが開発していたものだが、その統一規格化及び普及を図るべく、Intel、Microsoft、HP、IBM、American Megatrends Inc.、Phoenix Technologies等の11社が中心となってUnified EFI Forumを組織し、現在140を超える企業がそれに参加していると言う。
それでは、「BIOSとは何か」ということになるが、その前にそもそも「ファームウェアとは何ぞや」ということになる。
MSDNのウェブページからダウンロードできる【※ このページはTechNetの"UEFI Firmware"というページにリダイレクトされるようになり、そこから下のホワイトペーパーはダウンロードできなくなった。】MicrosoftのDownload Center内のhttp://download.microsoft.com/download/D/2/E/D2E64B38-5F38-459C-A8BA-88CA43E0D0CF/UEFI-Windows-8.docxからダウンロードできる"UEFI and Windows"（June 13, 2012）と題されたホワイトペーパーは、ファームウェアの概念から説き起こす。
【※ いつのまにかこのリンクも断たれており、2012年版の"UEFI and Windows"はダウンロードできなくなっている。しかし、なぜか元の2009年版はここからダウンロードできるようになっている。
http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/uefi_windows.docx
このリンクは、"BASIC INPUT/OUTPUT"というブログで知ったものである。（2016.12.20）】
ファームウェアについては、こう説明されている。
「あらゆるPCはファームウェアによってプリロードされる。ファームウェアとは、上位のソフトウェアからの命令に対してハードウェアの反応を指示するハードウェア特有のコードをいう。ファームウェアは、通常、マザーボードのようなハードウェアというディバイスに直接付属する不揮発性のストレージ内に組み込まれている。特に、ファームウェアは、通常、プログラム可能なread-only memory（PROM）又は電気的に消去可能なPROM（EEPROM)又はフラッシュ・メモリ内に保存されている。しかし、ファームウェアは、ビデオカードやストレージ・コントローラといった任意のディバイス・ハードウェア上にも存在する。
ファームウェアはブート・プロセスの間に実行される最初の指示を与える。ファームウェアは、ハードウェアの検出とシステムの初期化を終了した後、OSのboot loaderのようなブート・アプリケーションあるいはOSがロードされる前に実行されるツール（時として、プリOSツールと呼ばれる）にコントロールを渡すのである。
BIOSやUEFIはファームウェアの例である。PCは通常そのいずれか一方を使うのである。」と。
BIOSについては、改めて、
「BIOSというファームウェアは1970年代に初期のPCのために開発されたものである。BIOSは今なお最も流布しているファームウェアであるが、BIOSは、それが16bitプロセッサ・モードと1MBのアドレス指定可能なメモリ領域だけをサポートしているに過ぎないので、いよいよ制約されたものとなっている。共通するBIOSの規格が存在せず、BIOSの実装がベンダーごとにまちまちになりうることから、BIOSシステム上に新たなハードウェアのためにサポートを追加することも、比較的複雑になっている。」と説明されている。
これに対してUEFIは、と言うと、
「BIOSと対照的にUEFIは、インターフェイスとデータ構造のための標準の構文と意味を持った一まとまりのブート・サービス及びランタイム・サービスを定義するものである。これは、すべてのUEFIの実装が、本質的には同じように動作するとともに、標準規格のドライバやアプリケーションを検証したり、開発することを可能にすることを意味する。これは、相互運用性を大いに高め、新たなハードウェアをサポートすることに伴う複雑さを軽減し、コンピュータ・メーカーがファームウェアをより迅速に更新し、整備・維持することに役立つことになる。」
続けて、UEFIの利点が6つ挙げられている。
「従来のBIOSとの互換性
現行のUEFIの実装のほとんどは、従来のBIOSをエミュレートするCompatibility Support Module （CSM） を内蔵している。したがって、UEFIファームウェアを備えるシステムは、UEFIを考慮したOSあるいはBIOSのみをサポートした古いOSのどちらも起動することができる。この機能が末端の利用者に柔軟性と互換性を提供する。
大容量ディスクのサポート
BIOSシステムはmaster boot record（MBR）というパーティショニング方式を用いるディスクをサポートする。この方式は、ディスクの最大容量を約2.2TBに、プライマリー・パーティションを最大4つに制限する。UEFIはGUID Partition Table（GPT）と呼ばれるより柔軟なパーティショニング方式をサポートする。GPTディスクはパーティションを記述するのに64bit値を使用する。この方式によれば、ディスクの最大容量は約1680万TB（※）、プライマリー・パーティションの数は最大128個まで可能となる。
CPUに依存しないアーキテクチャ
BIOSは32bit及び64bitのOSを実行することができるが、初期のブート段階の間は、BIOSは"real mode"と呼ばれる16bitインターフェイスに依拠する。このインターフェイスは初期のIntel x86プロセッサ・アーキテクチャに基づくものである。BIOS上のすべてのファームウェア・ディバイス・ドライバ（RAIDコントローラといったような）も16bitでなければならない。この条件は、初期のブート段階でアドレス指定可能なメモリを64KBに制限し、結果的にパフォーマンスを圧迫することになる。
UEFIはどのCPUのアーキテクチャにも依存しない。それは、最新の32bit及び64bitのファームウェア・ディバイス・ドライバをサポートすることができる。その64bitの機能によって、システムが初期のブート段階から172億GB（16EB：筆者註）以上のメモリにアドレスを指定することが可能となる。
CPUに依存しないドライバ
BIOSシステム上では、Peripheral Component Interconnect（PCI）のアドオンカードは、サポートするすべてのCPUアーキテクチャのために個別のドライバを保持しておく容量の大きなROMを内蔵しなければならない。そうでなければ、カード・ベンダーはそれぞれのプロセッサ・アーキテクチャごとに製品を揃え、在庫を管理しなければならないことになる。
UEFI仕様に適合するすべてのUEFIの実装は、EFI Byte Code（EBC）というインタプリタ（逐次解釈しながら実行するプログラムのこと：筆者注）を含んでいる。EBCイメージはすべてのプロセッサ・アーキテクチャと互換性のあるドライバである。これによってディバイス・ドライバとアプリケーションの開発者はどのシステムでも実行できる一つのEBCイメージを作り出すことが可能となる。EBCイメージは非常にコンパクトで公汎な適合性があるので、PCIカードのファームウェア・ドライバ（別名、オプションROMとも）は、BIOSシステムの場合のものよりも非常に小さくすることができ、それらは多様な市場に対応できることになる。これは、コストと混乱を軽減することに役立ち、システム・ベンダーが必要に応じてドライバを更新し、入れ替えることをさらに容易にすることになる。
柔軟性のあるプリOS環境
UEFIドライバ及びアプリケーションはブート環境でほとんど制約なしに実行される。例えば、UEFIは高解像度のグラフィックスに加えて完全なネットワークのプロトコル・スタックを提供することができ、動作可能なOSが利用できない場合であっても、すべてのディバイスにアクセスできる。
UEFIは柔軟なプリOSのプログラミング環境をサポートすることから、UEFIアプリケーションはどんなタイプのPCハードウェアに対しても広く多様なタスクを実行することができる。例えば、UEFIアプリケーションは診断とファームウェアのアップグレードを実行することができ、あるいはOSを修復して技術者に知らせることができ、あるいは認証のために遠隔のサーバに接続することができるのである。
モジュールの設計
BIOSの実装は構成された特定のハードウェアのために細心の注意を払ってカスタマイズしなければならない。緻密に組み合わされたコンポーネントは、往々にしてわずかな変更であっても広範囲にわたる影響を生じてしまいがちである。新たなハードウェアやプロトコルの導入は通常BIOSファームウェアの重要な部分の書き換えを要求する。これでは、コストと時間がかかる。
UEFIはハードウェアないしソフトウェアのインターフェイスの細かな点を意図的にまとめて一般化するモジュールのコンポーネントや汎用のインターフェイスを規定している。このアプローチによって、ファームウェア・ベンダーは、新たなハードウェアやプロトコルを導入すること、バグを修正すること、あるいは残りのシステムへの影響を最小限に抑えながら特定のコンポーネントの動作を改変することが可能となる。」
三、
それでは、UEFIは起動時にどのような働きをするのであろうか。「Windows Internals Sixth Edition」（Mark Russinovich他、Microsoft Press)には、UEFIのブート・プロセスについてもう少し詳しく説明されている。
「UEFI準拠システムはWindowsのセットアップによってシステムの不揮発性RAM（NVRAM）にプログラムされたboot loader codeを実行するファームウェアを有している。boot codeはBCD（Boot Configuration Database）の内容を読み込むが、それもまたNVRAMに保存されている。前述した（Part2のp.503以下で説明されている：筆者注）Bcdedit.exeツールは、このメカニズムがまったくユーザに知られずに処理されることを考慮して、BCDにあるファームウェアのNVRAMの変更可能な部分を抜き出す機能も備えている。
UEFI標準規格には、ロードするOS又は追加のアプリケーションを選択するために使うことができるEFI Boot Managerを使用するようユーザに促す機能が定義されている。しかし、BIOSシステムとUEFIシステムとの一貫したユーザ・インターフェイスを提供するべく、WindowsはEFI Boot Managerを選択するために2秒のタイムアウトを設定している。その後、EFIヴァージョンのBootmgr（Bootmgfw.efi）が替わりにロードされることになる。
次に、ハードウェアの検出が行われる。そこでは、boot loaderは、以下のディバイスの数とタイプを判定するために、UEFIというインターフェイスを使用するのである。
■ ネットワーク・アダプタ
■ ビデオ・アダプタ
■ キーボード
■ ディスク・コントローラ
■ ストレージ・ディバイス
UEFIシステム上では、全ての操作やプログラムはページングを有効にしたネイティブCPUモードで実行され、Windowsのブート・プロセスのどの部分も16bitモードで実行されることはない。EFIは32bitと64bitのいずれのシステムにおいてもサポートされているけれど、Windowsは64bitのプラットフォームにおいてのみEFIのためのサポートを提供していることに注意する必要がある（【追記】：Windows 8、8.1、10等では、32bitのプラットフォームにおいてもEFIをサポートするようになった）。
Bootmgrがx86あるいはx64システムで行うのと同じように、EFI Boot Managerは任意のタイムアウトでブート選択のメニューを表示する。ブート選択が行われると、ローダはその選択に応じてEFIシステム・パーティションのサブディレクトリに進み、EFIヴァージョンのWindows boot loader（Winload.efi）をロードする。
UEFIの仕様は、FATというファイル・システムでフォーマットされ、サイズが100MBから1GBの間であるか又はディスク・サイズの1％以下である、EFIシステム・パーティションとして指定されたパーティションを、システムが持つことを要求する。そして、インストールされた各WindowsはEFIシステム・パーティションの[EFI\Microsoft]の下にサブディレクトリを有する。
統一されたブート・プロセスとWindowsの現行のモデルのおかげで、表13-1（ Part2のp.500にあるBIOS Boot Process Componentsの一覧表：筆者注）に示されるコンポーネントは、「.exe」で終わるものが「.efi」で終わることを除いては、ほとんど同じようにUEFIシステムに適用される。そして、それらコンポーネントはBIOSの割込みの替わりにEFIのAPIとサービスを使用する。もう一つの違いは、MBRというパーティション・フォーマットの制約（1ディスクにつき最大4つのパーティションであるということを含む）を避けるため、UEFIシステムは、GPT（GUID Partition Table）フォーマットを使うということである。」（pp.512-513, Part2）
※ マザーボードのNVRAM内に格納されるBCD情報は、ドライブのEFIシステム・パーティション内にも保存される。EFIパーティション内のBCD情報は、OSがインストールされた時やBcdedit.exeによって変更等が加えられた時に、NVRAM内のそれと同期されるようである。コマンドプロンプトを「管理者として実行」し、［bcdedit］と入力してEnterを押下すると、EFIパーティション内のBCD情報を、［bcdedit /enum firmware］と入力して実行すると、NVRAM内のBCD情報を見ることができる。種々のコマンド・ラインが用意されており、詳細は「BCDEditのコマンド ライン オプション」をご覧下さい。
なお、上の引用でも触れているように、32bitのWindowsでUEFIを使用する場合には注意が必要である。前掲の「UEFI and Windows」の7ページの"Note"にも、「32bit版のWindowsはUEFIの機能をサポートしない。64bit版のWindowsだけが、UEFIファームウェアによって可能となる機能を活用することができる。幸い、現行のUEFIの実装におけるCSM（ Compatibility Support Module）のおかけで、32bit OSその他のUEFIをサポートしないOSは、UEFIファームウェアを備えるハードウェア上で起動することが可能となっている。しかし、CSMが従来のBIOSをエミュレートするのであるから、CSMに起動を要求するOSはUEFI固有の機能を使用することはできない。」と説明されている。
UEFIに準拠したマザーボードで32bitのWindowsを使用する場合には、UEFIは名ばかりということになる。
※ MBRとGPTについては、『「初期化」について』、「フォーマット、その2～論理フォーマット」も是非ご覧下さい。
四、
以上、UEFIの特徴と概略は分かったような気がするが、UEFIが、BIOSに比べ、素晴らしい申し分のないファームウェアであるからといって、BIOSが完全に不要となる訳ではないらしい。前掲のUnified EFI Forumのサイトの「About UEFI」のページには、
「UEFIは完全にBIOSに取って代わるのか」という問いに対して、「いいえ。UEFIは、ブート・サービスとランタイム・サービスのために異なるインターフェイスを使うが、しかし一方では、BIOSがシステム構成（「Power On Self Test」または「POST」とも呼ばれる）とセットアップのために用いる機能を、プラットフォーム・ファームウェアが実行しなければならない場合もある。UEFIはPOSTとセットアップがどのように実装されるかに関する仕様を定めるものではない。」と答えている。
UEFIが完全にBIOSに取って代わるというものではなく、BIOSが受け持っていた機能の一部は、プラットフォームのファームウェアが担っているようである。UEFI準拠のマザーボードであっても、そのファームウェアが「BIOS」あるいは「UEFI BIOS」と呼ばれているのは、単に便宜上という訳でもないのである。
ウェブでUEFIについて調べていると、UEFIについて私と同様の誤解ないし勘違いをしている文章に出くわす。例えば、64bitのWindows7でUEFIを使っているにもかかわらず、起動上のドラブルの原因がMBRにあるのではと疑っている、といったような。
※ なお、MBRのディスクにBIOSモードでインストールされている64bit WindowsをUEFIモードのGPTディスクに簡単に移行させるソフトが、Paragonのサイトから入手できる。Migrate to UEFIというソフトであるが、現在（2013年4月14日）、Paragon Early Adopter Programに参加登録すると無料で利用することができる。
但し、正式発売前のソフトですので、そのプログラム参加申込みページの契約書に必ず目を通し、同意することができる場合にのみ、お試し下さい。
この一文がUEFIの概要を知る一助となれば幸いである。
【2013年3月27日】
【追記】
最近、UEFI仕様（バージョン2.3.1）の中の規格の一つであるSecure Bootが問題となっているようである。
Secure Bootとは、「ハードウェアによって検証された、マルウェアのない オペレーティング システム (OS) ブートストラップを可能とし、システム実装時のセキュリティを向上させ 」るものだそうである（「オープン プラットフォームにおける UEFI Secure Boot への対応」、The Linux Foundation）。このLinux Foundationのホワイトペーパーによると、Secure Bootの仕組みは、概略、以下のようになる。
UEFI仕様のSecure Bootに関するセクションは、プラットフォーム鍵（Platform Key, PK）と鍵交換鍵（Key Exchange Key, KEK）を定義している。プラットフォーム鍵はハードウェアの所有者が管理し、鍵交換鍵は、OSベンダー等が管理することになっているが、公開鍵と秘密鍵がペアとなっており、公開鍵だけで署名データーベース内にインストールすることができるように設計されている。
鍵交換鍵及びプラットフォーム鍵がインストールされていない状態をSetupモードとし、その段階ではブート可能なOSは限定されない。初回のOSのブート時に鍵交換鍵及びプラットフォーム鍵がインストールされるとSecureモードに切り替わり、署名データーベースの鍵交換鍵によってOSの認証がなされ、原則として、OSを変更したり、他のOSを追加することはできなくなる。
このようにしてOSの権利保護が図られることになる。
この場合、ベンダーが、PCをSetupモードで出荷し、また任意にSetupモードに戻すことができるようにし、さらに新たな鍵交換鍵を追加する手段を提供するならば、知的財産権の対象となるOSの使用許諾条項に抵触することなく、オープンOSの使用が可能となる、というのである。
ところが、UEFI 仕様はかなり難解で、2,139ページもあるためか、ハードウェア・ベンダーやWindowsをプリインストールしたPCを製造するメーカーの中には、必ずしもこの仕様を守っていないものもあるらしいのである。そうなると、Windowsは起動できるが、その他のOSをインストールして起動させることは不可能ということにもなる。彼等にしてみれば、Windowsさえ起動できればよいのであって、他のOSの動作まで保証してはいないのだから、ということになる。
この問題については、UEFI Secure BootやMicrosoft側を非難する文もウェブにはあるようだが、ハードウェア・ベンダーないしPCメーカー側がUEFIの仕様に従ってSecure Bootを正しく実装していない点にその主な原因があることも少なくないようである。
そこで、UEFI準拠のWindows搭載PCにおいてLinux系のOSを起動させるために、Linux FoundationはMicrosoftから提供を受けたLinux Foundation UEFI secure boot systemを公開している。競争関係にある両者の間でどのような話し合いがもたれたかはもちろん不明だが、その公開はLinux Foundationのテクニカル・アドバイザリ・ボードのメンバーであるJames Bottomleyのウェブサイトで行われるという形を今のところとっている。
FedoraやUbuntuについては試しに使ったことがあるという程度の知識しかなく、プログラミングについてはほとんど無知に等しいので、LinuxとSecure Bootの詳細については、前掲のLinux Foundationのホワイトペーパーの他に、James Bottomley's random Pages、「UEFIとLinuxの現状」（本の虫）、「セキュアブートと制限ブートの違いについて」（本の虫）等をご覧下さい。
【2013年3月31日】
【追記】
従来のBIOSとの違いで戸惑うことの一つが起動順序の設定である。
BIOSでは、OSの入っているドライブに優先してFloppy DriveやCD ROMを先順位に設定しておくことができた。しかし、UEFIでは、Windowsをインストールした場合、「Windows Boot Manager」がBoot Option Prioritiesの第１位に表示され、これを後順位に変更してしまうと、先順位に何らかの起動可能なディバイスがなければ、「Reboot and Select proper Boot device or Insert Boot Media in selected Boot device and press a key_」と表示されたままブート・プロセスが停止してしまう。従って、「Windows Boot Manager」などの起動可能なOSローダやディバイスを起動順位の第１位にしておく必要がある。
一時的にFloppy DriveやCD ROMから起動したい場合は、電源投入直後にBoot Menuを表示させて該当ディバイスを選択することになる。
因みに、BIOSやUEFIメニューにある「BBS Priorities」のBBSとは、「BIOS Boot Specification」の略であり、その内容については、Compaq、Phoenix、Intelの３社が連名で公開している「BIOS Boot Specification Version 1.01 January 11, 1996」という仕様書をご覧下さい。この仕様書は、BIOSがシステムのすべての初期プログラムロード (Initial Program Load：IPL) ディバイスを識別し、ユーザが選択した順序でそれらに優先順位をつけ、さらにそれぞれのディバイスに対して起動を試みる方法を記述したものであると、その５ページの「1.3 Purpose」という項に記載されている。
【2013年5月23日】
昨年秋にPCを組んで、X79のマザーボードにi7-3930Kを載せ、Windows7 Professional SP1 x64をインストールすることにした。初めてのUEFIであった。
UEFIについては、従来のBIOSをグラフィカルにし、マウスでも操作できるように改良したものといった程度の理解であった。UEFIの概略する知らなかった。
そのような認識のまま、いつものようにセットアップを進めた。SSD2台をRAID0としてWindowsを入れてみたが、Trimが機能しないなどSSDでRAIDを組む不都合を考えて、一旦RAIDを解き、AHCIに変更してSSD1台にWindowsを入れ直すことにした。この時、何らかの手違いがあったようで、Boot Manager（Bootmgr）やBoot Configuration Database（BCD）といったファイルが、意図しない別のHDDにインストールされたしまい、面倒なことになってしまった。その際、UEFIの基本的な知識がないためにうろたえてしまった。
OSのインストール時には、やはり、安全を考慮して関係のないHDDやSSDは接続しない方がよいようである。
とはいえ、UEFIの大要を改めて確認することにした。
二、
UEFIの本家であるUnified EFI Forumのサイトを覗いてみる。
FAQsの「UEFIとは何か」に対して、「UEFI (Unified Extensible Firmware Interface) とは、プリブート環境（すなわち、システムに電源を入れた後、OSが始動する前の環境）のためのシステム・コントロールをWindowsやLinuxといったOSに手渡すことを手助けするインターフェイスを詳細に規定する仕様をいう。UEFIはOSと起動時のプラットフォーム・ファームウェアとの十全なインターフェイスを提供し、アドインカードを初期化するためのアーキテクチャに依存しないメカニズムをサポートするものである。」と回答されている。
当初、EFIはIntelが開発していたものだが、その統一規格化及び普及を図るべく、Intel、Microsoft、HP、IBM、American Megatrends Inc.、Phoenix Technologies等の11社が中心となってUnified EFI Forumを組織し、現在140を超える企業がそれに参加していると言う。
それでは、「BIOSとは何か」ということになるが、その前にそもそも「ファームウェアとは何ぞや」ということになる。
【※ いつのまにかこのリンクも断たれており、2012年版の"UEFI and Windows"はダウンロードできなくなっている。しかし、なぜか元の2009年版はここからダウンロードできるようになっている。
http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/uefi_windows.docx
このリンクは、"BASIC INPUT/OUTPUT"というブログで知ったものである。（2016.12.20）】
ファームウェアについては、こう説明されている。
「あらゆるPCはファームウェアによってプリロードされる。ファームウェアとは、上位のソフトウェアからの命令に対してハードウェアの反応を指示するハードウェア特有のコードをいう。ファームウェアは、通常、マザーボードのようなハードウェアというディバイスに直接付属する不揮発性のストレージ内に組み込まれている。特に、ファームウェアは、通常、プログラム可能なread-only memory（PROM）又は電気的に消去可能なPROM（EEPROM)又はフラッシュ・メモリ内に保存されている。しかし、ファームウェアは、ビデオカードやストレージ・コントローラといった任意のディバイス・ハードウェア上にも存在する。
ファームウェアはブート・プロセスの間に実行される最初の指示を与える。ファームウェアは、ハードウェアの検出とシステムの初期化を終了した後、OSのboot loaderのようなブート・アプリケーションあるいはOSがロードされる前に実行されるツール（時として、プリOSツールと呼ばれる）にコントロールを渡すのである。
BIOSやUEFIはファームウェアの例である。PCは通常そのいずれか一方を使うのである。」と。
BIOSについては、改めて、
「BIOSというファームウェアは1970年代に初期のPCのために開発されたものである。BIOSは今なお最も流布しているファームウェアであるが、BIOSは、それが16bitプロセッサ・モードと1MBのアドレス指定可能なメモリ領域だけをサポートしているに過ぎないので、いよいよ制約されたものとなっている。共通するBIOSの規格が存在せず、BIOSの実装がベンダーごとにまちまちになりうることから、BIOSシステム上に新たなハードウェアのためにサポートを追加することも、比較的複雑になっている。」と説明されている。
これに対してUEFIは、と言うと、
「BIOSと対照的にUEFIは、インターフェイスとデータ構造のための標準の構文と意味を持った一まとまりのブート・サービス及びランタイム・サービスを定義するものである。これは、すべてのUEFIの実装が、本質的には同じように動作するとともに、標準規格のドライバやアプリケーションを検証したり、開発することを可能にすることを意味する。これは、相互運用性を大いに高め、新たなハードウェアをサポートすることに伴う複雑さを軽減し、コンピュータ・メーカーがファームウェアをより迅速に更新し、整備・維持することに役立つことになる。」
続けて、UEFIの利点が6つ挙げられている。
「従来のBIOSとの互換性
現行のUEFIの実装のほとんどは、従来のBIOSをエミュレートするCompatibility Support Module （CSM） を内蔵している。したがって、UEFIファームウェアを備えるシステムは、UEFIを考慮したOSあるいはBIOSのみをサポートした古いOSのどちらも起動することができる。この機能が末端の利用者に柔軟性と互換性を提供する。
大容量ディスクのサポート
BIOSシステムはmaster boot record（MBR）というパーティショニング方式を用いるディスクをサポートする。この方式は、ディスクの最大容量を約2.2TBに、プライマリー・パーティションを最大4つに制限する。UEFIはGUID Partition Table（GPT）と呼ばれるより柔軟なパーティショニング方式をサポートする。GPTディスクはパーティションを記述するのに64bit値を使用する。この方式によれば、ディスクの最大容量は約1680万TB（※）、プライマリー・パーティションの数は最大128個まで可能となる。
【※筆者註：
GPTディスクにおいては、1パーティション・エントリでパーティションの開始LBA、終端LBAを指定するために各8バイトが割り当てられいるので、理論的には、8バイト=64bit、1セクタ512バイトで計算すると、2^64 × 512バイト、即ち8ZB（ゼタバイト、正確には2進接頭辞で8ZiB〈ゼビバイト〉であるが、ここでは従来の慣習に従い2の冪乗をSI接頭辞で表す。約86億TB）が定義できる上限となる（1ZB=1,0241EB〈エクサバイト〉=1,048,576PB〈ペタバイト〉=1,073,741,824TB=1,099,511,627,776GB）。
しかし、これはあくまで理論上の値であって、例えば、Windows Server 2003 SP1、Windows XP x64 edition及びそれ以降のWindowsにおいては、RAW（未フォーマット）パーティションの最大サイズは、18EB（エクサバイト、約1887万TB）であり、フォーマットされたパーティションでは256TBが最大サイズとなっている（各パーティションのファイルシステムが現行では、256TBに制限されているからである）。
参考：
https://msdn.microsoft.com/en-us/library/windows/hardware/dn640535%28v=vs.85%29.aspx
https://msdn.microsoft.com/en-us/microsoft-r/dn898510
このペーパーでは、ディスクの最大容量を、"roughly 16.8 million terabytes"と記述しているが、上記のサイトなどでは、"18 exabytes (~18.8 million terabytes)"と記載されている。おそらく、18.8 millionを16.8 millionと誤記したものと思われる。2017.5.8】
GPTディスクにおいては、1パーティション・エントリでパーティションの開始LBA、終端LBAを指定するために各8バイトが割り当てられいるので、理論的には、8バイト=64bit、1セクタ512バイトで計算すると、2^64 × 512バイト、即ち8ZB（ゼタバイト、正確には2進接頭辞で8ZiB〈ゼビバイト〉であるが、ここでは従来の慣習に従い2の冪乗をSI接頭辞で表す。約86億TB）が定義できる上限となる（1ZB=1,0241EB〈エクサバイト〉=1,048,576PB〈ペタバイト〉=1,073,741,824TB=1,099,511,627,776GB）。
しかし、これはあくまで理論上の値であって、例えば、Windows Server 2003 SP1、Windows XP x64 edition及びそれ以降のWindowsにおいては、RAW（未フォーマット）パーティションの最大サイズは、18EB（エクサバイト、約1887万TB）であり、フォーマットされたパーティションでは256TBが最大サイズとなっている（各パーティションのファイルシステムが現行では、256TBに制限されているからである）。
参考：
https://msdn.microsoft.com/en-us/library/windows/hardware/dn640535%28v=vs.85%29.aspx
https://msdn.microsoft.com/en-us/microsoft-r/dn898510
このペーパーでは、ディスクの最大容量を、"roughly 16.8 million terabytes"と記述しているが、上記のサイトなどでは、"18 exabytes (~18.8 million terabytes)"と記載されている。おそらく、18.8 millionを16.8 millionと誤記したものと思われる。2017.5.8】
CPUに依存しないアーキテクチャ
BIOSは32bit及び64bitのOSを実行することができるが、初期のブート段階の間は、BIOSは"real mode"と呼ばれる16bitインターフェイスに依拠する。このインターフェイスは初期のIntel x86プロセッサ・アーキテクチャに基づくものである。BIOS上のすべてのファームウェア・ディバイス・ドライバ（RAIDコントローラといったような）も16bitでなければならない。この条件は、初期のブート段階でアドレス指定可能なメモリを64KBに制限し、結果的にパフォーマンスを圧迫することになる。
UEFIはどのCPUのアーキテクチャにも依存しない。それは、最新の32bit及び64bitのファームウェア・ディバイス・ドライバをサポートすることができる。その64bitの機能によって、システムが初期のブート段階から172億GB（16EB：筆者註）以上のメモリにアドレスを指定することが可能となる。
CPUに依存しないドライバ
BIOSシステム上では、Peripheral Component Interconnect（PCI）のアドオンカードは、サポートするすべてのCPUアーキテクチャのために個別のドライバを保持しておく容量の大きなROMを内蔵しなければならない。そうでなければ、カード・ベンダーはそれぞれのプロセッサ・アーキテクチャごとに製品を揃え、在庫を管理しなければならないことになる。
UEFI仕様に適合するすべてのUEFIの実装は、EFI Byte Code（EBC）というインタプリタ（逐次解釈しながら実行するプログラムのこと：筆者注）を含んでいる。EBCイメージはすべてのプロセッサ・アーキテクチャと互換性のあるドライバである。これによってディバイス・ドライバとアプリケーションの開発者はどのシステムでも実行できる一つのEBCイメージを作り出すことが可能となる。EBCイメージは非常にコンパクトで公汎な適合性があるので、PCIカードのファームウェア・ドライバ（別名、オプションROMとも）は、BIOSシステムの場合のものよりも非常に小さくすることができ、それらは多様な市場に対応できることになる。これは、コストと混乱を軽減することに役立ち、システム・ベンダーが必要に応じてドライバを更新し、入れ替えることをさらに容易にすることになる。
柔軟性のあるプリOS環境
UEFIドライバ及びアプリケーションはブート環境でほとんど制約なしに実行される。例えば、UEFIは高解像度のグラフィックスに加えて完全なネットワークのプロトコル・スタックを提供することができ、動作可能なOSが利用できない場合であっても、すべてのディバイスにアクセスできる。
UEFIは柔軟なプリOSのプログラミング環境をサポートすることから、UEFIアプリケーションはどんなタイプのPCハードウェアに対しても広く多様なタスクを実行することができる。例えば、UEFIアプリケーションは診断とファームウェアのアップグレードを実行することができ、あるいはOSを修復して技術者に知らせることができ、あるいは認証のために遠隔のサーバに接続することができるのである。
モジュールの設計
BIOSの実装は構成された特定のハードウェアのために細心の注意を払ってカスタマイズしなければならない。緻密に組み合わされたコンポーネントは、往々にしてわずかな変更であっても広範囲にわたる影響を生じてしまいがちである。新たなハードウェアやプロトコルの導入は通常BIOSファームウェアの重要な部分の書き換えを要求する。これでは、コストと時間がかかる。
UEFIはハードウェアないしソフトウェアのインターフェイスの細かな点を意図的にまとめて一般化するモジュールのコンポーネントや汎用のインターフェイスを規定している。このアプローチによって、ファームウェア・ベンダーは、新たなハードウェアやプロトコルを導入すること、バグを修正すること、あるいは残りのシステムへの影響を最小限に抑えながら特定のコンポーネントの動作を改変することが可能となる。」
三、
それでは、UEFIは起動時にどのような働きをするのであろうか。「Windows Internals Sixth Edition」（Mark Russinovich他、Microsoft Press)には、UEFIのブート・プロセスについてもう少し詳しく説明されている。
「UEFI準拠システムはWindowsのセットアップによってシステムの不揮発性RAM（NVRAM）にプログラムされたboot loader codeを実行するファームウェアを有している。boot codeはBCD（Boot Configuration Database）の内容を読み込むが、それもまたNVRAMに保存されている。前述した（Part2のp.503以下で説明されている：筆者注）Bcdedit.exeツールは、このメカニズムがまったくユーザに知られずに処理されることを考慮して、BCDにあるファームウェアのNVRAMの変更可能な部分を抜き出す機能も備えている。
UEFI標準規格には、ロードするOS又は追加のアプリケーションを選択するために使うことができるEFI Boot Managerを使用するようユーザに促す機能が定義されている。しかし、BIOSシステムとUEFIシステムとの一貫したユーザ・インターフェイスを提供するべく、WindowsはEFI Boot Managerを選択するために2秒のタイムアウトを設定している。その後、EFIヴァージョンのBootmgr（Bootmgfw.efi）が替わりにロードされることになる。
次に、ハードウェアの検出が行われる。そこでは、boot loaderは、以下のディバイスの数とタイプを判定するために、UEFIというインターフェイスを使用するのである。
■ ネットワーク・アダプタ
■ ビデオ・アダプタ
■ キーボード
■ ディスク・コントローラ
■ ストレージ・ディバイス
UEFIシステム上では、全ての操作やプログラムはページングを有効にしたネイティブCPUモードで実行され、Windowsのブート・プロセスのどの部分も16bitモードで実行されることはない。EFIは32bitと64bitのいずれのシステムにおいてもサポートされているけれど、Windowsは64bitのプラットフォームにおいてのみEFIのためのサポートを提供していることに注意する必要がある（【追記】：Windows 8、8.1、10等では、32bitのプラットフォームにおいてもEFIをサポートするようになった）。
Bootmgrがx86あるいはx64システムで行うのと同じように、EFI Boot Managerは任意のタイムアウトでブート選択のメニューを表示する。ブート選択が行われると、ローダはその選択に応じてEFIシステム・パーティションのサブディレクトリに進み、EFIヴァージョンのWindows boot loader（Winload.efi）をロードする。
UEFIの仕様は、FATというファイル・システムでフォーマットされ、サイズが100MBから1GBの間であるか又はディスク・サイズの1％以下である、EFIシステム・パーティションとして指定されたパーティションを、システムが持つことを要求する。そして、インストールされた各WindowsはEFIシステム・パーティションの[EFI\Microsoft]の下にサブディレクトリを有する。
統一されたブート・プロセスとWindowsの現行のモデルのおかげで、表13-1（ Part2のp.500にあるBIOS Boot Process Componentsの一覧表：筆者注）に示されるコンポーネントは、「.exe」で終わるものが「.efi」で終わることを除いては、ほとんど同じようにUEFIシステムに適用される。そして、それらコンポーネントはBIOSの割込みの替わりにEFIのAPIとサービスを使用する。もう一つの違いは、MBRというパーティション・フォーマットの制約（1ディスクにつき最大4つのパーティションであるということを含む）を避けるため、UEFIシステムは、GPT（GUID Partition Table）フォーマットを使うということである。」（pp.512-513, Part2）
※ マザーボードのNVRAM内に格納されるBCD情報は、ドライブのEFIシステム・パーティション内にも保存される。EFIパーティション内のBCD情報は、OSがインストールされた時やBcdedit.exeによって変更等が加えられた時に、NVRAM内のそれと同期されるようである。コマンドプロンプトを「管理者として実行」し、［bcdedit］と入力してEnterを押下すると、EFIパーティション内のBCD情報を、［bcdedit /enum firmware］と入力して実行すると、NVRAM内のBCD情報を見ることができる。種々のコマンド・ラインが用意されており、詳細は「BCDEditのコマンド ライン オプション」をご覧下さい。
【追記】：ある人から、UEFIにおけるストレージ側のBCDとNVRAM側の内容との同期に関する奇妙な振舞について指摘があった。何度かメールのやり取りをしたが、それによると概略以下の通りである。
LenovoのE31においてSecure Bootを無効にしたUEFIでWindows8.1をインストールした後、Ubuntu13.10をインストールし、マルチブートを試みるも失敗。その時のNVRAMのエントリには、Ubuntuがある。その後、HDDを外してHDD未接続のまま、電源を投入してNVRAMの情報を読み出してみると、Ubuntuのエントリがなくなっている。再び、そのHDDを接続し、電源投入直後にNVRAMの内容を読み込むと、Windowsがエントリに追加されているが、Ubuntuは追加されない、というのである。
このことから、「電源投入時にHDD未接続から接続に切り替わったことを検知し、ESP（EFI System Partition）中の定義を読み込んだ」のであろうし、「HDD交換を検知した時点でも同様の挙動」をするのであろう、と彼は推察する。また、「WindowsのBCDはwindowsを起動しないと読めない」ので、「NVRAMと全く同じ内容か不明」である、と言う。
ESP内のBCDとNVRAMとの同期は、正確にはどの時点で、どのようになされるのであろうか。そもそも、これはLenovoのE31に限ってのことなのか、UEFIの仕様に基づく振舞なのかも分からない。
確かにBIOSは、ベンダーにとって制約の多いファームウェアであったかもしれないが 、我々ユーザにとっては扱いが簡明であったことは事実である。UEFIの動作を理解し、慣れるには、まだ時間がかかりそうである。（2014.3.20）
LenovoのE31においてSecure Bootを無効にしたUEFIでWindows8.1をインストールした後、Ubuntu13.10をインストールし、マルチブートを試みるも失敗。その時のNVRAMのエントリには、Ubuntuがある。その後、HDDを外してHDD未接続のまま、電源を投入してNVRAMの情報を読み出してみると、Ubuntuのエントリがなくなっている。再び、そのHDDを接続し、電源投入直後にNVRAMの内容を読み込むと、Windowsがエントリに追加されているが、Ubuntuは追加されない、というのである。
このことから、「電源投入時にHDD未接続から接続に切り替わったことを検知し、ESP（EFI System Partition）中の定義を読み込んだ」のであろうし、「HDD交換を検知した時点でも同様の挙動」をするのであろう、と彼は推察する。また、「WindowsのBCDはwindowsを起動しないと読めない」ので、「NVRAMと全く同じ内容か不明」である、と言う。
ESP内のBCDとNVRAMとの同期は、正確にはどの時点で、どのようになされるのであろうか。そもそも、これはLenovoのE31に限ってのことなのか、UEFIの仕様に基づく振舞なのかも分からない。
確かにBIOSは、ベンダーにとって制約の多いファームウェアであったかもしれないが 、我々ユーザにとっては扱いが簡明であったことは事実である。UEFIの動作を理解し、慣れるには、まだ時間がかかりそうである。（2014.3.20）
【追記】：BCD及びNVRAM等、起動時のUEFIの動作について分かったこと
● 上の追記のデュアルブートに関しては、通常であれば、Linuxのefibootmgrコマンドを使って直接NVRAMのブートエントリを編集すればよいのではなかろうか。さらに、GRUB 2（Grand Unified Bootloader 2）を使い、chainloaderでそれぞれのOSローダを呼び出すように設定すれば、UEFIにおけるマルチブートは可能となるはずである。この点については、rotakeさんのブログ「EFIマルチブート(1)」が非常に簡明で参考になった。それでもなお、マルチブートが実行できないとなると、Lenovo E31のUEFIの仕様に問題があると言わざるをえないであろう。
※ NVRAMについては、『「初期化」について』もご一読下さい。
遅まきながら、UEFIの仕様書（http://uefi.org/specifications）のSection 3 "Boot Manager"等にざっと目を通してみた。ブートプロセスの大まかな解説部分だけを拾い読みしただけであるが、UEFIのブートプロセスの不可解な部分がわずかながら理解できたような気がした。OSやファームウェアのベンダーに特有の仕様を認めている事項も多く、そのためOSやマザーボード（即ち、実装されるUEFI）によって起動時の動作・振舞が異なることも分かった。
そのファームウェア・ベンダー特有の仕様の一つと考えられるのが、ブートエントリにOSローダが存在しない場合、電源投入後自動的に接続ストレージの中からEFI System Partition（ESP）を探し出し、その中のWindowsのOSローダ、bootmgfw.efi（Windows Boot Manager、識別子{bootmgr}）を検出してNVRAMにブートエントリを登録するというものである（「Windows 10 PC UEFI BIOS(UEFI)の役割としくみ 」：UEFIの詳細な解説がなされており、一読をお勧めする）。これを厄介と見る向きもある。
また、WindowsにあるBCDとNVRAMとの同期について、TechNetのライブラリの「BCD と NVRAM で重複しているファームウェア オブジェクトを削除する」に次のような記述がある。
「bcdedit /enum コマンドを実行すると、bcdedit によってシステム BCD ストアが開きます。bcdedit によって BCD が開くと、NVRAM のエントリと BCD のエントリが比較されます。ファームウェアによって作成された NVRAM のエントリのうち BCD に存在しないものが、システム BCD に追加されます。bcdedit によってシステム BCD が閉じると、BCD のブート マネージャ エントリのうち NVRAM に存在しないものが NVRAM に追加されます。」と。
なるほど、bcdedit /enumによってBCDを開き、そして閉じるだけで、BCDとNVRAMとの同期がなされるというのである。
また、bcdedit /enum /v （bcdedit /v）で詳細を、bcdedit /enum allですべてを表示することが可能である。
さらに、bcdedit /import コマンドを使うと、BCDをNVRAMにコピーすることができる。
しかし、ESP内のBCDファイルが破損している場合には、bcdbootコマンドを使ってBCDを再作成する必要がある。詳細は、MSDNの「BCDboot のコマンド ライン オプション」をご覧頂きたい。
例えば、
bcdboot C:\Windows /l ja-jp
と打つと、C:\WindowsフォルダーにあるBCDファイルを使ってESP内にBCDブート環境ファイルが改めて作成される。C:\Windows\Boot\EFI内には、bootmgfw.efi等が保存されている。それと同時にBCDBootは、NVRAM内にWindows Boot Managerをエントリの第1順位として追加してくれるのである。
異なるグレードのWindowsでデュアルブートないしマルチブート環境を構築すべく、各ドライブにOSをインストールしたにもかかわらず、OS選択画面が表示されない場合、このbcdbootコマンドを使用する。
例えば、Cドライブに加えて、Dドライブ、Eドライブにも異なるWindowsがインストールされているとすれば、
bcdboot D:\Windows /l ja-jp
bcdboot E:\Windows /l ja-jp
を実行する。
BCDファイルが書き換えられ、各々のWindowsの「Windows ブートローダー」（Winload.efi）が追加されて、「オペレーティングシステムの選択画面」に表示されるようになる。この場合、最後に追加したOSがデフォルトの起動OSとなる。
改めて確認しておくが、Windowsの場合、UEFIにおける「OSローダ」はあくまでNVRAN内のブートエントリに登録されるWindows Boot Manager（bootmgfw.efiの「fw」は「firmware」の略なのであろう。「ファームウェアブートマネージャー」とも呼ばれている。MSDN、「UEFI 用の BCD システム ストアの設定」）であり、これが読み込まれてBCDファイルを解析し、それに従ってOS選択画面（ブートメニュー）にインストールされているOSが列挙され、いずれかが選択されるとそのWindowsブートローダーが読み込まれて当該Windowsが起動することになるのである。
● なお、上記MSDNのライブラリには、「UEFI 2.3.1 仕様により、既定のファームウェア設定は、EFI システム パーティション (ESP) のファイル \efi\boot\bootx64.efi を開きます。」とある。これは、NVRAM内のエントリが指示するディバイスが存在しない場合や、有効なエントリが存在しないといった場合には、起動時の既定の動作として、ESPのあるドライブを検索し、その中の\efi\boot\bootx64.efiを読み取りに行くということである。
例えば、Windows7 64bitでは、ESPの\efi\Microsoft\boot内にbootmgfw.efi（Windows Boot Manager)がインストール時に作成されるが、同時にESPの\efi\boot内にbootx64.efiという名のファイルが作成されている。このbootx64.efiは、作成日時やサイズから判断すると、bootmgfw.efiと同じファイルであると推測される。だとすれば、NVRAMのエントリに不具合が生じても、その既定の動作によってWindowsが起動されることになる。これはフェイル・セーフ機能の一つということなのであろう。
確認のために、EFI Shellを使って、ESPの\efi\boot\bootx64.efiを実行してみると、正常にWindowsが起動する。上記の推測は間違っていないようである。
この\efi\boot\bootx64.efiは、UEFI仕様書（Version 2.3.1）のSection 3.4.1.1 "Removable Media Boot Behavior"及びSection 3.4.1.2 "Non-removable Media Boot Behavior"に規定されており、これを利用してUSBメモリ等からOSを起動することも可能となるとされている。
● EFI Shellについて
EFI Shell（UEFI Shellとも表記される）は、対話型のコマンド・ライン・インターフェイス（CLI）を持ち、UEFI Shellスクリプトを作成することもできるソフトウェアである。UEFI環境で使用することができる。"Built-in EFI Shell"としてUEFIの設定画面から直ぐに利用できるマザーボードもあるが、"Launch EFI Shell from filesystem device"、あるいは"Launch Shell from device"などと表示されるマザーボードの場合、予めUSBメモリにshellx64.efiを置いておかなければならない。
このEFI Shellであるshellx64.efiの入手は、ほとんどの場合、tianocoreというUEFIのオープン・ソース・コミュニティが提供するEDK IIというUEFIの開発環境に含まれているShell.efiをダウンロードすることによってなされているようである。
開発者にはリポジトリ・ホスティング・サイトとしてお馴染みであろうGitHubの以下のWebページを開き、
https://github.com/tianocore/edk2/tree/master/ShellBinPkg/UefiShell/X64
そこのShell.efiをダウンロードする。これをshellx64.efiというファイル名に書き換えて、FAT32にフォーマットしたUSBメモリのパーティションのルートディレクトリに置いておくのである。
しかし、UEFI設定画面に"Launch EFI Shell from filesystem device"、または"Launch Shell from device"といったEFI Shellを起動する項目がなければ、USBメモリにshellx64.efiとして置いていたとしても、そのままではEFI Shellを開くことはできない。後述するように、USBメモリのパーティションをFAT32でフォーマットし、\efi\bootのディレクトリを作成し、その中にshellx64.efiをbootx64.efiというファイル名に変更して置いておき、Boot Menu等から当該USBメモリ（「UEFI:」などと表示される）を選択して起動すれば、EFI Shellを実行することができる。
コマンドやパラメータの詳細は、UEFI Forumの"Specifications"にある"UEFI Shell Specification"をご覧頂きたい。各メーカーもサイトでコマンドの説明を行っており、特にHPは、日本語によるUEFI Shellコマンドの詳細な解説を「HPE ProLiant Gen10 サーバーおよび HPE Synergy 用 UEFI シェルユーザーガイド」などで公開している。ただし、このユーザーガイドには Hewlett Packard Enterprise (HPE) が独自に追加したカスタムコマンドも含まれており、当然それを一般のUEFI Shellで使うことはできない。
"Launch EFI Shell from filesystem device"をクリックすると、EFI Shellが起動する。その初期化の過程で、PCI deviceに対してマッピングが行われる。ファイルシステムが認識されたディバイスに対してパーティションごとに、fsという文字に0から順に番号が割り振られ、fs0、fs1、fs2、…というマッピング名が付けられる。と同時に、ファイルシステムに関係なく全てのPCI deviceには、block deviceとして、blk0、blk1、blk3、…とマッピング名が付与される。これらが標準のマッピング名としてコマンド等で使用されることになる。EFI Shellのversion 1.0では番号は16進数であったが、今使っているversion 2.1では10進数に変更されている。マッピングの表示も、version 2.1では簡潔なものとなっている。私のマシンでは、fs6及びblk17までマッピングされている。
○ 一般的なコマンド、cd、ls/dir、rm/del、cp/copy、mkdir/md等が使える。helpでコマンドの一覧も表示される。大文字と小文字は区別されない。特定のコマンドの詳細な説明は、
Shell> help [コマンド名]
Shell> ? [コマンド名]
Shell> [コマンド名] -?
いずれでも表示される。注意点やパラメータの使用例なども示されており、便宜である。
また、
Shell> help [コマンド名] -b
と、-b のパラメータを使うと、一画面ごとに表示が停止されるので便利である。これは大量の情報が表示されることが想定されるコマンドでは使用できるようになっている。また、Page UP、Page Downキーで画面を上下させることができる。ただし、4画面までしか戻れない。
○ 現在のディレクトリを特定のマッピングされたファイルシステム、例えば、fs0に変更するには、
Shell> fs0:
FS0:\>
とする。ただし、この時点では、キーボードが英語配列（USキーボード）として認識されているので、
[:]を入力するには、Shift＋;キーを、
[\（バックスラッシュ）]を入力するには、]キーを、
[*]を入力するには、Shift＋8キーを、
["]を入力するには、Shift＋:キーを押さなければならない。
○ ディレクトリやファイルをコピーする場合、例えば、fs1にある全てのディレクトリ（フォルダ）をfs0にあるbackupというディレクトリにコピーするときは、ワイルドカード、*を使って、
FS0:\> cp -r fs1:\* backup
とする。
ただし、日本語の全角文字は識別されないので、名前に全角文字を含むディレクトリやファイルは指定することができない。その場合は、その親ディレクトリをコピーするか、ワイルドカードを使って全てのディレクトリやファイルをコピーするほかない。
○ ディレクトリ名やファイル名の変更は、mvコマンドで行うことが可能である。例えば、fs1のルートディレクトリにあるosx64.efiをppapx64.efiに変更する場合には、
FS1:\> mv osx64.efi ppapx64.efi
○ バージョンを確認する場合、verが使える。
FS0:\> ver
UEFI Interactive Shell v2.1
EDK II
UEFI v2.31 (American Megatrends, 0x...)
このようにUEFI ShellのバージョンとUEFIのバージョンが表示される。UEFIのバージョンは、マザーボードのファームウェアとしてのUEFIのバージョンではなく、それが準拠しているUEFI仕様のバージョンである。UEFI仕様のバージョンの相違によって、UEFIの動作・振舞にかなりの違いを生ずる点もあるようである。UEFI仕様のバージョンを知る必要がある場合もあろう。
○ UEFI［Shell］アプリケーション（拡張子.efi）とUEFI Shellスクリプトファイル（拡張子.nsh）を実行することができる。OSローダもUEFIアプリケーションであるから、前述したESP内にあるbootx64.efiを指定するとWindowsを起動させることができる。
Shell> fs1:\efi\boot\bootx64.efi
FS1:\> efi\boot\bootx64.efi
絶対パス、相対パスどちらも使える。EFI Shellを終了するときは、exitを使わずに、このように直接Windowsを起動している。
また、このEFI Shellも、UEFIアプリケーションであるから、shellx64.efiをbootx64.efiにファイル名を変更し、USB等に\efi\boot\bootx64.efiとして置いておけば、電源投入後、UEFIによりNVRAMに自動的にエントリが作成され、Boot MenuやPlease select boot device画面に"UEFI: USB..."などと表示される。それを選択すれば、EFI Shellを起動することが可能であり、便利である。
○ EFI Shellのコマンドの中で最も有用なコマンドは、bcfgであろう。bcfgは、NVRAMに保存されているブート・オプションやドライバ・オプションを操作することができるコマンドである。bcfgコマンドは、バージョン1.0のEFI Shellにはない機能であり、バージョン2.0以降で使用することが可能となったようである。これであれば、OSを問わず使用できるので、Linuxのefibootmgrコマンドよりも便宜であると言えよう。詳細は、上記に示したUEFI Shell Specificationをご覧頂きたい。
・ NVRAM内のブート・エントリや順位などのブート・オプションを表示するには、
Shell> bcfg boot dump
・ ブート・オプションを追加するには、例えば、fs1:\EFI\test\にあるbootx64win.efiをブート順位3（先頭は0）に、Windows Loaderという表示名（Desc[ription] ）で追加する場合は、
Shell> bcfg boot add 3 fs1:\EFI\test\bootx64win.efi "Windows Loader"
として実行。すると、
Target = 0006.
bcfg: Add Boot0006 as 3
などとなり、BootXXXX変数は自動で割り振られる。順位3以降に既にブート・オプションが存在する場合は、それらは全て順位が1つ繰り下がることになる。
・ ブート・オプション、例えば順位4を削除する場合は、
Shell> bcfg boot rm 4
順位5以降は、順位が繰り上がる。
・ ブート・オプションの順位を、例えば2から6へ移動させるには、
Shell> bcfg boot mv 2 6
とする。順位3、4、5は、順位が繰り上がる。
・ ブート・オプション、例えば順位3の表示名を、「Emergency Loader」に変更する場合は、
Shell> bcfg boot mod 3 "Emergency Loader"
UEFI環境における各OSやマザーボード特有の振舞だけでなく、UEFI自体の振舞についても理解が進むにつれて、戸惑いや混乱は治まってきているようである。（2016.12.4）
● 上の追記のデュアルブートに関しては、通常であれば、Linuxのefibootmgrコマンドを使って直接NVRAMのブートエントリを編集すればよいのではなかろうか。さらに、GRUB 2（Grand Unified Bootloader 2）を使い、chainloaderでそれぞれのOSローダを呼び出すように設定すれば、UEFIにおけるマルチブートは可能となるはずである。この点については、rotakeさんのブログ「EFIマルチブート(1)」が非常に簡明で参考になった。それでもなお、マルチブートが実行できないとなると、Lenovo E31のUEFIの仕様に問題があると言わざるをえないであろう。
※ NVRAMについては、『「初期化」について』もご一読下さい。
遅まきながら、UEFIの仕様書（http://uefi.org/specifications）のSection 3 "Boot Manager"等にざっと目を通してみた。ブートプロセスの大まかな解説部分だけを拾い読みしただけであるが、UEFIのブートプロセスの不可解な部分がわずかながら理解できたような気がした。OSやファームウェアのベンダーに特有の仕様を認めている事項も多く、そのためOSやマザーボード（即ち、実装されるUEFI）によって起動時の動作・振舞が異なることも分かった。
そのファームウェア・ベンダー特有の仕様の一つと考えられるのが、ブートエントリにOSローダが存在しない場合、電源投入後自動的に接続ストレージの中からEFI System Partition（ESP）を探し出し、その中のWindowsのOSローダ、bootmgfw.efi（Windows Boot Manager、識別子{bootmgr}）を検出してNVRAMにブートエントリを登録するというものである（「Windows 10 PC UEFI BIOS(UEFI)の役割としくみ 」：UEFIの詳細な解説がなされており、一読をお勧めする）。これを厄介と見る向きもある。
また、WindowsにあるBCDとNVRAMとの同期について、TechNetのライブラリの「BCD と NVRAM で重複しているファームウェア オブジェクトを削除する」に次のような記述がある。
「bcdedit /enum コマンドを実行すると、bcdedit によってシステム BCD ストアが開きます。bcdedit によって BCD が開くと、NVRAM のエントリと BCD のエントリが比較されます。ファームウェアによって作成された NVRAM のエントリのうち BCD に存在しないものが、システム BCD に追加されます。bcdedit によってシステム BCD が閉じると、BCD のブート マネージャ エントリのうち NVRAM に存在しないものが NVRAM に追加されます。」と。
なるほど、bcdedit /enumによってBCDを開き、そして閉じるだけで、BCDとNVRAMとの同期がなされるというのである。
また、bcdedit /enum /v （bcdedit /v）で詳細を、bcdedit /enum allですべてを表示することが可能である。
さらに、bcdedit /import コマンドを使うと、BCDをNVRAMにコピーすることができる。
しかし、ESP内のBCDファイルが破損している場合には、bcdbootコマンドを使ってBCDを再作成する必要がある。詳細は、MSDNの「BCDboot のコマンド ライン オプション」をご覧頂きたい。
例えば、
bcdboot C:\Windows /l ja-jp
と打つと、C:\WindowsフォルダーにあるBCDファイルを使ってESP内にBCDブート環境ファイルが改めて作成される。C:\Windows\Boot\EFI内には、bootmgfw.efi等が保存されている。それと同時にBCDBootは、NVRAM内にWindows Boot Managerをエントリの第1順位として追加してくれるのである。
異なるグレードのWindowsでデュアルブートないしマルチブート環境を構築すべく、各ドライブにOSをインストールしたにもかかわらず、OS選択画面が表示されない場合、このbcdbootコマンドを使用する。
例えば、Cドライブに加えて、Dドライブ、Eドライブにも異なるWindowsがインストールされているとすれば、
bcdboot D:\Windows /l ja-jp
bcdboot E:\Windows /l ja-jp
を実行する。
BCDファイルが書き換えられ、各々のWindowsの「Windows ブートローダー」（Winload.efi）が追加されて、「オペレーティングシステムの選択画面」に表示されるようになる。この場合、最後に追加したOSがデフォルトの起動OSとなる。
改めて確認しておくが、Windowsの場合、UEFIにおける「OSローダ」はあくまでNVRAN内のブートエントリに登録されるWindows Boot Manager（bootmgfw.efiの「fw」は「firmware」の略なのであろう。「ファームウェアブートマネージャー」とも呼ばれている。MSDN、「UEFI 用の BCD システム ストアの設定」）であり、これが読み込まれてBCDファイルを解析し、それに従ってOS選択画面（ブートメニュー）にインストールされているOSが列挙され、いずれかが選択されるとそのWindowsブートローダーが読み込まれて当該Windowsが起動することになるのである。
● なお、上記MSDNのライブラリには、「UEFI 2.3.1 仕様により、既定のファームウェア設定は、EFI システム パーティション (ESP) のファイル \efi\boot\bootx64.efi を開きます。」とある。これは、NVRAM内のエントリが指示するディバイスが存在しない場合や、有効なエントリが存在しないといった場合には、起動時の既定の動作として、ESPのあるドライブを検索し、その中の\efi\boot\bootx64.efiを読み取りに行くということである。
例えば、Windows7 64bitでは、ESPの\efi\Microsoft\boot内にbootmgfw.efi（Windows Boot Manager)がインストール時に作成されるが、同時にESPの\efi\boot内にbootx64.efiという名のファイルが作成されている。このbootx64.efiは、作成日時やサイズから判断すると、bootmgfw.efiと同じファイルであると推測される。だとすれば、NVRAMのエントリに不具合が生じても、その既定の動作によってWindowsが起動されることになる。これはフェイル・セーフ機能の一つということなのであろう。
確認のために、EFI Shellを使って、ESPの\efi\boot\bootx64.efiを実行してみると、正常にWindowsが起動する。上記の推測は間違っていないようである。
この\efi\boot\bootx64.efiは、UEFI仕様書（Version 2.3.1）のSection 3.4.1.1 "Removable Media Boot Behavior"及びSection 3.4.1.2 "Non-removable Media Boot Behavior"に規定されており、これを利用してUSBメモリ等からOSを起動することも可能となるとされている。
● EFI Shellについて
EFI Shell（UEFI Shellとも表記される）は、対話型のコマンド・ライン・インターフェイス（CLI）を持ち、UEFI Shellスクリプトを作成することもできるソフトウェアである。UEFI環境で使用することができる。"Built-in EFI Shell"としてUEFIの設定画面から直ぐに利用できるマザーボードもあるが、"Launch EFI Shell from filesystem device"、あるいは"Launch Shell from device"などと表示されるマザーボードの場合、予めUSBメモリにshellx64.efiを置いておかなければならない。
このEFI Shellであるshellx64.efiの入手は、ほとんどの場合、tianocoreというUEFIのオープン・ソース・コミュニティが提供するEDK IIというUEFIの開発環境に含まれているShell.efiをダウンロードすることによってなされているようである。
開発者にはリポジトリ・ホスティング・サイトとしてお馴染みであろうGitHubの以下のWebページを開き、
https://github.com/tianocore/edk2/tree/master/ShellBinPkg/UefiShell/X64
そこのShell.efiをダウンロードする。これをshellx64.efiというファイル名に書き換えて、FAT32にフォーマットしたUSBメモリのパーティションのルートディレクトリに置いておくのである。
しかし、UEFI設定画面に"Launch EFI Shell from filesystem device"、または"Launch Shell from device"といったEFI Shellを起動する項目がなければ、USBメモリにshellx64.efiとして置いていたとしても、そのままではEFI Shellを開くことはできない。後述するように、USBメモリのパーティションをFAT32でフォーマットし、\efi\bootのディレクトリを作成し、その中にshellx64.efiをbootx64.efiというファイル名に変更して置いておき、Boot Menu等から当該USBメモリ（「UEFI:」などと表示される）を選択して起動すれば、EFI Shellを実行することができる。
コマンドやパラメータの詳細は、UEFI Forumの"Specifications"にある"UEFI Shell Specification"をご覧頂きたい。各メーカーもサイトでコマンドの説明を行っており、特にHPは、日本語によるUEFI Shellコマンドの詳細な解説を「HPE ProLiant Gen10 サーバーおよび HPE Synergy 用 UEFI シェルユーザーガイド」などで公開している。ただし、このユーザーガイドには Hewlett Packard Enterprise (HPE) が独自に追加したカスタムコマンドも含まれており、当然それを一般のUEFI Shellで使うことはできない。
"Launch EFI Shell from filesystem device"をクリックすると、EFI Shellが起動する。その初期化の過程で、PCI deviceに対してマッピングが行われる。ファイルシステムが認識されたディバイスに対してパーティションごとに、fsという文字に0から順に番号が割り振られ、fs0、fs1、fs2、…というマッピング名が付けられる。と同時に、ファイルシステムに関係なく全てのPCI deviceには、block deviceとして、blk0、blk1、blk3、…とマッピング名が付与される。これらが標準のマッピング名としてコマンド等で使用されることになる。EFI Shellのversion 1.0では番号は16進数であったが、今使っているversion 2.1では10進数に変更されている。マッピングの表示も、version 2.1では簡潔なものとなっている。私のマシンでは、fs6及びblk17までマッピングされている。
○ 一般的なコマンド、cd、ls/dir、rm/del、cp/copy、mkdir/md等が使える。helpでコマンドの一覧も表示される。大文字と小文字は区別されない。特定のコマンドの詳細な説明は、
Shell> help [コマンド名]
Shell> ? [コマンド名]
Shell> [コマンド名] -?
いずれでも表示される。注意点やパラメータの使用例なども示されており、便宜である。
また、
Shell> help [コマンド名] -b
と、-b のパラメータを使うと、一画面ごとに表示が停止されるので便利である。これは大量の情報が表示されることが想定されるコマンドでは使用できるようになっている。また、Page UP、Page Downキーで画面を上下させることができる。ただし、4画面までしか戻れない。
○ 現在のディレクトリを特定のマッピングされたファイルシステム、例えば、fs0に変更するには、
Shell> fs0:
FS0:\>
とする。ただし、この時点では、キーボードが英語配列（USキーボード）として認識されているので、
[:]を入力するには、Shift＋;キーを、
[\（バックスラッシュ）]を入力するには、]キーを、
[*]を入力するには、Shift＋8キーを、
["]を入力するには、Shift＋:キーを押さなければならない。
○ ディレクトリやファイルをコピーする場合、例えば、fs1にある全てのディレクトリ（フォルダ）をfs0にあるbackupというディレクトリにコピーするときは、ワイルドカード、*を使って、
FS0:\> cp -r fs1:\* backup
とする。
ただし、日本語の全角文字は識別されないので、名前に全角文字を含むディレクトリやファイルは指定することができない。その場合は、その親ディレクトリをコピーするか、ワイルドカードを使って全てのディレクトリやファイルをコピーするほかない。
○ ディレクトリ名やファイル名の変更は、mvコマンドで行うことが可能である。例えば、fs1のルートディレクトリにあるosx64.efiをppapx64.efiに変更する場合には、
FS1:\> mv osx64.efi ppapx64.efi
○ バージョンを確認する場合、verが使える。
FS0:\> ver
UEFI Interactive Shell v2.1
EDK II
UEFI v2.31 (American Megatrends, 0x...)
このようにUEFI ShellのバージョンとUEFIのバージョンが表示される。UEFIのバージョンは、マザーボードのファームウェアとしてのUEFIのバージョンではなく、それが準拠しているUEFI仕様のバージョンである。UEFI仕様のバージョンの相違によって、UEFIの動作・振舞にかなりの違いを生ずる点もあるようである。UEFI仕様のバージョンを知る必要がある場合もあろう。
○ UEFI［Shell］アプリケーション（拡張子.efi）とUEFI Shellスクリプトファイル（拡張子.nsh）を実行することができる。OSローダもUEFIアプリケーションであるから、前述したESP内にあるbootx64.efiを指定するとWindowsを起動させることができる。
Shell> fs1:\efi\boot\bootx64.efi
FS1:\> efi\boot\bootx64.efi
絶対パス、相対パスどちらも使える。EFI Shellを終了するときは、exitを使わずに、このように直接Windowsを起動している。
また、このEFI Shellも、UEFIアプリケーションであるから、shellx64.efiをbootx64.efiにファイル名を変更し、USB等に\efi\boot\bootx64.efiとして置いておけば、電源投入後、UEFIによりNVRAMに自動的にエントリが作成され、Boot MenuやPlease select boot device画面に"UEFI: USB..."などと表示される。それを選択すれば、EFI Shellを起動することが可能であり、便利である。
○ EFI Shellのコマンドの中で最も有用なコマンドは、bcfgであろう。bcfgは、NVRAMに保存されているブート・オプションやドライバ・オプションを操作することができるコマンドである。bcfgコマンドは、バージョン1.0のEFI Shellにはない機能であり、バージョン2.0以降で使用することが可能となったようである。これであれば、OSを問わず使用できるので、Linuxのefibootmgrコマンドよりも便宜であると言えよう。詳細は、上記に示したUEFI Shell Specificationをご覧頂きたい。
・ NVRAM内のブート・エントリや順位などのブート・オプションを表示するには、
Shell> bcfg boot dump
・ ブート・オプションを追加するには、例えば、fs1:\EFI\test\にあるbootx64win.efiをブート順位3（先頭は0）に、Windows Loaderという表示名（Desc[ription] ）で追加する場合は、
Shell> bcfg boot add 3 fs1:\EFI\test\bootx64win.efi "Windows Loader"
として実行。すると、
Target = 0006.
bcfg: Add Boot0006 as 3
などとなり、BootXXXX変数は自動で割り振られる。順位3以降に既にブート・オプションが存在する場合は、それらは全て順位が1つ繰り下がることになる。
・ ブート・オプション、例えば順位4を削除する場合は、
Shell> bcfg boot rm 4
順位5以降は、順位が繰り上がる。
・ ブート・オプションの順位を、例えば2から6へ移動させるには、
Shell> bcfg boot mv 2 6
とする。順位3、4、5は、順位が繰り上がる。
・ ブート・オプション、例えば順位3の表示名を、「Emergency Loader」に変更する場合は、
Shell> bcfg boot mod 3 "Emergency Loader"
UEFI環境における各OSやマザーボード特有の振舞だけでなく、UEFI自体の振舞についても理解が進むにつれて、戸惑いや混乱は治まってきているようである。（2016.12.4）
なお、上の引用でも触れているように、32bitのWindowsでUEFIを使用する場合には注意が必要である。前掲の「UEFI and Windows」の7ページの"Note"にも、「32bit版のWindowsはUEFIの機能をサポートしない。64bit版のWindowsだけが、UEFIファームウェアによって可能となる機能を活用することができる。幸い、現行のUEFIの実装におけるCSM（ Compatibility Support Module）のおかけで、32bit OSその他のUEFIをサポートしないOSは、UEFIファームウェアを備えるハードウェア上で起動することが可能となっている。しかし、CSMが従来のBIOSをエミュレートするのであるから、CSMに起動を要求するOSはUEFI固有の機能を使用することはできない。」と説明されている。
UEFIに準拠したマザーボードで32bitのWindowsを使用する場合には、UEFIは名ばかりということになる。
【追記】：Windows 7とWindows Server 2008 R2では、64bit版においてのみUEFIをサポートしていたが、
「Windows 10デスクトップ エディション (Home、Pro、Enterprise、Education)、Windows Server 2016 Technical Preview、Windows 8.1、Windows 8 は、32ビット (x86)、64ビット (x64)、ARMベースのPCでネイティブのUEFI 2.0以降をサポート」（「UEFI ファームウェア」、MSDN）しているとなっている。
※ MBRとGPTについては、『「初期化」について』、「フォーマット、その2～論理フォーマット」も是非ご覧下さい。
四、
以上、UEFIの特徴と概略は分かったような気がするが、UEFIが、BIOSに比べ、素晴らしい申し分のないファームウェアであるからといって、BIOSが完全に不要となる訳ではないらしい。前掲のUnified EFI Forumのサイトの「About UEFI」のページには、
「UEFIは完全にBIOSに取って代わるのか」という問いに対して、「いいえ。UEFIは、ブート・サービスとランタイム・サービスのために異なるインターフェイスを使うが、しかし一方では、BIOSがシステム構成（「Power On Self Test」または「POST」とも呼ばれる）とセットアップのために用いる機能を、プラットフォーム・ファームウェアが実行しなければならない場合もある。UEFIはPOSTとセットアップがどのように実装されるかに関する仕様を定めるものではない。」と答えている。
UEFIが完全にBIOSに取って代わるというものではなく、BIOSが受け持っていた機能の一部は、プラットフォームのファームウェアが担っているようである。UEFI準拠のマザーボードであっても、そのファームウェアが「BIOS」あるいは「UEFI BIOS」と呼ばれているのは、単に便宜上という訳でもないのである。
ウェブでUEFIについて調べていると、UEFIについて私と同様の誤解ないし勘違いをしている文章に出くわす。例えば、64bitのWindows7でUEFIを使っているにもかかわらず、起動上のドラブルの原因がMBRにあるのではと疑っている、といったような。
※ なお、MBRのディスクにBIOSモードでインストールされている64bit WindowsをUEFIモードのGPTディスクに簡単に移行させるソフトが、Paragonのサイトから入手できる。Migrate to UEFIというソフトであるが、現在（2013年4月14日）、Paragon Early Adopter Programに参加登録すると無料で利用することができる。
但し、正式発売前のソフトですので、そのプログラム参加申込みページの契約書に必ず目を通し、同意することができる場合にのみ、お試し下さい。
この一文がUEFIの概要を知る一助となれば幸いである。
【2013年3月27日】
【追記】
最近、UEFI仕様（バージョン2.3.1）の中の規格の一つであるSecure Bootが問題となっているようである。
Secure Bootとは、「ハードウェアによって検証された、マルウェアのない オペレーティング システム (OS) ブートストラップを可能とし、システム実装時のセキュリティを向上させ 」るものだそうである（「オープン プラットフォームにおける UEFI Secure Boot への対応」、The Linux Foundation）。このLinux Foundationのホワイトペーパーによると、Secure Bootの仕組みは、概略、以下のようになる。
UEFI仕様のSecure Bootに関するセクションは、プラットフォーム鍵（Platform Key, PK）と鍵交換鍵（Key Exchange Key, KEK）を定義している。プラットフォーム鍵はハードウェアの所有者が管理し、鍵交換鍵は、OSベンダー等が管理することになっているが、公開鍵と秘密鍵がペアとなっており、公開鍵だけで署名データーベース内にインストールすることができるように設計されている。
鍵交換鍵及びプラットフォーム鍵がインストールされていない状態をSetupモードとし、その段階ではブート可能なOSは限定されない。初回のOSのブート時に鍵交換鍵及びプラットフォーム鍵がインストールされるとSecureモードに切り替わり、署名データーベースの鍵交換鍵によってOSの認証がなされ、原則として、OSを変更したり、他のOSを追加することはできなくなる。
このようにしてOSの権利保護が図られることになる。
この場合、ベンダーが、PCをSetupモードで出荷し、また任意にSetupモードに戻すことができるようにし、さらに新たな鍵交換鍵を追加する手段を提供するならば、知的財産権の対象となるOSの使用許諾条項に抵触することなく、オープンOSの使用が可能となる、というのである。
ところが、UEFI 仕様はかなり難解で、2,139ページもあるためか、ハードウェア・ベンダーやWindowsをプリインストールしたPCを製造するメーカーの中には、必ずしもこの仕様を守っていないものもあるらしいのである。そうなると、Windowsは起動できるが、その他のOSをインストールして起動させることは不可能ということにもなる。彼等にしてみれば、Windowsさえ起動できればよいのであって、他のOSの動作まで保証してはいないのだから、ということになる。
この問題については、UEFI Secure BootやMicrosoft側を非難する文もウェブにはあるようだが、ハードウェア・ベンダーないしPCメーカー側がUEFIの仕様に従ってSecure Bootを正しく実装していない点にその主な原因があることも少なくないようである。
そこで、UEFI準拠のWindows搭載PCにおいてLinux系のOSを起動させるために、Linux FoundationはMicrosoftから提供を受けたLinux Foundation UEFI secure boot systemを公開している。競争関係にある両者の間でどのような話し合いがもたれたかはもちろん不明だが、その公開はLinux Foundationのテクニカル・アドバイザリ・ボードのメンバーであるJames Bottomleyのウェブサイトで行われるという形を今のところとっている。
FedoraやUbuntuについては試しに使ったことがあるという程度の知識しかなく、プログラミングについてはほとんど無知に等しいので、LinuxとSecure Bootの詳細については、前掲のLinux Foundationのホワイトペーパーの他に、James Bottomley's random Pages、「UEFIとLinuxの現状」（本の虫）、「セキュアブートと制限ブートの違いについて」（本の虫）等をご覧下さい。
※ 【追記】： Secure BootとCSMの関係で注意すべきこと
両者の関係について、MSDNの文書には、「CSM を使うには、セキュア ブートを無効にする必要があります。」（「UEFI ファームウェア」）と書かれている。
また、UEFIクラス2（CSMを使って従来のBIOS互換モードで機能することが可能なUEFI実装をいう）のPCにおいては、セキュアブートが有効になっている場合、承認されたUEFIベースのOSのみを起動させるためには、CSMを無効にしなければならないとも、説明されている（"Secure Boot"）。従って、承認されたUEFIベースのOSのみを起動する場合でなければ、このSecure Bootは無効にしておいてよいのではなかろうか。マルチブートでSecure Bootに対応していないOSが含まれている場合、Secure Bootは無効にするほかなかろう。（2017.1.8）
両者の関係について、MSDNの文書には、「CSM を使うには、セキュア ブートを無効にする必要があります。」（「UEFI ファームウェア」）と書かれている。
また、UEFIクラス2（CSMを使って従来のBIOS互換モードで機能することが可能なUEFI実装をいう）のPCにおいては、セキュアブートが有効になっている場合、承認されたUEFIベースのOSのみを起動させるためには、CSMを無効にしなければならないとも、説明されている（"Secure Boot"）。従って、承認されたUEFIベースのOSのみを起動する場合でなければ、このSecure Bootは無効にしておいてよいのではなかろうか。マルチブートでSecure Bootに対応していないOSが含まれている場合、Secure Bootは無効にするほかなかろう。（2017.1.8）
【2013年3月31日】
【追記】
従来のBIOSとの違いで戸惑うことの一つが起動順序の設定である。
BIOSでは、OSの入っているドライブに優先してFloppy DriveやCD ROMを先順位に設定しておくことができた。しかし、UEFIでは、Windowsをインストールした場合、「Windows Boot Manager」がBoot Option Prioritiesの第１位に表示され、これを後順位に変更してしまうと、先順位に何らかの起動可能なディバイスがなければ、「Reboot and Select proper Boot device or Insert Boot Media in selected Boot device and press a key_」と表示されたままブート・プロセスが停止してしまう。従って、「Windows Boot Manager」などの起動可能なOSローダやディバイスを起動順位の第１位にしておく必要がある。
一時的にFloppy DriveやCD ROMから起動したい場合は、電源投入直後にBoot Menuを表示させて該当ディバイスを選択することになる。
因みに、BIOSやUEFIメニューにある「BBS Priorities」のBBSとは、「BIOS Boot Specification」の略であり、その内容については、Compaq、Phoenix、Intelの３社が連名で公開している「BIOS Boot Specification Version 1.01 January 11, 1996」という仕様書をご覧下さい。この仕様書は、BIOSがシステムのすべての初期プログラムロード (Initial Program Load：IPL) ディバイスを識別し、ユーザが選択した順序でそれらに優先順位をつけ、さらにそれぞれのディバイスに対して起動を試みる方法を記述したものであると、その５ページの「1.3 Purpose」という項に記載されている。
【2013年5月23日】
tag : UEFIEFIBIOSBootManagerBootmgrBootmgfwConfigurationDatabaseBCD
