本文是我翻譯自國外技術(shù)博客的一篇文章，其中講述了 UEFI 的一些基本概念和細(xì)節(jié)。
本文的原始鏈接位于： https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/
本人的翻譯水平有限，難免多有疏漏。廢話不多說，請看正文：
又到 AdamW 的講課時間了，如果你不想聽我的長篇大論，那么請出門右拐。
Kamil Paral 說我有 寫作癖 ，知道自己的壞習(xí)慣也是件好事。
可能你已經(jīng)在互聯(lián)網(wǎng)上閱讀過有關(guān) UEFI 的大量資料。但是有一些重要事項需要了解：這些資料中的 95% 都毫無價值。如果你認(rèn)為你已經(jīng)對 UEFI 有所了解，但是如果你的知識來源并不可靠，那么所掌握的知識就不過是一堆誤解、謬論、一己之見、信口開河和彌天大謊。先把這些都忘了吧。如果想真正了解有關(guān) UEFI 的權(quán)威知識，不妨訪問 UEFI 規(guī)范、 mjg59 的博客 、其他靠譜一點的文章/權(quán)威人士——包括 Rod Smith 、 Peter Jones 、Chris Murphy，或者閱讀一些小眾操作系統(tǒng)的文檔，前提是這些操作系統(tǒng)的開發(fā)人員確實了解 UEFI。
好，準(zhǔn)備工作做完了。我主要想討論啟動加載，因為對于大多數(shù)用戶而言，固件在其中扮演著重要角色，同時，不少網(wǎng)站也針對這一過程喋喋不休，由此產(chǎn)生不少誤解。
首先，我們了解一些術(shù)語。 BIOS 和 UEFI 都是計算機(jī)的 固件 類型。BIOS 固件（主要）用于 IBM PC 兼容計算機(jī) 。UEFI 的通用性更強(qiáng)，可用在非“IBM PC 兼容”系列的計算機(jī)上。
不存在“UEFI BIOS”。沒有任何一臺計算機(jī)會有“UEFI BIOS”。請不要再說“UEFI BIOS”。BIOS 不是所有 PC 固件的通用術(shù)語，它只是 PC 固件的一種特定類型。計算機(jī)中包含固件。如果你有一臺 IBM PC 兼容計算機(jī)，那么固件幾乎肯定就是 BIOS 或 UEFI。如果你運(yùn)行的是 Coreboot ，那么恭喜，你是個例外，引以為傲吧。
安全啟動 (Secure Boot) 與 UEFI 不是同一個概念。請不要將這些術(shù)語混淆使用。安全啟動 (Secure Boot) 實際上是 UEFI 規(guī)范的一項可選功能，于 UEFI 規(guī)范版本 2.2 引入。我們稍后會詳細(xì)討論安全啟動 (Secure Boot) 到底是什么，但是目前而言，只需要記住它和 UEFI 不同即可。你需要區(qū)分安全啟動 (Secure Boot) 和 UEFI 的差異，在任何場合，你都應(yīng)當(dāng)了解你實際上討論的是其中哪一個。我們首先討論 UEFI，然后我們將把安全啟動 (Secure Boot) 作為 UEFI 的一項“擴(kuò)展”來進(jìn)行討論，因為這就是安全啟動 (Secure Boot) 的本質(zhì)。
注釋：UEFI 不是由微軟開發(fā)的，也從來不受微軟控制。它的前身和基礎(chǔ)——EFI，是由 Intel 開發(fā)和發(fā)布的。UEFI 由 UEFI 論壇 進(jìn)行管理。微軟是 UEFI 論壇的成員之一。Red Hat、Apple、幾乎所有主要 PC 制造商、Intel（顯然）、AMD 和 一大批其他主要和次要硬件、軟件和固件公司及組織 也都是 UEFI 論壇的成員。UEFI 是一套業(yè)已達(dá)成廣泛共識的規(guī)范，其中當(dāng)然也包含各種混亂（我們稍后會專門討論其中一部分）。UEFI 并不由任何一家公司獨裁掌控。
如果想真正了解 UEFI，閱讀 UEFI 規(guī)范是個不錯的方法。這件事并不難，也不需要什么代價。閱讀 UEFI 規(guī)范相當(dāng)枯燥乏味，但是會讓你受益匪淺。你可以從 官方 UEFI 網(wǎng)站 下載 UEFI 規(guī)范。盡管下載 UEFI 規(guī)范需要先同意某些條款和條件，但是不會帶來損失。在我撰寫本文時，UEFI 規(guī)范的最新版本是 2.4 Errata A （譯者注：現(xiàn)在更新到了 2.4 Errata B ），本文所寫內(nèi)容也基于這一版本。
BIOS 沒有制定相應(yīng)規(guī)范。BIOS 本身就是一項事實標(biāo)準(zhǔn)，從 20 世紀(jì) 80 年代開始，BIOS 的工作方式就一成不變。這也是誕生 UEFI 的原因之一。
簡單起見，我們可以把 BIOS 和 UEFI 看成兩種不同的組合。其中一種是 UEFI和 GPT （我們稍后會討論 GPT）產(chǎn)生之前，IBM PC 兼容計算機(jī)（以下稱為 PC）所廣泛采用的組合。大部分人可能對這種組合非常熟悉，對其中的細(xì)節(jié)了如指掌。那么我們就先來討論在具有 BIOS 固件的 PC 上，啟動是如何工作的。
事實上，BIOS 啟動的工作原理非常非常簡單。在老式 BIOS PC 上，裝有一個或多個磁盤，每個磁盤中包含 MBR 。MBR 是另一套事實標(biāo)準(zhǔn)；大體而言，磁盤起始位置以特定格式描述磁盤上的分區(qū)，并包含“啟動裝載程序 (boot loader)”，BIOS 固件知道如何執(zhí)行這一小段啟動裝載程序代碼。啟動裝載程序的職責(zé)是啟動操作系統(tǒng)（現(xiàn)代啟動裝載程序的大小通常超出了 MBR 空間所能容納的范圍，因此必須采用多階段設(shè)計，其中 MBR 部分只知道如何從其他位置加載下一階段，我們現(xiàn)在先不著重討論這一過程）。
在啟動系統(tǒng)的過程中，BIOS 固件只能識別系統(tǒng)包含的磁盤。而作為 BIOS 計算機(jī)的擁有者，你可以告訴 BIOS 固件你想從哪個磁盤啟動系統(tǒng)。而固件本身并不知道其他細(xì)節(jié)，它只會執(zhí)行在指定磁盤的 MBR 部分所發(fā)現(xiàn)的啟動裝載程序，就這么回事。在執(zhí)行啟動裝載程序之后，固件本身就不再參與啟動。
在 BIOS 組合中，所有的多重啟動形式都肯定是在固件層上進(jìn)行處理的。固件層無法真正識別啟動裝載程序或操作系統(tǒng)，甚至連分區(qū)都無法識別。固件所能執(zhí)行的操作只是從磁盤的 MBR 中運(yùn)行啟動裝載程序。你無法從固件外部配置啟動過程。
好，BIOS 組合的背景知識已經(jīng)明確了。我們現(xiàn)在來看看 UEFI 計算機(jī)上的啟動原理。即使未掌握本文的細(xì)節(jié)，也請記住這一點：UEFI 與 BIOS 完全不同。UEFI 啟動原理與 BIOS 絕對不同。你不能把 BIOS 啟動的原理直接套用到原生 UEFI 啟動上。你不能把專為 BIOS 啟動設(shè)計的工具應(yīng)用到原生 UEFI 啟動的系統(tǒng)上。記住，UEFI 組合完全不同。
還需要了解一個重點：許多 UEFI 固件實現(xiàn)了某種 BIOS 兼容模式（有時候稱為 CSM）。許多 UEFI 固件可以像 BIOS 固件一樣啟動系統(tǒng)，它們可以查找磁盤上的 MBR，然后從 MBR 中執(zhí)行啟動裝載程序，接著將后續(xù)工作完全交給啟動裝載程序。有時候，其他人誤將此功能稱為“禁用 UEFI”，從語言學(xué)角度而言，這種說法是荒謬的。系統(tǒng)固件是無法“禁用”的。這種說法很愚蠢，不要采用這種說法。但是在其他人這么說的時候，應(yīng)該了解他們真正想表達(dá)什么。他們討論的是通過 UEFI 固件的一項功能，以“BIOS 風(fēng)格”啟動系統(tǒng)，而不是采用原生 UEFI 方式啟動系統(tǒng)。
我想解釋一下原生 UEFI 啟動。如果你有一臺基于 UEFI 的計算機(jī)，其固件具有 BIOS 兼容功能，并且你打算一直使用這項兼容功能，在啟動過程中，你的計算機(jī)看起來就是基于 BIOS 的。你只需要像 BIOS 啟動一樣進(jìn)行所需操作即可。如果你確實有此打算，那么就不要中途變卦。對于你日常使用的操作系統(tǒng)，強(qiáng)烈建議不要混合使用原生 UEFI 啟動和 BIOS 兼容啟動，尤其不要在同一塊磁盤上混用。這么做的話，你會痛不欲生。如果你決定混合使用原生 UEFI 啟動和 BIOS 兼容啟動，到時候就別找我哭訴。
為了理清頭緒，我將假設(shè)磁盤采用 GPT ，并且包含用于 EFI 的 FAT32 EFI 系統(tǒng)分區(qū) (ESP)。根據(jù)你對這些知識的深入程度，你可能發(fā)現(xiàn)，在進(jìn)行原生 UEFI 啟動時，GPT 磁盤和 EFI FAT32 ESP 并不是必要條件。但是 UEFI 規(guī)范和 GPT 磁盤以及 EFI FAT32 ESP 的聯(lián)系程度相當(dāng)密切。在99%的情況下，你要處理的也正是這樣的組合。除非你在使用 Mac（老實說，Mac 混亂不堪）。
編輯說明：以下章節(jié)（到缺陷為止）在 2014 年 1 月 26 日（本文發(fā)布的幾小時后）根據(jù) Peter Jones 的反饋進(jìn)行了大量修訂。本文可視為 v2.0 版本。早期版本的寫作方式不夠嚴(yán)謹(jǐn)，而且內(nèi)容可能會產(chǎn)生誤解。
言歸正傳。本節(jié)將解釋原生 UEFI 啟動的實際工作原理。如果已掌握一定程度的背景知識，可能更容易深入理解本節(jié)內(nèi)容。
在固件層，UEFI 的基礎(chǔ)架構(gòu)更豐富，可用于處理系統(tǒng)啟動。UEFI 遠(yuǎn)不像BIOS 那么簡單。與 BIOS 不同，UEFI 確實可以（不同程度上）理解“磁盤分區(qū)”、“啟動裝載程序”以及“操作系統(tǒng)”的概念。
你可以稍微看看 BIOS 啟動過程，然后再看看 UEFI 啟動過程，了解 UEFI 啟動過程如何采用多種措施來解決特定問題。
在思考啟動過程時，你會發(fā)現(xiàn) BIOS/MBR 查找啟動裝載程序的方法實在不怎么樣。BIOS/MBR 非常奇葩：位于磁盤起始位置的這一小段空間包含神奇代碼 (magic code)，而這段神奇代碼只作用于系統(tǒng)固件和寫入此神奇代碼的工具。這種方法有許多問題。
可以想象，在 UEFI 設(shè)計之初，開發(fā)人員思考過這些問題，并最終提出解決方案。UEFI 固件并不僅僅可以識別磁盤，它也知道啟動裝載程序代碼在每個磁盤上所處的位置，而且在固件層，UEFI 的基礎(chǔ)架構(gòu)更豐富，可用于處理啟動裝載。接下來，我們討論下 UEFI 規(guī)范中定義的相關(guān)內(nèi)容。
UEFI 規(guī)范定義了一種可執(zhí)行文件格式，并要求所有 UEFI 固件能夠執(zhí)行此格式的代碼。當(dāng)開發(fā)人員為原生 UEFI 編寫啟動裝載程序時，就必須按照這種格式編寫。這種設(shè)計非常簡潔直觀，也無需進(jìn)一步解釋：對于固件可以執(zhí)行的代碼，固件規(guī)范真正定義了其通用格式，這是件好事。
GUID 分區(qū)表格式與 UEFI 規(guī)范具有密切聯(lián)系，而且，它并不特別復(fù)雜，無需多加解釋。GPT 是 UEFI 規(guī)范提供的良好基礎(chǔ)架構(gòu)之一。GPT 僅僅是分區(qū)表的一種標(biāo)準(zhǔn)——磁盤起始位置的信息定義了磁盤所包含的分區(qū)。相比 MBR/MS-DOS 分區(qū)表，這種分區(qū)表對分區(qū)的定義要好得多，并且 UEFI 規(guī)范要求 UEFI 兼容固件必須能識別 GPT（也要求固件能識別 MBR，以保證向后兼容）。所有這些規(guī)范都是相當(dāng)實用的基礎(chǔ)架構(gòu)： UEFI 規(guī)范正建立某些功能，固件層上的一切都可依靠固件本身來實現(xiàn)這些功能。
在修訂本文時，我才真正思考 EFI 系統(tǒng)分區(qū)的概念，讓我有如醍醐灌頂。實際上，“EFI 系統(tǒng)分區(qū)”的概念可以解決“奇葩”的 MBR 空間所產(chǎn)生的問題。在磁盤起始位置留出自由空間，用于存放啟動裝載程序代碼，但又不定義其容量，種設(shè)計糟糕透頂。這一點在上文已經(jīng)討論過了。EFI 系統(tǒng)分區(qū)是 UEFI 用于解決這種問題的解決方案。1
具體的解決方案如下：我們要求固件層能夠讀取某些特定的文件系統(tǒng)類型。UEFI 規(guī)范要求兼容固件必須能讀取 FAT 格式的變種（包括 FAT12、FAT16 和 FAT32）。UEFI 規(guī)范實際扮演的角色就是編纂整理 FAT 文件系統(tǒng)格式的現(xiàn)有解釋，確保在采用 UEFI 時可以使用那些格式，并規(guī)定 UEFI 兼容固件必須能夠讀取那些格式。UEFI 規(guī)范針對這方面的具體規(guī)定如下：
“可擴(kuò)展固件接口 (EFI) 支持的文件系統(tǒng)基于 FAT 文件系統(tǒng)。EFI 定義了可以明確記錄和測試的具體 FAT 版本。FAT 的唯一定義必須符合 EFI 規(guī)范及關(guān)聯(lián)參考文檔，對 FAT 唯一定義的實現(xiàn)必須支持 EFI。為區(qū)分 EFI 文件系統(tǒng)與純 FAT，定義了新的分區(qū)文件系統(tǒng)類型?！?/p>
“EFI 系統(tǒng)分區(qū)”是采用 FAT 變種（UEFI 規(guī)范定義的變種之一）格式化的任意分區(qū)，該分區(qū)被賦予特定 GPT 分區(qū)類型，以幫助固件識別該分區(qū)。此分區(qū)的目的如上所述：固件層確實可以讀取“普通”磁盤分區(qū)中的數(shù)據(jù)。希望我已明確解釋為何這種設(shè)計更佳：操作系統(tǒng)可以創(chuàng)建、格式化和掛載分區(qū)（采用廣泛理解的格式），并將啟動裝載程序的代碼和固件可能需要讀取的所有其他內(nèi)容放到這個分區(qū)中，而不用像 MBR 磁盤一樣，將啟動裝載程序的代碼寫入磁盤的起始位置空間。
剛開始的時候，對我而言，整個 ESP 的設(shè)計看起來有點匪夷所思且令人困惑，因此我希望本節(jié)可以解釋為何 ESP 實際上是非常優(yōu)秀的設(shè)計——真正匪夷所思和令人困惑的設(shè)計是 BIOS/MBR。若要從操作系統(tǒng)層寫入某些內(nèi)容，唯一的方法是將這些內(nèi)容寫入磁盤起始位置的某部分（但不知道是多少）空間，而并沒有具體規(guī)定其中的具體實現(xiàn)。如果回過頭再看，這種設(shè)計并不明智，且難以理解。
正如我們稍后會強(qiáng)調(diào)的那樣，UEFI 規(guī)范試圖采用更直觀嚴(yán)格的方法——它很少禁止固件執(zhí)行其他操作。UEFI 規(guī)范并不反對編寫固件，用于執(zhí)行以其他格式寫成的代碼、讀取其他類型的分區(qū)表，以及讀取用UEFI 變種文件系統(tǒng)（非 FAT）格式化的分區(qū)。但是 UEFI 兼容固件必須至少能夠?qū)崿F(xiàn)執(zhí)行 EFI 可執(zhí)行文件、讀取 GPT 分區(qū)表、以及讀取 ESP，因此如果你正編寫操作系統(tǒng)或其他東西，并且想要在 UEFI 兼容固件上運(yùn)行的話，你也得遵循 UEFI 規(guī)范，這就是 EFI 系統(tǒng)分區(qū)的概念非常重要的原因：它允許（至少理論上）將 EFI 可執(zhí)行文件放在以 UEFI FAT 格式化且 GPT 分區(qū)類型正確無誤的分區(qū)上，另外，系統(tǒng)固件要能夠讀取該分區(qū)。這種機(jī)制非常嚴(yán)謹(jǐn)，等價于 BIOS 中的“固件能夠執(zhí)行放置在 MBR 空間中的啟動裝載程序代碼”。
UEFI 規(guī)范為我們提供了三大重要基礎(chǔ)，這些重要基礎(chǔ)是上層架構(gòu)正常運(yùn)行的立足之本：
相比 BIOS 固件所提供的功能，UEFI 的功能要豐富得多。但是，為了完成固件層可以處理多重目標(biāo)（而不僅僅是磁盤）啟動的愿景，我們需要其他基礎(chǔ)：需要建立一種機(jī)制，通過這種機(jī)制，固件可以查找各種可能的啟動目標(biāo)，并提供相應(yīng)的配置方法。
UEFI 規(guī)范定義了名為 UEFI 啟動管理器的一項功能（Linux發(fā)行版包含名為efibootmgr 的工具，可用于更改 UEFI 啟動管理器的配置）。如果你確實閱讀過 UEFI 規(guī)范，那么就會發(fā)現(xiàn)，UEFI 規(guī)范對 UEFI 啟動管理器作出了如下規(guī)定：
“UEFI 啟動管理器是一種固件策略引擎，可通過修改固件架構(gòu)中定義的全局NVRAM 變量來進(jìn)行配置。啟動管理器將嘗試按全局 NVRAM 變量定義的順序依次加載 UEFI 驅(qū)動和 UEFI 應(yīng)用程序（包括 UEFI 操作系統(tǒng)啟動裝載程序）?！?/p>
好，既然已經(jīng)明確了這一概念，那我們就繼續(xù)吧。不，先等等。我來先把那一項規(guī)定解釋清楚，便于理解。簡單來說，你可以把 UEFI 啟動管理器視為啟動菜單。在 BIOS 固件上，固件層的“啟動菜單”（當(dāng)然）是，啟動時連接到計算機(jī)的各個磁盤——不多不少。但是對于 UEFI 固件而言，情況有所不同。
UEFI 啟動管理器可以進(jìn)行配置——簡言之，你可以向“啟動菜單”添加項或者從中刪除項。固件也可以（事實上， UEFI 規(guī)范也有此要求）根據(jù)連接到計算機(jī)的磁盤或根據(jù)某些固件配置，在此啟動菜單中“生成”有效項。你也可以檢查啟動菜單，確保正確無誤。
UEFI 提供了一種非常優(yōu)秀的機(jī)制，可以從上層架構(gòu)執(zhí)行此操作：你可以從已啟動的操作系統(tǒng)中配置系統(tǒng)啟動行為。如果已通過 UEFI 啟動 Linux，就可以使用 efibootmgr 工具來完成所有這些操作。Windows 也有相應(yīng)的工具，但是我對 Windows 下的工具非常不熟悉。我們不妨看一些典型的 efibootmgr 輸出，這些是我從 Fedora 論壇轉(zhuǎn)過來的，稍微進(jìn)行了調(diào)整：
[root@system directory]# efibootmgr -vBootCurrent: 0002Timeout: 3 secondsBootOrder: 0003,0002,0000,0004Boot0000* CD/DVD Drive BIOS(3,0,00)Boot0001* Hard Drive HD(2,0,00)Boot0002* Fedora HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\fedora\grubx64.efi)Boot0003* opensuse HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\opensuse\grubx64.efi)Boot0004* Hard Drive BIOS(2,0,00)P0: ST1500DM003-9YN16G .[root@system directory]#
這個示例非常清晰。我們可以從中觀察細(xì)節(jié)。
第一行表示，目前你從“啟動菜單”的哪個項進(jìn)行了啟動。第二行非常明顯（如果固件的 UEFI 啟動管理器顯示了類似啟動菜單的界面，那么這一行表示繼續(xù)啟動默認(rèn)項之前的超時）。BootOrder 是列表中啟動項的嘗試順序。其余輸出顯示了實際的啟動項。我們稍后會說明每一個啟動項具體作用。
如果完全正常啟動 UEFI 固件，而不進(jìn)行任何調(diào)整（我們稍后會討論），UEFI 固件將按照BootOrder 中列出的順序，嘗試從“啟動菜單”中的每個“項”進(jìn)行啟動。因此，在這臺計算機(jī)上，UEFI 固件將嘗試啟動名為“opensuse”的項，如果啟動失敗，然后再嘗試啟動名為“Fedora”的項，然后再是“CD/DVD Drive”，接著是第二項“Hard Drive”。
那么，這些項的實際含義是什么？實際上，UEFI 規(guī)范之所以顯得復(fù)雜，很大程度上是因為其中的不確定因素太多。如果你正在閱讀 UEFI 規(guī)范，那么先做好心理準(zhǔn)備，然后前往 EFI_DEVICE_PATH_PROTOCOL 一節(jié)。但是請注意，這個協(xié)議是通用的，雖然這個協(xié)議不涉及啟動過程，但是有其他作用——這實際上就是 UEFI 官方的設(shè)備標(biāo)識方法，這種標(biāo)識方法可用于啟動管理器項以及各種其他用途。出于各種原因，并不是每一種潛在的 EFI 設(shè)備都像 UEFI 啟動管理器項一樣起作用（如果你想從視頻適配器啟動，很可能不會成功）。但是啟動菜單中顯然可以包含指向 PXE 服務(wù)器（而不是磁盤分區(qū)）的項。UEFI 規(guī)范進(jìn)行了多項規(guī)定，可以向 UEFI 啟動管理器配置中添加除磁盤以外的啟動目標(biāo)。
但是對我們而言，只需要考慮連接到計算機(jī)的一般磁盤即可。既然這樣，我們來討論下可能遇到的三種啟動項類型。
在本示例中，Boot0000 和 Boot0004 實際上是 BIOS 兼容模式啟動項，而不是原生 UEFI 啟動項。這些啟動項不是通過外部工具添加到 UEFI 啟動管理器配置中的，而是由固件本身生成的——這也是 UEFI 固件實現(xiàn) BIOS 兼容啟動的常見方式，通過生成 UEFI 啟動管理器項，可觸發(fā)指定設(shè)備的 BIOS 啟動。至于 UEFI 啟動管理器如何呈現(xiàn)給用戶，這是另一個問題，我們稍后討論。根據(jù)具體固件及其配置，其中有些項可能無法顯示。每一項只會具有一個名稱（“CD/DVD Drive”、“Hard Drive”），這表示“如果選中此項，那么就以 BIOS 兼容模式啟動本磁盤”（其中，對于 Boot0000，“本磁盤”為 3,0,00，對于 Boot0004，“本磁盤”為 2,0,00）。
Boot0001 項（我虛構(gòu)的，實際操作中可能不存在，這里只是為了舉例說明）用于通知固件嘗試從特定磁盤啟動（以 UEFI 模式而不是 BIOS 兼容模式），但是并沒有向固件提供其他信息。它沒有指定磁盤上的具體啟動目標(biāo)，而只是讓固件啟動磁盤。
UEFI 規(guī)范定義了一種“回退”路徑 (Fallback path)，用于啟動此類啟動管理器項，其工作原理類似于 BIOS 驅(qū)動器啟動：它會在標(biāo)準(zhǔn)位置查找某些啟動裝載程序代碼。但是其中的細(xì)節(jié)和 BIOS 不同。
當(dāng)嘗試以這種方式啟動時，固件真正執(zhí)行的操作相當(dāng)簡單。固件會遍歷磁盤上的每個 EFI 系統(tǒng)分區(qū)（按照磁盤上的分區(qū)順序）。在 ESP 內(nèi)，固件將查找位于特定位置的具有特定名稱的文件。在 x86-64 PC 上，固件會查找文件 \EFI\BOOT\BOOTx64.EFI。固件實際查找的是 \EFI\BOOT\BOOT{計算機(jī)類型簡稱}.EFI，其中，“x64”是 x86-64 PC 的“計算機(jī)類型簡稱”。文件名還有可能是 BOOTIA32.EFI (x86-32)、BOOTIA64.EFI (Itanium)、BOOTARM.EFI（AArch32，即32位ARM）和 BOOTAA64.EFI（AArch64，即64位ARM）。然后，固件將執(zhí)行找到的第一個有效文件（當(dāng)然，文件需要符合UEFI規(guī)范中定義的可執(zhí)行格式）。
這種機(jī)制的設(shè)計目的不在于啟動日常使用的操作系統(tǒng)。它的設(shè)計目的更像是為了啟動可熱插拔、與設(shè)備無關(guān)的介質(zhì)（如 Live 映像和操作系統(tǒng)介質(zhì)）。這也是這種機(jī)制的常見用途。如果查看 Linux 或其他操作系統(tǒng)的 UEFI 兼容 Live 或安裝介質(zhì)，你會發(fā)現(xiàn)其中包含 GPT，以及位于（或靠近）設(shè)備起始位置的 FAT 分區(qū)，該分區(qū)的 GPT 分區(qū)類型標(biāo)識為 EFI 系統(tǒng)分區(qū)。在那個分區(qū)中，會有一個 \EFI\BOOT 目錄，目錄中至少包含上述特殊命名的文件之一。當(dāng)以原生 UEFI 模式啟動 Fedora Live 或安裝介質(zhì)時，就會采用這種機(jī)制。BOOTx64.EFI（或其他）文件將處理剩余啟動過程，從而啟動介質(zhì)上包含的真正操作系統(tǒng)。
Boot0002 和 Boot0003 是存儲設(shè)備上所安裝操作系統(tǒng)的“典型”項。這些項顯示了 UEFI 啟動機(jī)制的全部優(yōu)勢，不僅僅是“從此磁盤啟動”，而是“啟動此特定磁盤上此特定位置中的這一特定啟動裝載程序”。
Boot0002 是由原生 UEFI Fedora 安裝生成的啟動項。Boot0003 是由原生 UEFI OpenSUSE安裝生成的啟動項。按照字面意思，這些啟動項表示“從此分區(qū)加載這一文件”。分區(qū)指的是 HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d) 這個東西：表示某一特定分區(qū)（使用 EFI_DEVICE_PATH_PROTOCOL，我不打算對此進(jìn)行詳細(xì)介紹。如果你通過固件界面和 efibootmgr 與啟動管理器進(jìn)行交互，你也不需要知道其中的細(xì)節(jié)）。文件指的是 (\EFI\opensuse\grubx64.efi) 這個東西：它僅表示“加載所述分區(qū)上此位置中的文件”。這里所指的分區(qū)基本上始終指的就是充當(dāng) EFI 系統(tǒng)分區(qū)的那個分區(qū)，因此：可以放心地讓固件訪問 EFI 系統(tǒng)分區(qū)。
UEFI 規(guī)范提供這一機(jī)制，以便操作系統(tǒng)可啟動：操作系統(tǒng)將啟動裝載程序（作用為加載操作系統(tǒng)內(nèi)核等）安裝到 EFI 系統(tǒng)分區(qū)中，并使用某一名稱（顯然，這一名稱通常來源于操作系統(tǒng)名稱）以及啟動裝載程序（EFI 可執(zhí)行格式，用于加載操作系統(tǒng)）的位置向 UEFI 啟動管理器配置中添加啟動項。
Linux發(fā)行版使用 efibootmgr 工具處理 UEFI 啟動管理器。進(jìn)行原生 UEFI 安裝時，有關(guān)啟動裝載方面，Linux 發(fā)行版實際進(jìn)行的操作相當(dāng)簡單：它會創(chuàng)建一個 EFI 系統(tǒng)分區(qū)（如果不存在此分區(qū)），使用相應(yīng)配置將 EFI 啟動裝載程序（通常為 grub2-efi，但是也有例外）安裝到 EFI 系統(tǒng)分區(qū)中的正確路徑下，然后調(diào)用 efibootmgr 添加相應(yīng)的 UEFI 啟動管理器項（指向其啟動裝載程序）。如果已存在 EFI 系統(tǒng)分區(qū)，大部分發(fā)行版會使用現(xiàn)有分區(qū)（盡管完全可以創(chuàng)建新的 EFI 系統(tǒng)分區(qū)并使用這個新分區(qū)）：我們已經(jīng)提到過，UEFI 是一種寬松規(guī)范，只要在邏輯上遵循其設(shè)計，那么有多少個 EFI 系統(tǒng)分區(qū)都沒問題。
上文描述了 UEFI 規(guī)范定義的基本機(jī)制，用于管理 UEFI 啟動過程。固件用戶界面可能不會明確遵循這一機(jī)制，了解這一點非常重要。不幸的是，UEFI 規(guī)范有意未限制啟動過程的呈現(xiàn)方式或用戶配置啟動過程的方式，這表示——由于我們也從事 固件工程 ——每個固件會有不同的實現(xiàn)方法，并且其中某些固件的實現(xiàn)方法較瘋狂。
許多固件的啟動配置界面較直觀。優(yōu)秀的固件設(shè)計至少會顯示啟動順序以及其中的各個啟動項，允許用戶添加/刪除項、更改啟動順序或在某次特定啟動中忽略原有啟動順序（僅針對那次啟動生效，或直接讓固件啟動特定菜單項，甚至可以選擇讓固件以 BIOS 兼容模式或 UEFI“回退 (Fallback)”模式“啟動這塊磁盤”，我的固件就可以這么操作）。此類界面通?？梢詢H按名稱顯示完整的原生 UEFI 啟動項（例如我們上文提到的 Fedora 和 OpenSUSE 示例）；你需要檢查 efibootmgr –v 的輸出，以詳細(xì)了解在調(diào)用這些項時，它們具體會嘗試并執(zhí)行哪些操作。
某些固件會嘗試對配置進(jìn)行抽象和簡化，最終結(jié)果良莠不齊。例如，如果可以選擇“啟用或禁用”BIOS 兼容模式，固件很有可能會為已連接驅(qū)動器的 UEFI 啟動管理器配置添加或刪除 BIOS 兼容項。如果可以選擇“啟用或禁用”原生 UEFI 啟動，那么在用戶“禁用”原生 UEFI 啟動時，固件很有可能更改 UEFI 啟動管理器配置，從 BootOrder 中刪除所有原生UEFI啟動項。
請謹(jǐn)記，固件界面中的所有配置選項所執(zhí)行的操作就是在后臺配置 UEFI 啟動管理器的行為。如果你能理解以上所有內(nèi)容，那么當(dāng)你更改固件界面中的選項時，你會更容易理解其背后的本質(zhì)。
在 BIOS 中，系統(tǒng)不會始終嘗試優(yōu)先從可移動驅(qū)動器（CD、USB）進(jìn)行啟動，然后再從驅(qū)動器啟動。根據(jù)實際情況，結(jié)果可能有所不同。有些 BIOS 固件會優(yōu)先嘗試從 CD 啟動，然后再嘗試從硬盤啟動（而不是 USB）。試圖安裝新的操作系統(tǒng)時，用戶已習(xí)慣于時常檢查 BIOS 配置，以確保啟動順序“正確無誤”。
UEFI 也是如此，但是由于 UEFI 啟動管理器機(jī)制的靈活性/復(fù)雜性，這一過程看起來可能顯得陌生而可怕。
在系統(tǒng)嘗試啟動固定啟動項之前，如果想要確保系統(tǒng)使用“回退(Fallback)”機(jī)制優(yōu)先從可移動設(shè)備啟動（例如，在安裝 Fedora 時），需要將可移動設(shè)備作為固件的默認(rèn)啟動項，或需要相應(yīng)設(shè)置固件。根據(jù)具體固件界面，可能發(fā)現(xiàn)每個連接的可移動設(shè)備都有對應(yīng)的“菜單項”，你只需要調(diào)整啟動順序，把你想要的可移動設(shè)備放在首位即可，有時候你也會發(fā)現(xiàn)可以直接請求“對此特定磁盤進(jìn)行 UEFI 恢復(fù)啟動”，另外你還可能發(fā)現(xiàn)固件會嘗試將配置進(jìn)行抽象。我們不知道具體的固件界面是什么樣，因此難以編寫說明。但是既然你已了解背后的工作原理，那么就可能更容易理解固件用戶界面配置的含義。
如上所述，與 BIOS 機(jī)制不同，你可以從操作系統(tǒng)層面配置 UEFI 啟動過程。如果你的固件比較令人惡心，你可能需要執(zhí)行此操作才能達(dá)成目的。
你可以使用之前提過的 efibootmgr 工具來添加、刪除和修改 UEFI 啟動管理器配置中的項，這一工具也具有其他豐富功能。你可以更改啟動順序。你可以更改下次啟動時的首要啟動項，而不需要使用 BootOrder 列表（如果你或其他某些工具已經(jīng)進(jìn)行過配置，efibootmgr –v 的輸出將包括 BootNext 項，說明下一次啟動將加載的菜單項）。Windows 下也有類似的工具。因此如果你難以從固件界面配置 UEFI 啟動，但是你可以啟動某種原生 UEFI 操作系統(tǒng)，那么你可以考慮從操作系統(tǒng)（而不是固件 UI）進(jìn)行啟動配置。
我們快速瀏覽下上文中與在 UEFI 計算機(jī)上安裝操作系統(tǒng)相關(guān)的具體結(jié)果。
用戶有時會忽略以下事項：
這適用于（現(xiàn)在暫時忽略其中的無關(guān)警告）我接觸過的所有操作系統(tǒng)。因此你可能確實想了解，如何在固件層選擇以原生 UEFI 模式啟動可移動設(shè)備，以及如何在固件層選擇以 BIOS 兼容模式啟動可移動設(shè)備，確保在安裝時可以隨意選擇需要使用的模式。
如果以 BIOS 兼容模式啟動安裝介質(zhì)，那么你絕對無法成功進(jìn)行操作系統(tǒng)的原生 UEFI 安裝，因為安裝程序無法配置 UEFI 啟動管理器（除非以原生 UEFI 模式啟動安裝介質(zhì)）。
理論上，在以原生 UEFI 模式啟動之后，操作系統(tǒng)的安裝程序可通過 BIOS 模式安裝該操作系統(tǒng)，即，將啟動裝載程序?qū)懭氪疟P MBR，但是大部分安裝程序無法執(zhí)行此操作，這種做法比較可取。
有時候，在啟動操作系統(tǒng)安裝程序之后，你不確定啟動模式為原生 UEFI 模式還是 BIOS 兼容模式。別擔(dān)心。有幾種簡單方法可以確定啟動模式。最簡單的方法之一是嘗試讀取 UEFI 啟動管理器。如果你啟動了 Linux 安裝程序或環(huán)境，并且可以運(yùn)行 shell（例如，在 Fedora 安裝程序中是 Ctrl-Alt-F2），請運(yùn)行 efibootmgr –v。如果你啟動的是原生 UEFI 模式，那么就可以看到上文所示的 UEFI啟動管理器配置。如果你啟動的是 BIOS 兼容模式，那么會看到類似以下內(nèi)容：
Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables.Try 'modprobe efivars' as root.
如果啟動了其他操作系統(tǒng)，你可以嘗試運(yùn)行該操作系統(tǒng)的內(nèi)置實用程序，讀取 UEFI 啟動管理器，并查看是否顯示了明確輸出或類似錯誤?；蛘吣憧梢詸z查系統(tǒng)日志并搜索“efi”和/或“uefi”，從中可能發(fā)現(xiàn)蛛絲馬跡。
若要啟用原生 UEFI 模式的啟動，那么操作系統(tǒng)安裝介質(zhì)必須明確符合我們剛剛說明的所有規(guī)范：具有 GUID 分區(qū)表，和 EFI 系統(tǒng)分區(qū)，啟動裝載程序位于正確的“回退”路徑 (Fallback path) 中—\EFI\BOOT\BOOTx64.EFI（其他平臺可能會有其他名稱）。如果無法以原生 UEFI 模式啟動安裝介質(zhì)，并且無法查出原因，那么請檢查安裝介質(zhì)是否滿足上述條件。顯然，當(dāng)使用 livecd-iso-to-disk 工具將 Fedora 映像寫入 USB 存儲器時，你必須傳遞 –efi 參數(shù)，才能將存儲器配置為可用 UEFI 模式啟動。
如果你的固件難以通過 BIOS 兼容模式從可移動介質(zhì)啟動，但是你又確實想通過這種方式啟動，那么可以使用一些小把戲：完全禁用該介質(zhì)的原生 UEFI 啟動模式?？梢酝ㄟ^清除所有 EFI 系統(tǒng)分區(qū)來輕松執(zhí)行此操作（或者，如果使用 livecd-iso-to-disk 從 Fedora 映像創(chuàng)建 USB存儲器，那么只需去掉 –efi 參數(shù)，存儲器就會變?yōu)椴豢赏ㄟ^ UEFI 模式啟動）。如果執(zhí)行完此操作以后，你的固件仍然無法以 BIOS 兼容模式啟動介質(zhì)，那么就去吐槽你的固件供應(yīng)商吧（如果還沒吐槽過）。
其他注意事項如下：
當(dāng)然，為了給用戶找不自在，許多固件可以通過 BIOS 模式從 GPT 格式的磁盤啟動。事實上，從技術(shù)層面而言，也要求 UEFI 固件能從 MBR 格式的磁盤以 UEFI 模式啟動（雖然無法保證）。但是你應(yīng)當(dāng)盡可能避免這種情況。這些注意事項非常重要，因為許多用戶都曾深受其害。例如，以原生 UEFI 模式啟動操作系統(tǒng)安裝程序，然后試圖直接安裝到 MBR 格式的磁盤是非常不明智的。很有可能失敗。多數(shù)現(xiàn)代操作系統(tǒng)安裝程序?qū)汛疟P自動重新格式化為正確格式（如果你允許安裝程序徹底清除磁盤數(shù)據(jù)），但是，如果你嘗試讓安裝程序“對此 MBR 格式的磁盤執(zhí)行原生 UEFI 安裝，并且不要重新格式化這塊磁盤，因為上面有重要數(shù)據(jù)”，那么就很有可能失敗，盡管技術(shù)層面而言，UEFI 規(guī)范提到了這種配置。具體而言，至少 Windows 和 Fedora 會明確禁止這種配置。
你可以使用 parted 實用程序檢查給定磁盤的格式：
[adamw@adam Downloads]$ sudo parted /dev/sdaGNU Parted 3.1Using /dev/sdaWelcome to GNU Parted! Type 'help' to view a list of commands.(parted) p Model: ATA C300-CTFDDAC128M (scsi)Disk /dev/sda: 128GBSector size (logical/physical): 512B/512BPartition Table: msdosDisk Flags: Number Start End Size Type File system Flags 1 1049kB 525MB 524MB primary ext4 boot 2 525MB 128GB 128GB primary lvm(parted)
注意到 Partition table: msdos 那一行了嗎？這是一塊 MBR/MS-DOS 格式的磁盤。如果是 GPT 格式的磁盤，會顯示 gpt。你可以從 parted 中通過執(zhí)行 mklabel gpt 或 mklabel msdos 將磁盤重新格式化為其他類型分區(qū)表。這會破壞磁盤內(nèi)容。
對于多數(shù)操作系統(tǒng)的安裝程序而言，如果你采用的磁盤配置會清空目標(biāo)磁盤的所有內(nèi)容，那么根據(jù)執(zhí)行的安裝類型，安裝程序就會自動使用最合適的配置重新格式化磁盤。但是如果你想使用現(xiàn)有磁盤而不格式化，那么你需要檢查該磁盤的格式并三思而后行。
我只能針對 Fedora 給出權(quán)威建議，但是其中的主要內(nèi)容可能也適用于其他發(fā)行版/操作系統(tǒng)。
執(zhí)行原生 UEFI 安裝，并且采用 GPT 格式的磁盤時，或者允許 Fedora 重新格式化磁盤（通過刪除所有現(xiàn)有分區(qū)）時，如果允許 Fedora 自動處理分區(qū)，那么 Fedora 就會自動處理 EFI 系統(tǒng)分區(qū)。
但是，如果使用自定義分區(qū)，F(xiàn)edora 會要求指定 EFI 系統(tǒng)分區(qū)，以供安裝程序使用。如果不執(zhí)行此步驟，安裝程序會報錯（錯誤消息的含義不明）并拒絕啟動安裝。
因此，如果執(zhí)行原生 UEFI 安裝并使用自定義分區(qū)，需要確保類型為“EFI 系統(tǒng)分區(qū)”的分區(qū)已掛載到 /boot/efi（這是 Fedora 查找 EFI 系統(tǒng)分區(qū)的路徑）。如果系統(tǒng)上存在現(xiàn)有 EFI 系統(tǒng)分區(qū)，那么僅需將其掛載點設(shè)置為 /boot/efi 即可。如果還沒有 EFI 系統(tǒng)分區(qū)，那么請創(chuàng)建一個分區(qū)，將其類型設(shè)置為 EFI 系統(tǒng)分區(qū)，大小至少為 200MB（建議 500MB），然后將其掛載點設(shè)置為 /boot/efi。
總結(jié)：如果購買了 Windows 8 或更高版本的操作系統(tǒng)，那么你的 Windows 基本上肯定是通過原生 UEFI 安裝到 GPT 格式磁盤的。這表示如果你想安裝其他操作系統(tǒng)，并與 Windows 共存，那么需要通過原生 UEFI 方式安裝操作系統(tǒng)。如果你不喜歡 UEFI，并且想要用回老掉牙的 BIOS，那么恐怕就得清空整個原生 UEFI 的 Windows，而且需要重新將磁盤格式化為 MBR。
上文解釋了 UEFI 的啟動原理(至少解釋得差不多了)。我這種描述方法應(yīng)該還可以吧？
但是，UEFI 并不完美，也有許多問題。
細(xì)心的讀者可能已經(jīng)留意，我曾經(jīng)提到過，UEFI 規(guī)范提供了一種機(jī)制。這種說法很嚴(yán)謹(jǐn)，也很重要。由于 UEFI 規(guī)范是一種“廣泛共識”，因此其主要缺點之一（就特定方面而言）是并未提供具體實現(xiàn)。
如果仔細(xì)閱讀 UEFI 規(guī)范，就會發(fā)現(xiàn) UEFI 規(guī)范的基本方式是定義 UEFI 兼容固件必須支持的一系列功能。但是 UEFI 規(guī)范并沒有嚴(yán)格規(guī)定這些功能的具體實現(xiàn)方法。
因此，UEFI 規(guī)范只要求系統(tǒng)固件必須遵循其中描述的所有內(nèi)容，以便滿足 UEFI 兼容固件的要求。但是，規(guī)范本身未規(guī)定操作系統(tǒng)“應(yīng)該”或“必須”怎么做，并且 UEFI 規(guī)范也沒有規(guī)定固件不得支持（或者不期望支持）的功能。換言之，在制定 UEFI 固件時，需要支持 GPT 格式的磁盤和 FAT 格式的 EFI 系統(tǒng)分區(qū)，并且必須以標(biāo)準(zhǔn)格式讀取 UEFI 啟動管理器項等等——但是也可以隨意添加其他未規(guī)定的功能。
從 UEFI 規(guī)范中不難發(fā)現(xiàn)其中的隱喻——UEFI 規(guī)范仔細(xì)設(shè)置了一種良好機(jī)制，用于在固件層處理操作系統(tǒng)（或其他啟動項）選擇。但是 UEFI 規(guī)范并不要求一定要這么做，其他廣受贊譽(yù)的規(guī)范也沒有類似規(guī)定。
因此，在實際使用時，我們可能遇到各種復(fù)雜情況。例如，Apple Mac 的 HFS+ 分區(qū)中隨附了某些啟動裝載程序。UEFI 規(guī)范提到，UEFI 兼容固件必須支持特定 GPT 分區(qū)類型的 UEFI FAT 分區(qū)（標(biāo)識為“EFI 系統(tǒng)分區(qū)”），但是 UEFI 規(guī)范并沒有提到固件不能識別其他文件系統(tǒng)類型并從中加載啟動裝載程序。（此類分區(qū)是否應(yīng)視為“EFI 系統(tǒng)分區(qū)”，這很難回答，在此不做探討。）
要是所有廠商都能按照 UEFI 規(guī)范嚴(yán)格使用 EFI 系統(tǒng)分區(qū)，那就不會有這么多問題了。但是 Apple 畢竟是 Apple，它的產(chǎn)品設(shè)計領(lǐng)先于其他廠商，率先設(shè)計出了可以從 HFS+ 分區(qū)讀取和加載代碼的固件，導(dǎo)致現(xiàn)在其他廠商不得不緊隨 Apple 的腳步，除非他們不打算支持 Mac。在啟動過程設(shè)計中，Apple 進(jìn)行的工作遠(yuǎn)超出 UEFI 規(guī)范的范圍，因此，如果你想讓其他操作系統(tǒng)以美觀的圖標(biāo)或其他形式顯示在 Mac 的圖形啟動菜單上，你所要做的操作將超出 UEFI 規(guī)范的建議范圍。
還有各種類似的極端狀況，使人煩不勝煩，但是我們先不管了。這篇文章夠長的了。
另外，就像之前提到過的，UEFI 規(guī)范并沒有對機(jī)制的具體呈現(xiàn)方式進(jìn)行約束。因此，如果一些軟件公司設(shè)計的操作系統(tǒng)符合 UEFI 規(guī)范，并且可以安裝 EFI 啟動裝載程序，并明確命名 EFI 啟動管理器項（例如，F(xiàn)edora 和 Windows），那么如果要向用戶提供某種相對辨識度較高的漂亮界面，讓用戶可以從中選擇啟動 Windows 或 Fedora，就得看固件本身設(shè)計得怎么樣。固件設(shè)計得越糟糕，操作系統(tǒng)工程師就越不會遵守 UEFI 規(guī)范，他們越可能在固件層上另起爐灶。
說句公道話，我們可以在操作系統(tǒng)層實現(xiàn)更多功能。我們可以用更整潔直觀的方式實現(xiàn) efibootmgr 的所有功能——例如，我們可以采用“無視下一次啟動時的啟動順序，直接啟動此項”，同時將“重新啟動到 Windows”作為選項之一。如果開發(fā)人員能夠用更直觀的方式展現(xiàn) efibootmgr 的所有功能，那將會非常不錯。Windows 8 系統(tǒng)在一定程度上采用了這種方式——例如，用戶可以從 Windows 8 設(shè)置菜單中將系統(tǒng)重新啟動到固件 UI。但是這還不夠。
這些實在令人欲哭無淚，因為 UEFI 本來可以更好地進(jìn)行統(tǒng)一。對于多重啟動，BIOS 不提供任何類型的規(guī)范或標(biāo)準(zhǔn)，因此完全需要在固件層上處理多重啟動。我們（這一產(chǎn)業(yè)）已經(jīng)提出了某種處理多重啟動的規(guī)范，但是我們從未將其付諸實施，因此最終不了了之。而每種操作系統(tǒng)都采用自己的多重啟動方法，大量開發(fā)人員也自己寫了啟動裝載程序，試圖包攬所有操作系統(tǒng)。而所有操作系統(tǒng)和獨立的啟動裝載程序難以互相兼容。我想說的是，在 UEFI 誕生之前，多重啟動的實現(xiàn)方式一團(tuán)混亂。
如果 UEFI——或者基于 UEFI 的某種規(guī)范——要求所有廠商遵循 UEFI 提出的規(guī)范，并要求固件提供直觀的用戶界面，那將會終結(jié)現(xiàn)階段的混亂情況。但是現(xiàn)實不如人意，因此 UEFI 的情況完全可能比 BIOS 更糟糕。如果大量固件沒有為 UEFI 啟動管理器機(jī)制提供良好的 UI，那么操作系統(tǒng)供應(yīng)商可能放棄 UEFI 啟動管理器機(jī)制（或選擇性地進(jìn)行支持），轉(zhuǎn)而在 UEFI 中重現(xiàn) BIOS 多重啟動的混亂情況——如此一來，我們就得收拾所有爛攤子，外加 UEFI 啟動管理器層的其他影響。在整個 UEFI 啟動管理器機(jī)制上，用戶可能裝有多個啟動裝載程序，互相爭搶裝載多個操作系統(tǒng)的控制權(quán)，而 UEFI 啟動管理器機(jī)制只會機(jī)械地處理各種變量，而無法解決這種混亂情況。
這不是某人靈光閃現(xiàn)的荒唐想法，而是可能實際發(fā)生的真實情形。
另外，在這方面產(chǎn)生的 UEFI 缺陷是由一時疏忽引起的——這些缺陷不受委員會控制，也不是某人故意為之的結(jié)果。如果你的系統(tǒng)固件很坑爹，無法讓你輕松訪問 UEFI 啟動管理器，那么你的發(fā)泄對象不應(yīng)該是 UEFI 論壇或微軟，當(dāng)然也不是 Fedora 或者我。你應(yīng)該歸咎于系統(tǒng)/主板制造商和他們雇用的傻逼固件開發(fā)人員。凡是大腦健全的人，都能看出來，UEFI 規(guī)范已經(jīng)明確說明，為 UEFI 啟動管理器提供某種直觀的用戶界面是非常有益的，所有反人類的固件都是一堆垃圾代碼。的確，UEFI 論壇已經(jīng)意識到固件工程師難以脫離現(xiàn)有約束重新學(xué)習(xí)新規(guī)范，但是，固件工程師最終還是應(yīng)該與時俱進(jìn)。
簡單來說，“所有固件都是垃圾代碼”。這句話通常非常準(zhǔn)確。
我們最后要介紹的，就是安全啟動 (Secure Boot)。
安全啟動 (Secure Boot) 并不神奇，也不復(fù)雜。才怪。安全啟動 (Secure Boot) 復(fù)雜得要命，但是其理論并不復(fù)雜。安全啟動 (Secure Boot) 本身也并不邪惡。事實就是如此，你也應(yīng)當(dāng)認(rèn)同這一事實，除非你認(rèn)為GPG也有惡意。
在 UEFI 規(guī)范（2.4A 版本）的第 28 章對安全啟動 (Secure Boot) 進(jìn)行了定義。這種機(jī)制事實上非常明智。但是其原理卻非常簡單。UEFI 規(guī)范規(guī)定固件可以包含一系列簽名，并拒絕運(yùn)行未簽名或簽名與固件中包含的簽名不一致的 EFI 可執(zhí)行文件。
就這么簡單?當(dāng)然不是了，這只是一種簡單概括。安全問題很復(fù)雜，因此才會產(chǎn)生通過安全啟動 (Secure Boot) 來實現(xiàn)真正安全啟動鏈的各種方法。mjg59 可以進(jìn)行詳細(xì)介紹，或者你可以完整閱讀第 28 章。但是其中只涉及了基本概念。
使用公開密鑰加密來驗證某個文件完整性的方法很難判斷其好壞。幾乎所有 Linux 發(fā)行版都依賴這種加密方法——我們?yōu)檐浖灻?，在嘗試安裝未使用我們的密鑰之一簽名的軟件包時，軟件包管理器將發(fā)出警告。這不是我們的錯，我也不認(rèn)為會有人因為以這種方式使用公開密鑰加密進(jìn)行簽名而歸咎于操作系統(tǒng)本身。從字面上看，安全啟動 (Secure Boot) 與這種廣泛認(rèn)可的機(jī)制完全相同，只不過安全啟動 (Secure Boot) 適用于啟動鏈。由于一撮媒體人找錯了槽點，并揪著不放，導(dǎo)致大眾受到了廣泛誤導(dǎo)，認(rèn)為安全啟動 (Secure Boot) 是洪水猛獸。
UEFI 規(guī)范中定義的安全啟動 (Secure Boot) 并沒有對固件所信任的密鑰形式及其來源作出規(guī)定，我也不打算介紹所有細(xì)節(jié)，因為過于枯燥乏味，而且本文已經(jīng)挺長了。但是總的來說，UEFI 規(guī)范只對執(zhí)行啟動鏈的加密驗證進(jìn)行了定義。UEFI 規(guī)范甚至沒有涉及用于執(zhí)行這一過程的策略可能產(chǎn)生的問題。這本來并沒有錯，因為這樣可以保證其靈活性，并且 UEFI 規(guī)范允許在多個層面配置涉及的所有機(jī)制。UEFI 規(guī)范中未提及微軟，也沒有和微軟互相勾結(jié)。如果你不信，那么你可以閱讀 UEFI 規(guī)范。我已經(jīng)提供了所有說明。字面上來說，對于那些反對在固件規(guī)范中將啟動裝載程序加密驗證機(jī)制作為可選功能的人，我不予置評。
有關(guān)安全啟動 (Secure Boot) 的所有不滿并不針對安全啟動 (Secure Boot) 機(jī)制本身——雖然發(fā)出這些不滿的人可能不這么認(rèn)為——而是針對安全啟動 (Secure Boot) 在實際操作中的特定實現(xiàn)方式。
我們唯一在意的是，對于預(yù)裝 Windows 8 或更高版本 Windows 的 PC 而言，安全啟動 (Secure Boot) 是默認(rèn)開啟的。
微軟將這些稱為“Windows 硬件認(rèn)證要求”。這些要求并不是什么絕密內(nèi)容，所有人都可以在互聯(lián)網(wǎng)上閱讀。
如果想從微軟那里以低廉的價格獲得預(yù)裝 Windows 的批量許可，并在機(jī)箱上貼有“微軟認(rèn)證”標(biāo)簽，那么你必須符合這些認(rèn)證要求。微軟的約束力有限：他們不是美國或其他國家/地區(qū)的法律制定者，無論其他人怎么想。即使你銷售的 PC 不符合這些要求，比爾·蓋茨也不會拿你怎么樣，前提是你不需要預(yù)裝廉價的 Windows 副本和那張“微軟認(rèn)證”標(biāo)簽。對于不符合微軟許可計劃的在售 PC，事實上并不要求如何配置安全啟動 (Secure Boot)，甚至根本不需要提供安全啟動 (Secure Boot) 功能。具有 UEFI 2.2 或更高版本兼容固件的 PC 必須提供安全啟動 (Secure Boot) 功能，但是并沒有規(guī)定具體的實現(xiàn)方法（包括關(guān)閉安全啟動 (Secure Boot) 的方法）。
如果你對安全啟動 (Secure Boot) 意見很大，那么就別找借口了，馬上去讀讀微軟認(rèn)證要求吧（http://msdn.microsoft.com/en-us/library/windows/hardware/dn423132.aspx）。你可以搜索“Secure Boot”來閱讀相關(guān)內(nèi)容。從“System.Fundamentals.Firmware.UEFISecureBoot”一節(jié)開始。
你最好讀一遍，但是我對其內(nèi)容進(jìn)行了總結(jié)。
符合微軟認(rèn)證要求的計算機(jī)必須滿足以下條件：
符合微軟認(rèn)證要求的 x86 計算機(jī) 還必須滿足以下附加條件：
符合微軟認(rèn)證要求的 ARM 計算機(jī) 還必須滿足以下附加條件：
是的，你沒看錯。對于 x86 計算機(jī)，微軟認(rèn)證要求明確規(guī)定了自然人用戶應(yīng)當(dāng)能夠完全控制安全啟動 (Secure Boot)（啟用或禁用），或完全控制安全啟動 (Secure Boot) 的信任密鑰列表。另一個重點是，盡管認(rèn)證要求規(guī)定，信任密鑰列表必須包括微軟的密鑰，但是其中沒有規(guī)定不允許包括其他密鑰。微軟認(rèn)證要求也明確允許系統(tǒng)包含其他任意數(shù)量的信任密鑰。
這些要求并不完全出于微軟的好意，之所以作出這些規(guī)定，是因為如果不這么做的話，微軟將面臨大量訴訟2。真正了解 UEFI 和安全啟動 (Secure Boot) 的用戶可能不會曲解微軟認(rèn)證要求，這些要求非常清晰明確。這些要求旨在確保認(rèn)證系統(tǒng)的所有者能完全控制安全啟動 (Secure Boot)，事實上這些要求也確實成功確保了這一條件。
如果你有包含 Windows 認(rèn)證的 x86 系統(tǒng)，但是不允許你禁用安全啟動 (Secure Boot)，那么這就直接違反了認(rèn)證要求，你應(yīng)該馬上投訴。如果市面上存在大量這類系統(tǒng)，那么我們肯定會有麻煩，可能要給那些巨頭廠商提起訴訟了。但是目前為止，事實并非如此。在我見過的所有 x86 Windows 認(rèn)證系統(tǒng)中，其固件都有“禁用安全啟動 (Secure Boot)”選項。
對于 ARM 計算機(jī)，認(rèn)證要求顯然更變態(tài)：其中的規(guī)定和 x86 完全相反，不允許禁用安全啟動 (Secure Boot)，也不允許系統(tǒng)所有者更改信任密鑰。非常糟糕且不合理。這使得微軟認(rèn)證 ARM 系統(tǒng)成為了一個封閉的環(huán)境。值得注意的是，其他主要 ARM 平臺甚至更糟糕。Apple 在所有 iDevice 上鎖定了啟動裝載程序，而且大部分 Android 設(shè)備的啟動裝載程序也是鎖定的。
如果你計劃購買微軟認(rèn)證 ARM 設(shè)備，請注意這一問題，你將無法控制設(shè)備上的啟動項。如果你對此反感，那就不要購買這樣的設(shè)備，也不要購買 iDevice 或啟動裝載程序處于鎖定狀態(tài)的 Android 設(shè)備（你可以購買啟動裝載程序未鎖定或無法鎖定的 Android 設(shè)備，但是需要事先進(jìn)行調(diào)查研究）。
目前，就 x86 設(shè)備本身而言，微軟的認(rèn)證要求實際上明確保障了用戶自由啟動系統(tǒng)的權(quán)利。這是件好事。
以下內(nèi)容是我在管理系統(tǒng)啟動方面的一般建議，不保證其準(zhǔn)確性、可靠性或安全性。
1. 這一整節(jié)都是簡化過的內(nèi)容——當(dāng)啟動已安裝的操作系統(tǒng)時，無論啟動裝載程序是否安裝在“ESP”上，對固件都沒有影響；固件只會讀取啟動管理器項，然后嘗試訪問特定分區(qū)并執(zhí)行特定可執(zhí)行文件，具體請參閱 pjones 的說明。但是一般會使用 ESP 來進(jìn)行啟動過程，因為 UEFI 規(guī)范中有相應(yīng)規(guī)定，而且這個分區(qū)也很方便，固件可以讀取其文件系統(tǒng)。理論上來說，在固件執(zhí)行可移動介質(zhì)/回退路徑 (Fallback path) 啟動時，ESP 將不起作用。
2. 注意，這只是我的個人推斷。在整個規(guī)范的制定過程中，我都沒有參與，也沒人告訴我這些內(nèi)容。但是根據(jù)已知事實，明顯可以得出這一推斷。
聯(lián)系客服
