（譯）UEFI 啓動：實際工做原理

本文是我翻譯自國外技術博客的一篇文章，其中講述了 UEFI 的一些基本概念和細節。

本文的原始連接位於： https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/

本人的翻譯水平有限，不免多有疏漏。廢話很少說，請看正文：

又到 AdamW 的講課時間了，若是你不想聽個人長篇大論，那麼請出門右拐。

Kamil Paral 說我有 寫做癖 ，知道本身的壞習慣也是件好事。

可能你已經在互聯網上閱讀過有關 UEFI 的大量資料。可是有一些重要事項須要瞭解：這些資料中的 95% 都毫無價值。若是你認爲你已經對 UEFI 有所瞭解，可是若是你的知識來源並不可靠，那麼所掌握的知識就不過是一堆誤解、謬論、一己之見、信口開河和彌天大謊。先把這些都忘了吧。若是想真正瞭解有關 UEFI 的權威知識，不妨訪問 UEFI 規範、 mjg59 的博客 、其餘靠譜一點的文章/權威人士——包括 Rod Smith 、 Peter Jones 、Chris Murphy，或者閱讀一些小衆操做系統的文檔，前提是這些操做系統的開發人員確實瞭解 UEFI。

好，準備工做作完了。我主要想討論啓動加載，由於對於大多數用戶而言，固件在其中扮演着重要角色，同時，很多網站也針對這一過程喋喋不休，由此產生很多誤解。

術語

首先，咱們瞭解一些術語。 BIOS 和 UEFI 都是計算機的 固件 類型。BIOS 固件（主要）用於 IBM PC 兼容計算機 。UEFI 的通用性更強，可用在非「IBM PC 兼容」系列的計算機上。

不存在「UEFI BIOS」。沒有任何一臺計算機會有「UEFI BIOS」。請不要再說「UEFI BIOS」。BIOS 不是全部 PC 固件的通用術語，它只是 PC 固件的一種特定類型。計算機中包含固件。若是你有一臺 IBM PC 兼容計算機，那麼固件幾乎確定就是 BIOS 或 UEFI。若是你運行的是 Coreboot ，那麼恭喜，你是個例外，引覺得傲吧。

安全啓動 (Secure Boot) 與 UEFI 不是同一個概念。請不要將這些術語混淆使用。安全啓動 (Secure Boot) 其實是 UEFI 規範的一項可選功能，於 UEFI 規範版本 2.2 引入。咱們稍後會詳細討論安全啓動 (Secure Boot) 究竟是什麼，可是目前而言，只須要記住它和 UEFI 不一樣便可。你須要區分安全啓動 (Secure Boot) 和 UEFI 的差別，在任何場合，你都應當瞭解你實際上討論的是其中哪個。咱們首先討論 UEFI，而後咱們將把安全啓動 (Secure Boot) 做爲 UEFI 的一項「擴展」來進行討論，由於這就是安全啓動 (Secure Boot) 的本質。

註釋：UEFI 不是由微軟開發的，也歷來不受微軟控制。它的前身和基礎——EFI，是由 Intel 開發和發佈的。UEFI 由 UEFI 論壇 進行管理。微軟是 UEFI 論壇的成員之一。Red Hat、Apple、幾乎全部主要 PC 製造商、Intel（顯然）、AMD 和 一大批其餘主要和次要硬件、軟件和固件公司及組織 也都是 UEFI 論壇的成員。UEFI 是一套業已達成普遍共識的規範，其中固然也包含各類混亂（咱們稍後會專門討論其中一部分）。UEFI 並不禁任何一家公司獨裁掌控。

參考資料

若是想真正瞭解 UEFI，閱讀 UEFI 規範是個不錯的方法。這件事並不難，也不須要什麼代價。閱讀 UEFI 規範至關枯燥乏味，可是會讓你受益不淺。你能夠從 官方 UEFI 網站 下載 UEFI 規範。儘管下載 UEFI 規範須要先贊成某些條款和條件，可是不會帶來損失。在我撰寫本文時，UEFI 規範的最新版本是 2.4 Errata A （譯者注：如今更新到了2.4 Errata B ），本文所寫內容也基於這一版本。

BIOS 沒有制定相應規範。BIOS 自己就是一項事實標準，從 20 世紀 80 年代開始，BIOS 的工做方式就一成不變。這也是誕生 UEFI 的緣由之一。

簡單起見，咱們能夠把 BIOS 和 UEFI 當作兩種不一樣的組合。其中一種是 UEFI和 GPT （咱們稍後會討論 GPT）產生以前，IBM PC 兼容計算機（如下稱爲 PC）所普遍採用的組合。大部分人可能對這種組合很是熟悉，對其中的細節瞭如指掌。那麼咱們就先來討論在具備 BIOS 固件的 PC 上，啓動是如何工做的。

BIOS 啓動

事實上，BIOS 啓動的工做原理很是很是簡單。在老式 BIOS PC 上，裝有一個或多個磁盤，每一個磁盤中包含 MBR 。MBR 是另外一套事實標準；大致而言，磁盤起始位置以特定格式描述磁盤上的分區，幷包含「啓動裝載程序 (boot loader)」，BIOS 固件知道如何執行這一小段啓動裝載程序代碼。啓動裝載程序的職責是啓動操做系統（現代啓動裝載程序的大小一般超出了 MBR 空間所能容納的範圍，所以必須採用多階段設計，其中 MBR 部分只知道如何從其餘位置加載下一階段，咱們如今先不着重討論這一過程）。

在啓動系統的過程當中，BIOS 固件只能識別系統包含的磁盤。而做爲 BIOS 計算機的擁有者，你能夠告訴 BIOS 固件你想從哪一個磁盤啓動系統。而固件自己並不知道其餘細節，它只會執行在指定磁盤的 MBR 部分所發現的啓動裝載程序，就這麼回事。在執行啓動裝載程序以後，固件自己就再也不參與啓動。

在 BIOS 組合中，全部的多重啓動形式都確定是在固件層上進行處理的。固件層沒法真正識別啓動裝載程序或操做系統，甚至連分區都沒法識別。固件所能執行的操做只是從磁盤的 MBR 中運行啓動裝載程序。你沒法從固件外部配置啓動過程。

UEFI 啓動：背景

好，BIOS 組合的背景知識已經明確了。咱們如今來看看 UEFI 計算機上的啓動原理。即便未掌握本文的細節，也請記住這一點：UEFI 與 BIOS 徹底不一樣。UEFI 啓動原理與 BIOS 絕對不一樣。你不能把 BIOS 啓動的原理直接套用到原生 UEFI 啓動上。你不能把專爲 BIOS 啓動設計的工具應用到原生 UEFI 啓動的系統上。記住，UEFI 組合徹底不一樣。

還須要瞭解一個重點：許多 UEFI 固件實現了某種 BIOS 兼容模式（有時候稱爲 CSM）。許多 UEFI 固件能夠像 BIOS 固件同樣啓動系統，它們能夠查找磁盤上的 MBR，而後從 MBR 中執行啓動裝載程序，接着將後續工做徹底交給啓動裝載程序。有時候，其餘人誤將此功能稱爲「禁用 UEFI」，從語言學角度而言，這種說法是荒謬的。系統固件是沒法「禁用」的。這種說法很愚蠢，不要採用這種說法。可是在其餘人這麼說的時候，應該瞭解他們真正想表達什麼。他們討論的是經過 UEFI 固件的一項功能，以「BIOS 風格」啓動系統，而不是採用原生 UEFI 方式啓動系統。

