（譯）UEFI 啟動：實際工作原理

轉載位址：http://www.tuicool.com/articles/NNf26jB

本文是我翻譯自國外技術部落格的一篇文章，其中講述了 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 格式的變種（包括 FAT12、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 實用程式檢查給定磁盤的格式：

[[email protected] 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. 注意，這隻是我的個人推斷。在整個規範的制定過程中，我都沒有參與，也沒人告訴我這些内容。但是根據已知事實，明顯可以得出這一推斷。

轉載于:https://www.cnblogs.com/jerain6312/articles/4939423.html