統一可延伸韌體介面
此條目可參照英語維基百科相應條目來擴充。 (2020年7月28日) |
統一可延伸韌體介面（英語：Unified Extensible Firmware Interface，縮寫UEFI）是一種個人電腦系統規格，用來定義作業系統與系統韌體之間的軟件介面，作為BIOS的替代方案[1]。可延伸韌體介面負責加電自檢（POST）、聯絡作業系統以及提供連接作業系統與硬件的介面。
UEFI的前身是Intel在1998年開始開發的Intel Boot Initiative，後來被重新命名為可延伸韌體介面（Extensible Firmware Interface，縮寫EFI）。Intel在2005年將其交由統一可延伸韌體介面討論區（Unified EFI Forum）來推廣與發展，為了凸顯這一點，EFI也更名為UEFI（Unified EFI）。UEFI討論區的創始者是11家知名電腦公司，包括Intel、IBM等硬件廠商，軟件廠商Microsoft，及BIOS廠商安邁科技、Insyde、Phoenix。
規格
編輯可延伸韌體介面（EFI）最初是由英特爾開發，於2002年12月英特爾釋出其訂定的版本——1.1版，之後英特爾不再有其他關於EFI的規範格式發佈。有關EFI的規範，英特爾已於2005年將此規範格式交由UEFI討論區來推廣與發展，後來並更改名稱為Unified EFI（UEFI）。UEFI討論區於2007年1月7日釋出並行放2.1版本的規格，其中較1.1版本增加與改進了加密編碼（cryptography）、網絡認證（network authentication）與用戶介面架構（User Interface Architecture）。
相關方面的制定
編輯2009年5月9日，發佈2.3版本。截至今日為止，2.9版是最新的公開的版本。
產生
編輯
眾所周知，英特爾在近二十年來引領以x86系列處理器為基礎的PC技術潮流，其產品如CPU，晶片組等在PC生產線中佔據絕對領導的位置。因此，不少人認為此舉顯示英特爾公司欲染指韌體產品市場的野心。事實上，EFI技術源於英特爾安騰處理器（Itanium）平台的推出。安騰處理器是英特爾瞄準伺服器高端市場投入近十年研發力量設計產生的與x86系列完全不同的64位元新架構。在x86系列處理器進入32位元的時代，由於相容性的原因，新的處理器（80386）保留16位元的執行方式（真實模式），此後多次處理器的升級換代都保留這種執行方式。甚至在包含EM64T技術的至強系列處理器中，處理器加電啟動時仍然會切換到16位元的真實模式下執行（BIOS）。英特爾將這種情況歸咎於BIOS技術的發展緩慢。自從IBM PC相容機廠商通過淨室的方式複製出第一套BIOS源程式，BIOS就以16位元組譯代碼，暫存器參數呼叫方式，靜態連結，以及1MB以下主記憶體固定編址的形式存在十幾年。雖然由於各大BIOS廠商近年來的努力，有許多新元素添加到產品中，如PnP BIOS、ACPI、傳統USB裝置支援等等，但BIOS的根本性質沒有得到任何改變。這迫使英特爾在開發新的處理器時，都必須考慮加進使效能大大降低的相容模式。用一個比喻來講：這就像保時捷新一代的全自排跑車，被人套上去一個蹩腳打檔器。
然而，安騰處理器並沒有這樣的顧慮，它是一個新生的處理器架構，系統韌體和作業系統之間的介面都可以完全重新定義。並且這一次，英特爾將其定義為一個可延伸的，標準化的韌體介面規範，不同於傳統BIOS的固定的，缺乏文件的，完全基於經驗和晦澀約定的一個事實標準。基於EFI的第一套系統產品的出現至今已經有五年的時間，如今，英特爾試圖將成功運用在高端伺服器上的技術推廣到市場佔有率更有優勢的PC產品線中，並承諾在2006年間會投入全力的技術支援。
與BIOS的比較
編輯二者顯著的區別就是UEFI是用模組化，C語言風格的參數堆疊傳遞方式，動態連結的形式構建的系統，較BIOS而言更易於實現，容錯和糾錯特性更強，縮短了系統研發的時間。它可以執行於x86-64、IA32、ARM等架構上（在個人電腦上通常是x86-64平台），突破傳統16位元代碼的定址能力，達到處理器的最大定址。它利用載入UEFI驅動程式的形式，辨識及操作硬件，不同於BIOS利用掛載真實模式中斷的方式增加硬件功能。後者必須將一段類似於驅動程式的16位元代碼（如RAID卡的Option ROM）放置在固定的0x000C0000至0x000DFFFF之間儲存區中，執行這段代碼的初始化部分，它將掛載真實模式下約定的中斷向量向其他程式提供服務。例如，VGA圖形及文字輸出中斷（INT 10h），磁碟存取中斷服務（INT 13h）等等。BIOS以真實模式執行，因此這段記憶體空間很有限（在真實模式下僅能尋址最多1MB的記憶體），BIOS對於所需放置的驅動程式代碼大小超過空間大小的情況無能為力。另外，BIOS的硬件服務程式都以16位元代碼的形式存在，這就給執行於保護模式或長模式的作業系統訪問其服務造成了困難。因此BIOS提供的BIOS中斷呼叫在現實中只能提供給作業系統的啟動程式或MS-DOS類作業系統使用[2]。而UEFI系統下的驅動程式可以由EFI Byte Code（EBC）編寫而成，EFI Byte Code是一組專用於EFI驅動程式的虛擬機器語言，必須在UEFI驅動程式執行環境（Driver Execution Environment，DXE）下被解釋執行。由於UEFI驅動程式開發簡單，所有的PC部件提供商都可以參與，情形非常類似於現代作業系統的開發模式，這個開發模式曾使Windows在短短的兩三年時間內成為功能強大，效能優越的作業系統。基於UEFI驅動模型（UEFI driver model，UDM）可以使UEFI系統接觸到所有的硬件功能，在作業系統執行以前瀏覽萬維網站，實現圖形化、多語言的BIOS設置介面，或者無需執行作業系統即可線上更新BIOS等等不再是天方夜譚，甚至實現起來也非常簡單。這對基於傳統BIOS的系統來說是件難以實現的任務，在BIOS中添加幾個簡單的USB裝置支援都曾使很多BIOS設計師痛苦萬分，更何況除了添加對無數網絡硬件的支援外，還得憑空構建一個16位元模式下的TCP/IP協定棧。
一些人認為BIOS只不過是由於相容性問題遺留下來的無足輕重的部分，不值得為它花費太大的升級努力。而反對者認為，當BIOS的出現約制了PC技術的發展時，必須有人對它作必要的改變。
與作業系統的關係
編輯UEFI在概念上類似於一個低階的作業系統，並且具有操控所有硬件資源的能力。不少人感覺它的不斷發展將有可能代替現代的作業系統。事實上，EFI的締造者們在第一版規範出台時就將EFI的能力限制於不足以威脅作業系統的統治地位。首先，它只是硬件和預啟動軟件間的介面規範；其次，UEFI環境下不提供中斷的機制，也就是說每個UEFI驅動程式必須用輪詢（polling）的方式來檢查硬件狀態，並且需要以解釋的方式執行，較作業系統下的機械碼驅動效率更低；再則，UEFI系統不提供複雜的緩衝記憶體保護功能，它只具備簡單的緩衝記憶體管理機制，具體來說就是指執行在x64或x86處理器的長模式或保護模式下，以最大定址能力為限把緩衝記憶體分為一個平坦的段（Segment），所有的程式都有權限存取任何一段位置，並不提供真實的保護服務。當UEFI所有組件載入完畢時，便會啟動作業系統的啟動程式，如果UEFI韌體內建UEFI Shell，也可以啟動UEFI Shell命令提示。UEFI應用程式（UEFI Application）和UEFI驅動程式（UEFI driver）是PE格式的.efi檔案，可用C語言編寫。在UEFI開機模式下，作業系統的啟動程式也是UEFI應用程式，啟動程式的EFI檔案儲存在EFI系統分區（ESP）上[3]。
UEFI韌體區分架構，在UEFI開機模式下，通常只能執行特定架構的UEFI作業系統和特定架構的EFI應用程式（EBC程式除外）。比如，採用64位元UEFI韌體的PC，在UEFI開機模式下只能執行64位元作業系統啟動程式；而在Legacy開機模式（即BIOS相容開機模式）下，既可以執行16位元的作業系統（如DOS），也可以執行32位元作業系統和64位元作業系統。
組成
編輯一般認為，UEFI由以下幾個部分組成：
- Pre-EFI初始化模組（PEI）
- UEFI驅動程式執行環境（DXE）
- UEFI驅動程式（UEFI driver）
- 相容性支援模組（CSM）
- UEFI高層應用（UEFI Application）
- GUID磁碟分區表
- 系統管理模式（SMM）
Pre-EFI初始化程式在系統開機的時候最先得到執行，它負責最初的CPU，晶片組及主記憶體的初始化工作，緊接着載入UEFI的驅動程式執行環境（DXE）。當DXE被載入執行時，系統便具有了列舉並載入其他UEFI驅動程式的能力。DXE列舉並載入各種匯流排（包括PCI、SATA、USB、ISA）及硬件的UEFI驅動程式。例如一個具PCI-E匯流排介面的RAID儲存配接器，其UEFI驅動程式一般會放置在這個裝置的Option ROM中。在UEFI規範中，一種突破傳統MBR磁碟分區結構限制的GUID磁碟分區系統（GPT）被引入，新結構中，磁碟的主分區數不再受限制（在MBR結構下，只能存在4個主分區），另外UEFI+GPT結合還可以支援2.1 TB以上硬碟。在眾多的分區類型中，EFI系統分區可以被UEFI韌體存取，可用於存放作業系統的引導程式。UEFI韌體通過執行EFI系統分區中的啟動程式啟動作業系統。CSM是在x86平台UEFI系統中的一個特殊的模組，它將為不具備UEFI引導能力的作業系統以及16位元的傳統Option ROM提供類似於傳統BIOS的系統服務。在載入作業系統後，UEFI的SMM程式繼續執行，提供ACPI等服務[4]。
發展
編輯英特爾無疑是推廣EFI的積極因素，近年來由於業界對其認識的不斷深入，更多的廠商正投入這方面的研究。包括英特爾，AMD在內的一些PC生產廠家聯合成立了UEFI討論區。另外各大BIOS提供商如Insyde，Phoenix，AMI等，他們原先被認為是EFI發展的阻礙力量，現在也不斷的推出各自的解決方案。分析人士指出，這是由於BIOS廠商在EFI架構中重新找到了諸如Pre-EFI啟動環境之類的市場位置，然而隨着EFI在PC系統上的成功運用，以及英特爾新一代晶片組的推出，這一部分市場份額將會不出意料的在英特爾的掌控之中。2011年以後生產的零售主機板大多數採用UEFI技術。隨後，微軟又要求，預裝Windows 8的電腦，必須採用UEFI開機模式，以及Secure Boot。部分採用EFI技術的BIOS並不支援EFI開機。
作業系統支援
編輯Linux內核自2000年開始，已經支援EFI啟動。早期使用ELILO作為EFI下的啟動程式。現在，GRUB的EFI版本已代替ELILO，大多數Linux發行版已使用GRUB作為UEFI下的啟動程式。從Linux版本3.15起，來自英代爾的工程師Matt Fleming將64位元核心提供了支援32位元UEFI韌體的可能，前提只需要UEFI作業系統啟動程式支援EFI handover協定[5] ，譬如流行的GRUB2。同樣流行的32位元版Linux，譬如Ubuntu 16.04.3 LTS，也可以使用這類啟動程式在64位元版UEFI韌體的機器上使用。
安騰版本的Windows 2000已於2002年加入對EFI 1.10的支援。安騰版本的Windows Server 2003和Windows XP 64-Bit Edition（以IA-64架構作為執行平台）已支援EFI。
從Windows Vista SP1開始，x86-64架構的Windows作業系統已支援UEFI。但是，若在UEFI模式下安裝和啟動Windows Vista SP1或Windows 7，需要在UEFI韌體設置中開啟CSM[6]，因為在Windows 8之前的版本中，均不支援UEFI標準的「圖形輸出協定」（GOP），只支援用於傳統BIOS的VESA BIOS Extension。32位元的Windows Vista和Windows 7不支援UEFI啟動。從Windows 8開始，支援Secure Boot，UEFI模式下的啟動亦無須CSM。
現在，x86-64架構的FreeBSD、OpenBSD和NetBSD已支援UEFI。
虛擬機器對UEFI的模擬
編輯VMware Workstation支援對UEFI的模擬，但是在VMware Workstation 11以前，VMware Workstation並未正式支援UEFI，需要手動編輯虛擬機的.vmx檔案以開啟虛擬機器的UEFI。VMware Workstation 11及以後的版本正式支援對UEFI的模擬。從VMware Workstation 14開始支援Secure Boot。
VirtualBox支援對UEFI的模擬，但是VirtualBox的UEFI並不支援Windows Vista和Windows 7。
微軟Hyper-V的第二代虛擬機器支援對UEFI的模擬，以及Secure Boot。
Parallels Desktop不僅提供全規格的UEFI支援，並支援在作業系統不支援「圖形輸出協定」（GOP）的情況下回退至傳統BIOS
採用UEFI韌體的x86/x64系統類別
編輯類別0，這類系統使用x86 BIOS韌體，只支援傳統作業系統。
類別1，這類系統採用支援UEFI和Pi規範的韌體，啟用CSM層功能，只支援傳統作業系統。
類別2，這類系統採用支援UEFI和Pi規範的韌體，啟用CSM層功能，同時支援傳統和UEFI啟動的作業系統。
類別3，這類系統採用支援UEFI和Pi規範的韌體，不再提供或完全關閉CSM層功能，只支援由UEFI啟動的作業系統。
類別3+，在類別3的系統基礎上提供並啟用Secure Boot功能。
微軟公司的Windows 11僅可用於類別3+型電腦[7]，Windows 8及Windows 10適用於上述所有類別的電腦，x64型版的Windows Vista SP1和Windows 7，以及不支援UEFI韌體的作業系統僅可用於類別0至類別2型電腦。所有支援UEFI啟動的Linux作業系統適用於類別0至類別3型電腦，多數現行分發版也支援類別3+中的Secure Boot功能，譬如Ubuntu等。 Intel計劃將於2020年推出的UEFI Class 3規範中，將CSM層功能捨棄，不再支援由當年IBM公司制定的BIOS平台，Intel旗下的所有產品將遵循UEFI類別3（有一部分產品可能是3+）型規範[8]。
批評
編輯Ronald G. Minnich（coreboot的共同作者）和 Cory Doctorow（科幻小說家）和數碼權利運動者批評EFI是企圖藉由禁止用戶完整控制他們的電腦，來保護知識產權。 [9][10]它並沒有解決BIOS長期以來對多數硬件需要兩種不同驅動程式的問題－－一個給韌體，一個給作業系統。[11]
TianoCore（一個提供製作基於UEFI自由韌體工具的開放原始碼專案）[12]缺乏用來啟動晶片組的專門的驅動程式，因此需要晶片組廠商提供額外的功能。TianoCore是coreboot的一個附加選項，它包含了啟動晶片組的程式碼。
由於UEFI比起原先的BIOS技術可以對遠端網絡開機提供更高的彈性，因此在標準的安全規定有一些疑慮。[13]
Secure Boot
編輯中文名又譯作「安全啟動」，該協定定義在UEFI 2.3.1 Errata C規範中。Secure Boot只允許載入有適當數碼簽章的EFI驅動程式和EFI啟動程式，因此Secure Boot可讓開機過程更安全。
但是Red Hat開發者Matthew Garrett在他的文章"UEFI secure booting"中憂慮UEFI的Secure Boot功能可能會影響Linux（貼有Windows 8認證貼紙的機器，預設Secure Boot啟動，只預載了OEM和微軟金鑰，可能無法以Linux開機）。[14][15]微軟回應稱顧客可以停用UEFI韌體中的secure boot。[16][17]然而，某些OEM廠商仍然可能在其產品中省略這項功能。不久，報告指出微軟顯然禁止在ARM系統上實作停用Secure Boot的功能。[18][19]
自由軟件基金會（FSF）的Josh Gay對UEFI的"Secure Boot"實作提出憂慮，並發表公開聲明及連署說：
我們—連署者—敦促所有實作了UEFI中稱為"Secure Boot"的電腦製造商立即允許自由的作業系統可以被安裝。基於尊重用戶的自由權以及確切保護用戶安全，製造商必須允許電腦擁有者停用開機限制，或是提供一個確切可能的方法讓他們安裝並執行自由的作業系統。我們承諾我們將不會購買、也不會推薦剝奪用戶重要自由的電腦，並且，我們將積極地敦促社會大眾避免如此禁錮用戶的系統。[20][21]
2012年1月，微軟釋出一份關於OEM硬件認證的檔案，指出所有的x86和x86-64裝置應該將UEFI Secure Boot啟動，不過可以改用一個可讓用戶增加數碼簽章的自訂Secure Boot模式。然而，無法在執行Windows的ARM裝置上修改或禁用Secure Boot。[18]。這份稱為Windows硬件認證需求（英語：Windows Hardware Certification Requirements）[22]證實了執行Windows 8、基於ARM的裝置被禁止了任何安裝其他作業系統的可能性。現在，Ubuntu、Fedora、openSUSE、RHEL（從RHEL 7開始）、CentOS（從CentOS 7開始）、Debian（從Debian 10開始）等Linux發行版已經支援Secure Boot。Windows 8、Windows 8.1、Windows 10支援Secure Boot。
註釋
編輯- ^ Kinney, Michael. Solving BIOS Boot Issues with EFI (PDF). Intel DeveloperUPDATEMagazine: 1. [2008-02-18]. （原始內容存檔 (PDF)於2007-11-28）.
- ^ 存档副本. [2020-09-12]. （原始內容存檔於2021-04-17）.
- ^ 存档副本. [2020-09-12]. （原始內容存檔於2021-04-17）.
- ^ 存档副本. [2020-09-12]. （原始內容存檔於2017-05-26）.
- ^ Linux kernel 3.15, Section 1.3. EFI 64-bit kernels can be booted from 32-bit firmware. kernelnewbies.org. 2014-06-08 [2014-06-15]. （原始內容存檔於2018-06-11）.
- ^ UEFI 的 Windows 支援, Microsoft, [2017-11-25], （原始內容存檔於2017-12-01）
- ^ Windows 11 規格 - Microsoft. Windows. [2021-07-08]. （原始內容存檔於2021-11-18） （中文（臺灣））.
- ^ Richardson, Brian. "Last Mile" Barriers to Removing Legacy BIOS (PDF). 30 October 2017 [22 November 2017]. （原始內容存檔 (PDF)於2019-02-01）.
- ^ Interview: Ronald G Minnich. Fosdem. 2007-02-06 [2010-09-14]. （原始內容存檔於2011-01-29）.
- ^ Cory Doctorow, The Coming War on General Purpose Computation, 2011-12-27 [2013-07-11], （原始內容存檔於2013-02-10）
- ^ coreboot (aka LinuxBIOS): The Free/Open-Source x86 Firmware. YouTube. 2008-10-31 [2010-09-14]. （原始內容存檔於2020-11-21）.
- ^ Welcome, TianoCore, SourceForge, （原始內容存檔於2012-04-23）.
- ^ Risks, UK: NCL, [2012-01-19], （原始內容存檔於2021-03-14）.
- ^ Garrett, Matthew. UEFI secure booting. [2011-09-20]. （原始內容存檔於2021-04-27）.
- ^ Garrett, Matthew. UEFI secure booting. [2011-09-23]. （原始內容存檔於2021-04-27）.
- ^ MS denies secure boot will exclude Linux. The Register. 2011-09-23 [2011-09-24]. （原始內容存檔於2020-04-22）.
- ^ Protecting the pre-OS Environment with UEFI. Microsoft. 2011-09-22 [2011-09-24]. （原始內容存檔於2012-08-10）.
- ^ 18.0 18.1 存档副本. [2012-01-19]. （原始內容存檔於2021-04-19）.
- ^ 存档副本. [2017-03-07]. （原始內容存檔於2012-03-09）.
- ^ Gay, Josh. Will your computer's "Secure Boot" turn out to be "Restricted Boot"?. www.fsf.org. Free Software Foundation. [2011-10-25]. （原始內容存檔於2021-04-27）.
- ^ Stand up for your freedom to install free software. www.fsf.org. Free Software Foundation. [2011-10-25]. （原始內容存檔於2021-04-19）.
- ^ 存档副本 (PDF). [2014-04-24]. （原始內容 (PDF)存檔於2014-06-11）.