我想解釋一下原生 UEFI 啓動。若是你有一臺基於 UEFI 的計算機，其固件具備 BIOS 兼容功能，而且你打算一直使用這項兼容功能，在啓動過程當中，你的計算機看起來就是基於 BIOS 的。你只須要像 BIOS 啓動同樣進行所需操做便可。若是你確實有此打算，那麼就不要中途變卦。對於你平常使用的操做系統，強烈建議不要混合使用原生 UEFI 啓動和 BIOS 兼容啓動，尤爲不要在同一塊磁盤上混用。這麼作的話，你會痛不欲生。若是你決定混合使用原生 UEFI 啓動和 BIOS 兼容啓動，到時候就別找我哭訴。

爲了理清頭緒，我將假設磁盤採用 GPT ，而且包含用於 EFI 的 FAT32 EFI 系統分區(ESP)。根據你對這些知識的深刻程度，你可能發現，在進行原生 UEFI 啓動時，GPT 磁盤和 EFI FAT32 ESP 並非必要條件。可是 UEFI 規範和 GPT 磁盤以及 EFI FAT32 ESP 的聯繫程度至關密切。在99%的狀況下，你要處理的也正是這樣的組合。除非你在使用 Mac（老實說，Mac 混亂不堪）。

編輯說明：如下章節（到缺陷爲止）在 2014 年 1 月 26 日（本文發佈的幾小時後）根據 Peter Jones 的反饋進行了大量修訂。本文可視爲 v2.0 版本。早期版本的寫做方式不夠嚴謹，並且內容可能會產生誤解。

UEFI 原生啓動：實際工做原理——背景

言歸正傳。本節將解釋原生 UEFI 啓動的實際工做原理。若是已掌握必定程度的背景知識，可能更容易深刻理解本節內容。

在固件層，UEFI 的基礎架構更豐富，可用於處理系統啓動。UEFI 遠不像BIOS 那麼簡單。與 BIOS 不一樣，UEFI 確實能夠（不一樣程度上）理解「磁盤分區」、「啓動裝載程序」以及「操做系統」的概念。

你能夠稍微看看 BIOS 啓動過程，而後再看看 UEFI 啓動過程，瞭解 UEFI 啓動過程如何採用多種措施來解決特定問題。

在思考啓動過程時，你會發現 BIOS/MBR 查找啓動裝載程序的方法實在不怎麼樣。BIOS/MBR 很是奇葩：位於磁盤起始位置的這一小段空間包含神奇代碼 (magic code)，而這段神奇代碼只做用於系統固件和寫入此神奇代碼的工具。這種方法有許多問題。

• 處理不便——你須要特殊工具來寫入 MBR，若是要查看 MBR 中包含的內容，惟一的方法幾乎就是把 MBR dd 出來，而後進行檢查。
• 如上所述，MBR 自己不足以容納許多現代啓動裝載程序。這些啓動裝載程序會將自身的一小部分安裝在 MBR 中，而將其餘部分安裝到磁盤上的可用空間中。這段可用空間位於常規 MBR 末尾和第一個分區的起始位置之間。這就會形成很大的問題（其實這整個設計就是個大問題，不過無所謂）。對於第一個分區的起始位置，並無成文的可靠規定，所以難以確保空間足夠。只有一件事情是確定的：這段空間不足以容納某些啓動裝載程序的配置。
• 若是要選擇其餘啓動目標（除磁盤之外），這種設計沒有提供任何標準化層或標準化機制，可是用戶但願選擇除磁盤之外的啓動目標。也就是說，他們但願實現多重可啓動對象——一般是操做系統。在 BIOS/MBR 組合中，實現這種目的的惟一方法是由啓動裝載程序進行處理；至於如何實現，並無進行得到普遍承認的規定。雖然實現的方法很是多，可是它們沒法彼此協做，並且也都不是得到普遍承認的標準或規定。而在操做系統/操做系統安裝層編寫工具的難度很大，沒法乾淨利落地處理多重啓動。所以這種設計很是混亂。
• 這種設計沒有提供標準方法，讓用戶能夠從除磁盤之外的目標進行啓動。本文不會就此問題進行詳細討論，可是請注意，UEFI 啓動的另外一優點爲：它提供了進行啓動（例如，從遠程服務器進行啓動）的標準方法。
• 固件層以上的其餘層沒法配置固件的啓動行爲，BIOS 沒有提供相應機制。

能夠想象，在 UEFI 設計之初，開發人員思考過這些問題，並最終提出解決方案。UEFI 固件並不只僅能夠識別磁盤，它也知道啓動裝載程序代碼在每一個磁盤上所處的位置，並且在固件層，UEFI 的基礎架構更豐富，可用於處理啓動裝載。接下來，咱們討論下 UEFI 規範中定義的相關內容。

EFI 可執行文件

UEFI 規範定義了一種可執行文件格式，並要求全部 UEFI 固件可以執行此格式的代碼。當開發人員爲原生 UEFI 編寫啓動裝載程序時，就必須按照這種格式編寫。這種設計很是簡潔直觀，也無需進一步解釋：對於固件能夠執行的代碼，固件規範真正定義了其通用格式，這是件好事。

GPT（GUID 分區表）格式

GUID 分區表格式與 UEFI 規範具備密切聯繫，並且，它並不特別複雜，無需多加解釋。GPT 是 UEFI 規範提供的良好基礎架構之一。GPT 僅僅是分區表的一種標準——磁盤起始位置的信息定義了磁盤所包含的分區。相比 MBR/MS-DOS 分區表，這種分區表對分區的定義要好得多，而且 UEFI 規範要求 UEFI 兼容固件必須能識別 GPT（也要求固件能識別 MBR，以保證向後兼容）。全部這些規範都是至關實用的基礎架構： UEFI 規範正創建某些功能，固件層上的一切均可依靠固件自己來實現這些功能。

EFI 系統分區

在修訂本文時，我才真正思考 EFI 系統分區的概念，讓我有如醍醐灌頂。實際上，「EFI 系統分區」的概念能夠解決「奇葩」的 MBR 空間所產生的問題。在磁盤起始位置留出自由空間，用於存放啓動裝載程序代碼，但又不定義其容量，種設計糟糕透頂。這一點在上文已經討論過了。EFI 系統分區是 UEFI 用於解決這種問題的解決方案。1

具體的解決方案以下：咱們要求固件層可以讀取某些特定的文件系統類型。UEFI 規範要求兼容固件必須能讀取 FAT 格式的變種（包括 FAT十二、FAT16 和 FAT32）。UEFI 規範實際扮演的角色就是編纂整理 FAT 文件系統格式的現有解釋，確保在採用 UEFI 時可使用那些格式，並規定 UEFI 兼容固件必須可以讀取那些格式。UEFI 規範針對這方面的具體規定以下：

「可擴展固件接口 (EFI) 支持的文件系統基於 FAT 文件系統。EFI 定義了能夠明確記錄和測試的具體 FAT 版本。FAT 的惟必定義必須符合 EFI 規範及關聯參考文檔，對 FAT 惟必定義的實現必須支持 EFI。爲區分 EFI 文件系統與純 FAT，定義了新的分區文件系統類型。」

「EFI 系統分區」是採用 FAT 變種（UEFI 規範定義的變種之一）格式化的任意分區，該分區被賦予特定 GPT 分區類型，以幫助固件識別該分區。此分區的目的如上所述：固件層確實能夠讀取「普通」磁盤分區中的數據。但願我已明確解釋爲什麼這種設計更佳：操做系統能夠建立、格式化和掛載分區（採用普遍理解的格式），並將啓動裝載程序的代碼和固件可能須要讀取的全部其餘內容放到這個分區中，而不用像 MBR 磁盤同樣，將啓動裝載程序的代碼寫入磁盤的起始位置空間。

剛開始的時候，對我而言，整個 ESP 的設計看起來有點匪夷所思且使人困惑，所以我但願本節能夠解釋爲什麼 ESP 其實是很是優秀的設計——真正匪夷所思和使人困惑的設計是 BIOS/MBR。若要從操做系統層寫入某些內容，惟一的方法是將這些內容寫入磁盤起始位置的某部分（但不知道是多少）空間，而並無具體規定其中的具體實現。若是回過頭再看，這種設計並不明智，且難以理解。

正如咱們稍後會強調的那樣，UEFI 規範試圖採用更直觀嚴格的方法——它不多禁止固件執行其餘操做。UEFI 規範並不反對編寫固件，用於執行以其餘格式寫成的代碼、讀取其餘類型的分區表，以及讀取用UEFI 變種文件系統（非 FAT）格式化的分區。可是 UEFI 兼容固件必須至少可以實現執行 EFI 可執行文件、讀取 GPT 分區表、以及讀取 ESP，所以若是你正編寫操做系統或其餘東西，而且想要在 UEFI 兼容固件上運行的話，你也得遵循 UEFI 規範，這就是 EFI 系統分區的概念很是重要的緣由：它容許（至少理論上）將 EFI 可執行文件放在以 UEFI FAT 格式化且 GPT 分區類型正確無誤的分區上，另外，系統固件要可以讀取該分區。這種機制很是嚴謹，等價於 BIOS 中的「固件可以執行放置在 MBR 空間中的啓動裝載程序代碼」。

UEFI 規範爲咱們提供了三大重要基礎，這些重要基礎是上層架構正常運行的立足之本：

• 讀取分區表
• 訪問某些特定文件系統中的文件
• 執行特定格式的代碼

相比 BIOS 固件所提供的功能，UEFI 的功能要豐富得多。可是，爲了完成固件層能夠處理多重目標（而不只僅是磁盤）啓動的願景，咱們須要其餘基礎：須要創建一種機制，經過這種機制，固件能夠查找各類可能的啓動目標，並提供相應的配置方法。

UEFI 啓動管理器

UEFI 規範定義了名爲 UEFI 啓動管理器的一項功能（Linux發行版包含名爲efibootmgr 的工具，可用於更改 UEFI 啓動管理器的配置）。若是你確實閱讀過 UEFI 規範，那麼就會發現，UEFI 規範對 UEFI 啓動管理器做出了以下規定：

「UEFI 啓動管理器是一種固件策略引擎，可經過修改固件架構中定義的全局NVRAM 變量來進行配置。啓動管理器將嘗試按全局 NVRAM 變量定義的順序依次加載 UEFI 驅動和 UEFI 應用程序（包括 UEFI 操做系統啓動裝載程序）。」

好，既然已經明確了這一律念，那咱們就繼續吧。不，先等等。我來先把那一項規定解釋清楚，便於理解。簡單來講，你能夠把 UEFI 啓動管理器視爲啓動菜單。在 BIOS 固件上，固件層的「啓動菜單」（固然）是，啓動時鏈接到計算機的各個磁盤——很少很多。可是對於 UEFI 固件而言，狀況有所不一樣。

UEFI 啓動管理器能夠進行配置——簡言之，你能夠向「啓動菜單」添加項或者從中刪除項。固件也能夠（事實上， UEFI 規範也有此要求）根據鏈接到計算機的磁盤或根據某些固件配置，在此啓動菜單中「生成」有效項。你也能夠檢查啓動菜單，確保正確無誤。

UEFI 提供了一種很是優秀的機制，能夠從上層架構執行此操做：你能夠從已啓動的操做系統中配置系統啓動行爲。若是已經過 UEFI 啓動 Linux，就可使用 efibootmgr 工具來完成全部這些操做。Windows 也有相應的工具，可是我對 Windows 下的工具很是不熟悉。咱們不妨看一些典型的 efibootmgr 輸出，這些是我從 Fedora 論壇轉過來的，稍微進行了調整：

[root@system directory]# efibootmgr -v BootCurrent: 0002 Timeout: 3 seconds BootOrder: 0003,0002,0000,0004 Boot0000* 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]#

這個示例很是清晰。咱們能夠從中觀察細節。

第一行表示，目前你從「啓動菜單」的哪一個項進行了啓動。第二行很是明顯（若是固件的 UEFI 啓動管理器顯示了相似啓動菜單的界面，那麼這一行表示繼續啓動默認項以前的超時）。BootOrder 是列表中啓動項的嘗試順序。其他輸出顯示了實際的啓動項。咱們稍後會說明每個啓動項具體做用。

若是徹底正常啓動 UEFI 固件，而不進行任何調整（咱們稍後會討論），UEFI 固件將按照BootOrder 中列出的順序，嘗試從「啓動菜單」中的每一個「項」進行啓動。所以，在這臺計算機上，UEFI 固件將嘗試啓動名爲「opensuse」的項，若是啓動失敗，而後再嘗試啓動名爲「Fedora」的項，而後再是「CD/DVD Drive」，接着是第二項「Hard Drive」。

UEFI原生啓動：實際工做原理——啓動管理器項

那麼，這些項的實際含義是什麼？實際上，UEFI 規範之因此顯得複雜，很大程度上是由於其中的不肯定因素太多。若是你正在閱讀 UEFI 規範，那麼先作好心理準備，而後前往 EFI_DEVICE_PATH_PROTOCOL 一節。可是請注意，這個協議是通用的，雖然這個協議不涉及啓動過程，可是有其餘做用——這實際上就是 UEFI 官方的設備標識方法，這種標識方法可用於啓動管理器項以及各類其餘用途。出於各類緣由，並非每一種潛在的 EFI 設備都像 UEFI 啓動管理器項同樣起做用（若是你想從視頻適配器啓動，極可能不會成功）。可是啓動菜單中顯然能夠包含指向 PXE 服務器（而不是磁盤分區）的項。UEFI 規範進行了多項規定，能夠向 UEFI 啓動管理器配置中添加除磁盤之外的啓動目標。

可是對咱們而言，只須要考慮鏈接到計算機的通常磁盤便可。既然這樣，咱們來討論下可能遇到的三種啓動項類型。

BIOS 兼容啓動項

在本示例中，Boot0000 和 Boot0004 其實是 BIOS 兼容模式啓動項，而不是原生 UEFI 啓動項。這些啓動項不是經過外部工具添加到 UEFI 啓動管理器配置中的，而是由固件自己生成的——這也是 UEFI 固件實現 BIOS 兼容啓動的常見方式，經過生成 UEFI 啓動管理器項，可觸發指定設備的 BIOS 啓動。至於 UEFI 啓動管理器如何呈現給用戶，這是另外一個問題，咱們稍後討論。根據具體固件及其配置，其中有些項可能沒法顯示。每一項只會具備一個名稱（「CD/DVD Drive」、「Hard Drive」），這表示「若是選中此項，那麼就以 BIOS 兼容模式啓動本磁盤」（其中，對於 Boot0000，「本磁盤」爲 3,0,00，對於 Boot0004，「本磁盤」爲 2,0,00）。

「回退路徑 (Fallback path)」UEFI 原生啓動項

Boot0001 項（我虛構的，實際操做中可能不存在，這裏只是爲了舉例說明）用於通知固件嘗試從特定磁盤啓動（以 UEFI 模式而不是 BIOS 兼容模式），可是並無向固件提供其餘信息。它沒有指定磁盤上的具體啓動目標，而只是讓固件啓動磁盤。

UEFI 規範定義了一種「回退」路徑 (Fallback path)，用於啓動此類啓動管理器項，其工做原理相似於 BIOS 驅動器啓動：它會在標準位置查找某些啓動裝載程序代碼。可是其中的細節和 BIOS 不一樣。

當嘗試以這種方式啓動時，固件真正執行的操做至關簡單。固件會遍歷磁盤上的每一個 EFI 系統分區（按照磁盤上的分區順序）。在 ESP 內，固件將查找位於特定位置的具備特定名稱的文件。在 x86-64 PC 上，固件會查找文件 \EFI\BOOT\BOOTx64.EFI。固件實際查找的是 \EFI\BOOT\BOOT{計算機類型簡稱}.EFI，其中，「x64」是 x86-64 PC 的「計算機類型簡稱」。文件名還有多是 BOOTIA32.EFI (x86-32)、BOOTIA64.EFI (Itanium)、BOOTARM.EFI（AArch32，即32位ARM）和 BOOTAA64.EFI（AArch64，即64位ARM）。而後，固件將執行找到的第一個有效文件（固然，文件須要符合UEFI規範中定義的可執行格式）。

這種機制的設計目的不在於啓動平常使用的操做系統。它的設計目的更像是爲了啓動可熱插拔、與設備無關的介質（如 Live 映像和操做系統介質）。這也是這種機制的常見用途。若是查看 Linux 或其餘操做系統的 UEFI 兼容 Live 或安裝介質，你會發現其中包含 GPT，以及位於（或靠近）設備起始位置的 FAT 分區，該分區的 GPT 分區類型標識爲 EFI 系統分區。在那個分區中，會有一個 \EFI\BOOT 目錄，目錄中至少包含上述特殊命名的文件之一。當以原生 UEFI 模式啓動 Fedora Live 或安裝介質時，就會採用這種機制。BOOTx64.EFI（或其餘）文件將處理剩餘啓動過程，從而啓動介質上包含的真正操做系統。

徹底原生 UEFI 啓動項

Boot0002 和 Boot0003 是存儲設備上所安裝操做系統的「典型」項。這些項顯示了 UEFI 啓動機制的所有優點，不只僅是「今後磁盤啓動」，而是「啓動此特定磁盤上此特定位置中的這一特定啓動裝載程序」。

Boot0002 是由原生 UEFI Fedora 安裝生成的啓動項。Boot0003 是由原生 UEFI OpenSUSE安裝生成的啓動項。按照字面意思，這些啓動項表示「今後分區加載這一文件」。分區指的是 HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d) 這個東西：表示某一特定分區（使用 EFI_DEVICE_PATH_PROTOCOL，我不打算對此進行詳細介紹。若是你經過固件界面和 efibootmgr 與啓動管理器進行交互，你也不須要知道其中的細節）。文件指的是 (\EFI\opensuse\grubx64.efi) 這個東西：它僅表示「加載所述分區上此位置中的文件」。這裏所指的分區基本上始終指的就是充當 EFI 系統分區的那個分區，所以：能夠放心地讓固件訪問 EFI 系統分區。

UEFI 規範提供這一機制，以便操做系統可啓動：操做系統將啓動裝載程序（做用爲加載操做系統內核等）安裝到 EFI 系統分區中，並使用某一名稱（顯然，這一名稱一般來源於操做系統名稱）以及啓動裝載程序（EFI 可執行格式，用於加載操做系統）的位置向 UEFI 啓動管理器配置中添加啓動項。

Linux發行版使用 efibootmgr 工具處理 UEFI 啓動管理器。進行原生 UEFI 安裝時，有關啓動裝載方面，Linux 發行版實際進行的操做至關簡單：它會建立一個 EFI 系統分區（若是不存在此分區），使用相應配置將 EFI 啓動裝載程序（一般爲 grub2-efi，可是也有例外）安裝到 EFI 系統分區中的正確路徑下，而後調用 efibootmgr 添加相應的 UEFI 啓動管理器項（指向其啓動裝載程序）。若是已存在 EFI 系統分區，大部分發行版會使用現有分區（儘管徹底能夠建立新的 EFI 系統分區並使用這個新分區）：咱們已經提到過，UEFI 是一種寬鬆規範，只要在邏輯上遵循其設計，那麼有多少個 EFI 系統分區都沒問題。

配置啓動過程（固件 UI）

上文描述了 UEFI 規範定義的基本機制，用於管理 UEFI 啓動過程。固件用戶界面可能不會明確遵循這一機制，瞭解這一點很是重要。不幸的是，UEFI 規範有意未限制啓動過程的呈現方式或用戶配置啓動過程的方式，這表示——因爲咱們也從事 固件工程——每一個固件會有不一樣的實現方法，而且其中某些固件的實現方法較瘋狂。

許多固件的啓動配置界面較直觀。優秀的固件設計至少會顯示啓動順序以及其中的各個啓動項，容許用戶添加/刪除項、更改啓動順序或在某次特定啓動中忽略原有啓動順序（僅針對那次啓動生效，或直接讓固件啓動特定菜單項，甚至能夠選擇讓固件以 BIOS 兼容模式或 UEFI「回退 (Fallback)」模式「啓動這塊磁盤」，個人固件就能夠這麼操做）。此類界面一般能夠僅按名稱顯示完整的原生 UEFI 啓動項（例如咱們上文提到的 Fedora 和 OpenSUSE 示例）；你須要檢查 efibootmgr –v 的輸出，以詳細瞭解在調用這些項時，它們具體會嘗試並執行哪些操做。

某些固件會嘗試對配置進行抽象和簡化，最終結果參差不齊。例如，若是能夠選擇「啓用或禁用」BIOS 兼容模式，固件頗有可能會爲已鏈接驅動器的 UEFI 啓動管理器配置添加或刪除 BIOS 兼容項。若是能夠選擇「啓用或禁用」原生 UEFI 啓動，那麼在用戶「禁用」原生 UEFI 啓動時，固件頗有可能更改 UEFI 啓動管理器配置，從 BootOrder 中刪除全部原生UEFI啓動項。

請謹記，固件界面中的全部配置選項所執行的操做就是在後臺配置 UEFI 啓動管理器的行爲。若是你能理解以上全部內容，那麼當你更改固件界面中的選項時，你會更容易理解其背後的本質。

在 BIOS 中，系統不會始終嘗試優先從可移動驅動器（CD、USB）進行啓動，而後再從驅動器啓動。根據實際狀況，結果可能有所不一樣。有些 BIOS 固件會優先嚐試從 CD 啓動，而後再嘗試從硬盤啓動（而不是 USB）。試圖安裝新的操做系統時，用戶已習慣於時常檢查 BIOS 配置，以確保啓動順序「正確無誤」。

UEFI 也是如此，可是因爲 UEFI 啓動管理器機制的靈活性/複雜性，這一過程看起來可能顯得陌生而可怕。

在系統嘗試啓動固定啓動項以前，若是想要確保系統使用「回退(Fallback)」機制優先從可移動設備啓動（例如，在安裝 Fedora 時），須要將可移動設備做爲固件的默認啓動項，或須要相應設置固件。根據具體固件界面，可能發現每一個鏈接的可移動設備都有對應的「菜單項」，你只須要調整啓動順序，把你想要的可移動設備放在首位便可，有時候你也會發現能夠直接請求「對此特定磁盤進行 UEFI 恢復啓動」，另外你還可能發現固件會嘗試將配置進行抽象。咱們不知道具體的固件界面是什麼樣，所以難以編寫說明。可是既然你已瞭解背後的工做原理，那麼就可能更容易理解固件用戶界面配置的含義。

配置啓動過程（經過操做系統）

如上所述，與 BIOS 機制不一樣，你能夠從操做系統層面配置 UEFI 啓動過程。若是你的固件比較使人噁心，你可能須要執行此操做才能達成目的。

你可使用以前提過的 efibootmgr 工具來添加、刪除和修改 UEFI 啓動管理器配置中的項，這一工具也具備其餘豐富功能。你能夠更改啓動順序。你能夠更改下次啓動時的首要啓動項，而不須要使用 BootOrder 列表（若是你或其餘某些工具已經進行過配置，efibootmgr –v 的輸出將包括 BootNext 項，說明下一次啓動將加載的菜單項）。Windows 下也有相似的工具。所以若是你難以從固件界面配置 UEFI 啓動，可是你能夠啓動某種原生 UEFI 操做系統，那麼你能夠考慮從操做系統（而不是固件 UI）進行啓動配置。

結論：

• UEFI固件包含某些很是相似於啓動菜單的內容。
• 可使用 efibootmgr –v 從任何原生 UEFI 啓動的 Linux 操做系統中查詢 UEFI 啓動配置，也可使用 efibootmgr 更改配置（有關詳細信息，請參閱 man 頁面）。
• 「啓動菜單」能夠包含表示「以 BIOS 兼容模式啓動此磁盤」，「經過回退路徑 (Fallback path) 以原生 UEFI 模式啓動此磁盤」（將使用上文所述的「尋找 BOOT(某字符串).EFI」方式），或「啓動此特定位置（幾乎始終爲 EFI 系統分區）中的特定 EFI 格式的可執行文件」等含義的項。
• UEFI 規範嘗試一種優秀、簡潔的設計，讓全部操做系統都將其自身的啓動裝載程序安裝到 EFI 系統分區中，而後在「啓動菜單」中添加指向這些啓動裝載程序的項，同時不得干涉其餘目標的啓動過程。
• 你的固件 UI 能夠自由實現此機制，雖然具體的實現結果參差不齊。

在 UEFI 計算機上安裝操做系統

咱們快速瀏覽下上文中與在 UEFI 計算機上安裝操做系統相關的具體結果。

原生 UEFI 啓動和 BIOS 兼容啓動

用戶有時會忽略如下事項：

• 若是以「原生 UEFI」模式啓動安裝介質，安裝介質將以原生 UEFI 模式安裝操做系統：它將嘗試向 EFI 系統分區寫入 EFI 格式的啓動裝載程序，並嘗試向 UEFI 啓動管理器的「啓動菜單」中添加啓動項，用於啓動該啓動裝載程序。
• 若是以「BIOS 兼容」模式啓動安裝介質，安裝介質將以 BIOS 兼容模式安裝操做系統：它將嘗試向磁盤上的 MBR 空間寫入 MBR 類型的啓動裝載程序。

這適用於（如今暫時忽略其中的無關警告）我接觸過的全部操做系統。所以你可能確實想了解，如何在固件層選擇以原生 UEFI 模式啓動可移動設備，以及如何在固件層選擇以 BIOS 兼容模式啓動可移動設備，確保在安裝時能夠隨意選擇須要使用的模式。

若是以 BIOS 兼容模式啓動安裝介質，那麼你絕對沒法成功進行操做系統的原生 UEFI 安裝，由於安裝程序沒法配置 UEFI 啓動管理器（除非以原生 UEFI 模式啓動安裝介質）。

理論上，在以原生 UEFI 模式啓動以後，操做系統的安裝程序可經過 BIOS 模式安裝該操做系統，即，將啓動裝載程序寫入磁盤 MBR，可是大部分安裝程序沒法執行此操做，這種作法比較可取。

肯定啓動模式

有時候，在啓動操做系統安裝程序以後，你不肯定啓動模式爲原生 UEFI 模式仍是 BIOS 兼容模式。別擔憂。有幾種簡單方法能夠肯定啓動模式。最簡單的方法之一是嘗試讀取 UEFI 啓動管理器。若是你啓動了 Linux 安裝程序或環境，而且能夠運行 shell（例如，在 Fedora 安裝程序中是 Ctrl-Alt-F2），請運行 efibootmgr –v。若是你啓動的是原生 UEFI 模式，那麼就能夠看到上文所示的 UEFI啓動管理器配置。若是你啓動的是 BIOS 兼容模式，那麼會看到相似如下內容：

Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables.
Try 'modprobe efivars' as root.

若是啓動了其餘操做系統，你能夠嘗試運行該操做系統的內置實用程序，讀取 UEFI 啓動管理器，並查看是否顯示了明確輸出或相似錯誤。或者你能夠檢查系統日誌並搜索「efi」和/或「uefi」，從中可能發現蛛絲馬跡。

啓用原生 UEFI 啓動

若要啓用原生 UEFI 模式的啓動，那麼操做系統安裝介質必須明確符合咱們剛剛說明的全部規範：具備 GUID 分區表，和 EFI 系統分區，啓動裝載程序位於正確的「回退」路徑 (Fallback path) 中—\EFI\BOOT\BOOTx64.EFI（其餘平臺可能會有其餘名稱）。若是沒法以原生 UEFI 模式啓動安裝介質，而且沒法查出緣由，那麼請檢查安裝介質是否知足上述條件。顯然，當使用 livecd-iso-to-disk 工具將 Fedora 映像寫入 USB 存儲器時，你必須傳遞 –efi 參數，才能將存儲器配置爲可用 UEFI 模式啓動。

強制使用 BIOS 兼容啓動

若是你的固件難以經過 BIOS 兼容模式從可移動介質啓動，可是你又確實想經過這種方式啓動，那麼可使用一些小把戲：徹底禁用該介質的原生 UEFI 啓動模式。能夠經過清除全部 EFI 系統分區來輕鬆執行此操做（或者，若是使用 livecd-iso-to-disk 從 Fedora 映像建立 USB存儲器，那麼只需去掉 –efi 參數，存儲器就會變爲不可經過 UEFI 模式啓動）。若是執行完此操做之後，你的固件仍然沒法以 BIOS 兼容模式啓動介質，那麼就去吐槽你的固件供應商吧（若是還沒吐槽過）。

磁盤格式（MBR vs. GPT）

其餘注意事項以下：

• 若是想執行「BIOS 兼容」類型的安裝，那麼須要安裝到 MBR 格式的磁盤。
• 若是想執行原生 UEFI 安裝，那麼須要安裝到 GPT 格式的磁盤。

固然，爲了給用戶找不自在，許多固件能夠經過 BIOS 模式從 GPT 格式的磁盤啓動。事實上，從技術層面而言，也要求 UEFI 固件能從 MBR 格式的磁盤以 UEFI 模式啓動（雖然沒法保證）。可是你應當儘量避免這種狀況。這些注意事項很是重要，由於許多用戶都曾深受其害。例如，以原生 UEFI 模式啓動操做系統安裝程序，而後試圖直接安裝到 MBR 格式的磁盤是很是不明智的。頗有可能失敗。多數現代操做系統安裝程序將把磁盤自動從新格式化爲正確格式（若是你容許安裝程序完全清除磁盤數據），可是，若是你嘗試讓安裝程序「對此 MBR 格式的磁盤執行原生 UEFI 安裝，而且不要從新格式化這塊磁盤，由於上面有重要數據」，那麼就頗有可能失敗，儘管技術層面而言，UEFI 規範提到了這種配置。具體而言，至少 Windows 和 Fedora 會明確禁止這種配置。

檢查磁盤格式

你可使用 parted 實用程序檢查給定磁盤的格式：

[adamw@adam Downloads]$ sudo parted /dev/sda GNU Parted 3.1 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Model: ATA C300-CTFDDAC128M (scsi) Disk /dev/sda: 128GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk 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 中經過執行 mklabel gpt 或 mklabel msdos 將磁盤從新格式化爲其餘類型分區表。這會破壞磁盤內容。

對於多數操做系統的安裝程序而言，若是你採用的磁盤配置會清空目標磁盤的全部內容，那麼根據執行的安裝類型，安裝程序就會自動使用最合適的配置從新格式化磁盤。可是若是你想使用現有磁盤而不格式化，那麼你須要檢查該磁盤的格式並三思然後行。

執行手動分區時處理 EFI 系統分區

我只能針對 Fedora 給出權威建議，可是其中的主要內容可能也適用於其餘發行版/操做系統。

執行原生 UEFI 安裝，而且採用 GPT 格式的磁盤時，或者容許 Fedora 從新格式化磁盤（經過刪除全部現有分區）時，若是容許 Fedora 自動處理分區，那麼 Fedora 就會自動處理 EFI 系統分區。

可是，若是使用自定義分區，Fedora 會要求指定 EFI 系統分區，以供安裝程序使用。若是不執行此步驟，安裝程序會報錯（錯誤消息的含義不明）並拒絕啓動安裝。

所以，若是執行原生 UEFI 安裝並使用自定義分區，須要確保類型爲「EFI 系統分區」的分區已掛載到 /boot/efi（這是 Fedora 查找 EFI 系統分區的路徑）。若是系統上存在現有 EFI 系統分區，那麼僅需將其掛載點設置爲 /boot/efi 便可。若是尚未 EFI 系統分區，那麼請建立一個分區，將其類型設置爲 EFI 系統分區，大小至少爲 200MB（建議 500MB），而後將其掛載點設置爲 /boot/efi。

具體示例

總結：若是購買了 Windows 8 或更高版本的操做系統，那麼你的 Windows 基本上確定是經過原生 UEFI 安裝到 GPT 格式磁盤的。這表示若是你想安裝其餘操做系統，並與 Windows 共存，那麼須要經過原生 UEFI 方式安裝操做系統。若是你不喜歡 UEFI，而且想要用回老掉牙的 BIOS，那麼恐怕就得清空整個原生 UEFI 的 Windows，並且須要從新將磁盤格式化爲 MBR。

缺陷

上文解釋了 UEFI 的啓動原理(至少解釋得差很少了)。我這種描述方法應該還能夠吧？

可是，UEFI 並不完美，也有許多問題。

細心的讀者可能已經留意，我曾經提到過，UEFI 規範提供了一種機制。這種說法很嚴謹，也很重要。因爲 UEFI 規範是一種「普遍共識」，所以其主要缺點之一（就特定方面而言）是並未提供具體實現。

若是仔細閱讀 UEFI 規範，就會發現 UEFI 規範的基本方式是定義 UEFI 兼容固件必須支持的一系列功能。可是 UEFI 規範並無嚴格規定這些功能的具體實現方法。

所以，UEFI 規範只要求系統固件必須遵循其中描述的全部內容，以便知足 UEFI 兼容固件的要求。可是，規範自己未規定操做系統「應該」或「必須」怎麼作，而且 UEFI 規範也沒有規定固件不得支持（或者不指望支持）的功能。換言之，在制定 UEFI 固件時，須要支持 GPT 格式的磁盤和 FAT 格式的 EFI 系統分區，而且必須以標準格式讀取 UEFI 啓動管理器項等等——可是也能夠隨意添加其餘未規定的功能。

從 UEFI 規範中不難發現其中的隱喻——UEFI 規範仔細設置了一種良好機制，用於在固件層處理操做系統（或其餘啓動項）選擇。可是 UEFI 規範並不要求必定要這麼作，其餘廣受讚譽的規範也沒有相似規定。

所以，在實際使用時，咱們可能遇到各類複雜狀況。例如，Apple Mac 的 HFS+ 分區中隨附了某些啓動裝載程序。UEFI 規範提到，UEFI 兼容固件必須支持特定 GPT 分區類型的 UEFI FAT 分區（標識爲「EFI 系統分區」），可是 UEFI 規範並無提到固件不能識別其餘文件系統類型並從中加載啓動裝載程序。（此類分區是否應視爲「EFI 系統分區」，這很難回答，在此不作探討。）

要是全部廠商都能按照 UEFI 規範嚴格使用 EFI 系統分區，那就不會有這麼多問題了。可是 Apple 畢竟是 Apple，它的產品設計領先於其餘廠商，率先設計出了能夠從 HFS+ 分區讀取和加載代碼的固件，致使如今其餘廠商不得不緊隨 Apple 的腳步，除非他們不打算支持 Mac。在啓動過程設計中，Apple 進行的工做遠超出 UEFI 規範的範圍，所以，若是你想讓其餘操做系統以美觀的圖標或其餘形式顯示在 Mac 的圖形啓動菜單上，你所要作的操做將超出 UEFI 規範的建議範圍。

還有各類相似的極端情況，令人煩不勝煩，可是咱們先無論了。這篇文章夠長的了。

另外，就像以前提到過的，UEFI 規範並無對機制的具體呈現方式進行約束。所以，若是一些軟件公司設計的操做系統符合 UEFI 規範，而且能夠安裝 EFI 啓動裝載程序，並明確命名 EFI 啓動管理器項（例如，Fedora 和 Windows），那麼若是要向用戶提供某種相對辨識度較高的漂亮界面，讓用戶能夠從中選擇啓動 Windows 或 Fedora，就得看固件自己設計得怎麼樣。固件設計得越糟糕，操做系統工程師就越不會遵照 UEFI 規範，他們越可能在固件層上另起爐竈。

說句公道話，咱們能夠在操做系統層實現更多功能。咱們能夠用更整潔直觀的方式實現 efibootmgr 的全部功能——例如，咱們能夠採用「無視下一次啓動時的啓動順序，直接啓動此項」，同時將「從新啓動到 Windows」做爲選項之一。若是開發人員可以用更直觀的方式展示 efibootmgr 的全部功能，那將會很是不錯。Windows 8 系統在必定程度上採用了這種方式——例如，用戶能夠從 Windows 8 設置菜單中將系統從新啓動到固件 UI。可是這還不夠。

這些實在使人慾哭無淚，由於 UEFI 原本能夠更好地進行統一。對於多重啓動，BIOS 不提供任何類型的規範或標準，所以徹底須要在固件層上處理多重啓動。咱們（這一產業）已經提出了某種處理多重啓動的規範，可是咱們從未將其付諸實施，所以最終不了了之。而每種操做系統都採用本身的多重啓動方法，大量開發人員也本身寫了啓動裝載程序，試圖包攬全部操做系統。而全部操做系統和獨立的啓動裝載程序難以互相兼容。我想說的是，在 UEFI 誕生以前，多重啓動的實現方式一團混亂。

若是 UEFI——或者基於 UEFI 的某種規範——要求全部廠商遵循 UEFI 提出的規範，並要求固件提供直觀的用戶界面，那將會終結現階段的混亂狀況。可是現實不如人意，所以 UEFI 的狀況徹底可能比 BIOS 更糟糕。若是大量固件沒有爲 UEFI 啓動管理器機制提供良好的 UI，那麼操做系統供應商可能放棄 UEFI 啓動管理器機制（或選擇性地進行支持），轉而在 UEFI 中重現 BIOS 多重啓動的混亂狀況——如此一來，咱們就得收拾全部爛攤子，外加 UEFI 啓動管理器層的其餘影響。在整個 UEFI 啓動管理器機制上，用戶可能裝有多個啓動裝載程序，互相爭搶裝載多個操做系統的控制權，而 UEFI 啓動管理器機制只會機械地處理各類變量，而沒法解決這種混亂狀況。

這不是某人靈光閃現的荒唐想法，而是可能實際發生的真實情形。

另外，在這方面產生的 UEFI 缺陷是由一時疏忽引發的——這些缺陷不受委員會控制，也不是某人故意爲之的結果。若是你的系統固件很坑爹，沒法讓你輕鬆訪問 UEFI 啓動管理器，那麼你的發泄對象不該該是 UEFI 論壇或微軟，固然也不是 Fedora 或者我。你應該歸咎於系統/主板製造商和他們僱用的傻逼固件開發人員。凡是大腦健全的人，都能看出來，UEFI 規範已經明確說明，爲 UEFI 啓動管理器提供某種直觀的用戶界面是很是有益的，全部反人類的固件都是一堆垃圾代碼。的確，UEFI 論壇已經意識到固件工程師難以脫離現有約束從新學習新規範，可是，固件工程師最終仍是應該與時俱進。

簡單來講，「全部固件都是垃圾代碼」。這句話一般很是準確。

安全啓動 (Secure Boot)

咱們最後要介紹的，就是安全啓動 (Secure Boot)。

安全啓動 (Secure Boot) 並不神奇，也不復雜。纔怪。安全啓動 (Secure Boot) 複雜得要命，可是其理論並不複雜。安全啓動 (Secure Boot) 自己也並不邪惡。事實就是如此，你也應當認同這一事實，除非你認爲GPG也有惡意。

在 UEFI 規範（2.4A 版本）的第 28 章對安全啓動 (Secure Boot) 進行了定義。這種機制事實上很是明智。可是其原理卻很是簡單。UEFI 規範規定固件能夠包含一系列簽名，並拒絕運行未簽名或簽名與固件中包含的簽名不一致的 EFI 可執行文件。

就這麼簡單?固然不是了，這只是一種簡單歸納。安全問題很複雜，所以纔會產生經過安全啓動 (Secure Boot) 來實現真正安全啓動鏈的各類方法。mjg59 能夠進行詳細介紹，或者你能夠完整閱讀第 28 章。可是其中只涉及了基本概念。

使用公開密鑰加密來驗證某個文件完整性的方法很難判斷其好壞。幾乎全部 Linux 發行版都依賴這種加密方法——咱們爲軟件包簽名，在嘗試安裝未使用咱們的密鑰之一簽名的軟件包時，軟件包管理器將發出警告。這不是咱們的錯，我也不認爲會有人由於以這種方式使用公開密鑰加密進行簽名而歸咎於操做系統自己。從字面上看，安全啓動 (Secure Boot) 與這種普遍承認的機制徹底相同，只不過安全啓動 (Secure Boot) 適用於啓動鏈。因爲一撮媒體人找錯了槽點，並揪着不放，致使大衆受到了普遍誤導，認爲安全啓動 (Secure Boot) 是洪水猛獸。

UEFI 規範中定義的安全啓動 (Secure Boot) 並無對固件所信任的密鑰形式及其來源做出規定，我也不打算介紹全部細節，由於過於枯燥乏味，並且本文已經挺長了。可是總的來講，UEFI 規範只對執行啓動鏈的加密驗證進行了定義。UEFI 規範甚至沒有涉及用於執行這一過程的策略可能產生的問題。這原本並無錯，由於這樣能夠保證其靈活性，而且 UEFI 規範容許在多個層面配置涉及的全部機制。UEFI 規範中未說起微軟，也沒有和微軟互相勾結。若是你不信，那麼你能夠閱讀 UEFI 規範。我已經提供了全部說明。字面上來講，對於那些反對在固件規範中將啓動裝載程序加密驗證機制做爲可選功能的人，我不予置評。

實際使用安全啓動 (Secure Boot)

有關安全啓動 (Secure Boot) 的全部不滿並不針對安全啓動 (Secure Boot) 機制自己——雖然發出這些不滿的人可能不這麼認爲——而是針對安全啓動 (Secure Boot) 在實際操做中的特定實現方式。

咱們惟一在乎的是，對於預裝 Windows 8 或更高版本 Windows 的 PC 而言，安全啓動 (Secure Boot) 是默認開啓的。

微軟將這些稱爲「Windows 硬件認證要求」。這些要求並非什麼絕密內容，全部人均可以在互聯網上閱讀。

若是想從微軟那裏以低廉的價格得到預裝 Windows 的批量許可，並在機箱上貼有「微軟認證」標籤，那麼你必須符合這些認證要求。微軟的約束力有限：他們不是美國或其餘國家/地區的法律制定者，不管其餘人怎麼想。即便你銷售的 PC 不符合這些要求，比爾•蓋茨也不會拿你怎麼樣，前提是你不須要預裝廉價的 Windows 副本和那張「微軟認證」標籤。對於不符合微軟許可計劃的在售 PC，事實上並不要求如何配置安全啓動 (Secure Boot)，甚至根本不須要提供安全啓動 (Secure Boot) 功能。具備 UEFI 2.2 或更高版本兼容固件的 PC 必須提供安全啓動 (Secure Boot) 功能，可是並無規定具體的實現方法（包括關閉安全啓動 (Secure Boot) 的方法）。

若是你對安全啓動 (Secure Boot) 意見很大，那麼就別找藉口了，立刻去讀讀微軟認證要求吧（http://msdn.microsoft.com/en-us/library/windows/hardware/dn423132.aspx）。你能夠搜索「Secure Boot」來閱讀相關內容。從「System.Fundamentals.Firmware.UEFISecureBoot」一節開始。

你最好讀一遍，可是我對其內容進行了總結。

符合微軟認證要求的計算機必須知足如下條件：

• 默認啓用安全啓動 (Secure Boot)（服務器除外）
• 在其信任密鑰列表中包含微軟的密鑰
• 啓用安全啓動 (Secure Boot) 時，必須禁用 BIOS 兼容模式（若是沒記錯的話，UEFI 規範也有此要求）
• 支持簽名黑名單

符合微軟認證要求的 x86 計算機 還必須知足如下附加條件：

• 容許 天然人禁用安全啓動 (Secure Boot)
• 容許 天然人啓用自定義模式，以及修改固件的信任密鑰列表

符合微軟認證要求的 ARM 計算機 還必須知足如下附加條件：

• 不容許 天然人禁用安全啓動 (Secure Boot)
• 不容許 天然人啓用自定義模式，以及修改固件的信任密鑰列表

是的，你沒看錯。對於 x86 計算機，微軟認證要求明確規定了天然人用戶應當可以徹底控制安全啓動 (Secure Boot)（啓用或禁用），或徹底控制安全啓動 (Secure Boot) 的信任密鑰列表。另外一個重點是，儘管認證要求規定，信任密鑰列表必須包括微軟的密鑰，可是其中沒有規定不容許包括其餘密鑰。微軟認證要求也明確容許系統包含其餘任意數量的信任密鑰。

這些要求並不徹底出於微軟的好意，之因此做出這些規定，是由於若是不這麼作的話，微軟將面臨大量訴訟2。真正瞭解 UEFI 和安全啓動 (Secure Boot) 的用戶可能不會曲解微軟認證要求，這些要求很是清晰明確。這些要求旨在確保認證系統的全部者能徹底控制安全啓動 (Secure Boot)，事實上這些要求也確實成功確保了這一條件。

若是你有包含 Windows 認證的 x86 系統，可是不容許你禁用安全啓動 (Secure Boot)，那麼這就直接違反了認證要求，你應該立刻投訴。若是市面上存在大量這類系統，那麼咱們確定會有麻煩，可能要給那些巨頭廠商提起訴訟了。可是目前爲止，事實並不是如此。在我見過的全部 x86 Windows 認證系統中，其固件都有「禁用安全啓動 (Secure Boot)」選項。

對於 ARM 計算機，認證要求顯然更變態：其中的規定和 x86 徹底相反，不容許禁用安全啓動 (Secure Boot)，也不容許系統全部者更改信任密鑰。很是糟糕且不合理。這使得微軟認證 ARM 系統成爲了一個封閉的環境。值得注意的是，其餘主要 ARM 平臺甚至更糟糕。Apple 在全部 iDevice 上鎖定了啓動裝載程序，並且大部分 Android 設備的啓動裝載程序也是鎖定的。

若是你計劃購買微軟認證 ARM 設備，請注意這一問題，你將沒法控制設備上的啓動項。若是你對此反感，那就不要購買這樣的設備，也不要購買 iDevice 或啓動裝載程序處於鎖定狀態的 Android 設備（你能夠購買啓動裝載程序未鎖定或沒法鎖定的 Android 設備，可是須要事先進行調查研究）。

目前，就 x86 設備自己而言，微軟的認證要求實際上明確保障了用戶自由啓動系統的權利。這是件好事。

建議

如下內容是我在管理系統啓動方面的通常建議，不保證其準確性、可靠性或安全性。

• 若是能夠的話，每臺計算機只安裝一個操做系統。 若是你須要一個以上操做系統，那就多買幾臺計算機，或使用虛擬機。這麼作的話，事情就簡單多了，並且不管你的固件是 BIOS 或 UEFI，或在 UEFI 系統上使用 BIOS 兼容啓動，都沒什麼關係了。你在使用計算機時也會輕鬆許多。
• 若是你確實須要在每臺計算機上安裝多個操做系統，那麼請在每塊磁盤上至少安裝一個操做系統。 若是你比較熟悉 BIOS 啓動，並且也不須要安全啓動 (Secure Boot) 功能，在這種狀況下，對於 UEFI 系統，請優先使用 BIOS 兼容啓動。這樣一來，可能不會有那麼多麻煩，也不會形成數據丟失。若是每塊磁盤只安裝一個操做系統，那麼你也能夠混合使用原生 UEFI 和 BIOS 兼容模式。
• 若是你堅持要在每塊磁盤上安裝多個操做系統， 那麼請先理解本文所寫內容。這麼作無異於自做孽，不可活，出了問題可別責怪操做系統供應商。另外，在這種狀況下，也不要混用原生 UEFI 和 BIOS 兼容模式，不然就是雪上加霜。
• 若是你在使用 UEFI 原生啓動，而且不打算本身編譯內核/內核模塊或在 Linux 上使用 NVIDIA/ATI 私有驅動程序，那麼最好啓用安全啓動 (Secure Boot)。這不會有什麼反作用，反而能夠帶來額外的安全性，用以應對某些卑鄙的攻擊類型（儘管目前不多被利用）。
• 若是打算編譯內核/內核模塊或使用 NVIDIA/ATI 私有驅動程序，那就最好禁用安全啓動 (Secure Boot)。或者你能夠啓用安全啓動 (Secure Boot)，而後閱讀有關配置信任鏈和對內核/內核模塊簽名的說明。可是這一過程至少須要好幾天。
• 不要在 MBR 格式的磁盤上進行原生 UEFI 安裝，也不要在 GPT 格式的磁盤上進行 BIOS 兼容安裝（若是沒記錯的話，除非你的磁盤大小大於 2.2TB，由於 MBR 格式沒法識別那麼大的磁盤。若是想在那麼大的磁盤上進行 BIOS 兼容安裝，那麼你可能會卡在 BIOS+GPT 的組合上。雖然這種組合能夠正常運行，可是有點不靠譜，並且會牽涉到臭名昭著的「BIOS Boot 分區」）。
• 相信 mjg59 及其餘權威人士，包括我。

1. 這一整節都是簡化過的內容——當啓動已安裝的操做系統時，不管啓動裝載程序是否安裝在「ESP」上，對固件都沒有影響；固件只會讀取啓動管理器項，而後嘗試訪問特定分區並執行特定可執行文件，具體請參閱 pjones 的說明。可是通常會使用 ESP 來進行啓動過程，由於 UEFI 規範中有相應規定，並且這個分區也很方便，固件能夠讀取其文件系統。理論上來講，在固件執行可移動介質/回退路徑 (Fallback path) 啓動時，ESP 將不起做用。

2. 注意，這只是個人我的推斷。在整個規範的制定過程當中，我都沒有參與，也沒人告訴我這些內容。可是根據已知事實，明顯能夠得出這一推斷