UEFI
統一可擴展固件介面
統一可擴展固件介面(英語:Unified Extensible Firmware Interface,縮寫UEFI)是一種個人電腦系統規格,用來定義操作系統與系統固件之間的軟體界面,作為BIOS的替代方案。可擴展固件介面負責加電自檢(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廠商AMI、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版本。
眾所周知,英特爾在近二十年來引領以x86系列處理器為基礎的PC技術潮流,其產品如CPU,晶元組等在PC生產線中佔據絕對領導的位置。因此,不少人認為此舉顯示英特爾公司欲染指固件產品市場的野心。事實上,EFI技術源於英特爾安騰處理器(Itanium)平台的推出。安騰處理器是英特爾瞄準伺服器高端市場投入近十年研發力量設計產生的與x86系列完全不同的64位新架構。在x86系列處理器進入32位的時代,由於兼容性的原因,新的處理器(80386)保留16位的運行方式(實模式),此後多次處理器的升級換代都保留這種運行方式。甚至在包含EM64T技術的至強系列處理器中,處理器加電啟動時仍然會切換到16位的實模式下運行(BIOS)。英特爾將這種情況歸咎於BIOS技術的發展緩慢。自從IBM PC兼容機廠商通過凈室的方式複製出第一套BIOS源程序,BIOS就以16位彙編代碼,寄存器參數調用方式,靜態鏈接,以及1MB以下內存固定編址的形式存在十幾年。雖然由於各大BIOS廠商近年來的努力,有許多新元素添加到產品中,如PnPBIOS、ACPI、傳統USB設備支持等等,但BIOS的根本性質沒有得到任何改變。這迫使英特爾在開發新的處理器時,都必須考慮加進使性能大大降低的兼容模式。用一個比喻來講:這就像保時捷新一代的全自排跑車,被人套上去一個蹩腳打檔器。
然而,安騰處理器並沒有這樣的顧慮,它是一個新生的處理器架構,系統固件和操作系統之間的介面都可以完全重新定義。並且這一次,英特爾將其定義為一個可擴展的,標準化的固件介面規範,不同於傳統BIOS的固定的,缺乏文檔的,完全基於經驗和晦澀約定的一個事實標準。基於EFI的第一套系統產品的出現至今已經有五年的時間,如今,英特爾試圖將成功運用在高端伺服器上的技術推廣到市場佔有率更有優勢的PC產品線中,並承諾在2006年間會投入全力的技術支持。
二者顯著的區別就是UEFI是用模塊化,C語言風格的參數堆棧傳遞方式,動態鏈接的形式構建的系統,較BIOS而言更易於實現,容錯和糾錯特性更強,縮短了系統研發的時間。它可以運行於x86-64、IA32、IA64等架構上(在個人電腦上通常是x86-64平台),突破傳統16位代碼的定址能力,達到處理器的最大定址。它利用載入EFI驅動程序的形式,識別及操作硬體,不同於BIOS利用掛載真實模式中斷的方式增加硬體功能。後者必須將一段類似於驅動程序的16位代碼(如RAID卡的Option ROM)放置在固定的0x000C0000至0x000DFFFF之間存儲區中,運行這段代碼的初始化部分,它將掛載實模式下約定的中斷向量向其他程序提供服務。例如,VGA圖形及文本輸出中斷(INT 10h),磁碟訪問中斷服務(INT 13h)等等。由於這段存儲空間有限(128KB),BIOS對於所需放置的驅動程序代碼大小超過空間大小的情況無能為力。另外,BIOS的硬體服務程序都以16位代碼的形式存在,這就給運行於增強模式的操作系統訪問其服務造成了困難。因此BIOS提供的服務在現實中只能提供給操作系統引導程序或MS-DOS類操作系統使用。而UEFI系統下的驅動程序可以由EFI Byte Code(EBC)編寫而成,EFI Byte Code是一組專用於EFI驅動程序的虛擬機器語言,必須在EFI驅動程序運行環境(Driver Execution Environment,或DXE)下被解釋運行。採用EBC編寫的EFI驅動程序擁有向下兼容性,打個比方說,一個帶有EFI驅動程序的擴展設備,既可以將其安裝在安騰處理器的系統中,也可以安裝於支持UEFI的64位/32位PC系統中,而它的EFI驅動不需要重新編寫。這樣就無需對系統升級帶來的兼容性因素作考慮。另外,由於EFI驅動程序開發簡單,所有的PC部件提供商都可以參與,情形非常類似於現代操作系統的開發模式,這個開發模式曾使Windows在短短的兩三年時間內成為功能強大,性能優越的操作系統。基於EFI的驅動模型可以使UEFI系統接觸到所有的硬體功能,在操作系統運行以前瀏覽萬維網站,實現圖形化、多語言的BIOS設置界面,或者無需運行操作系統即可線上更新BIOS等等不再是天方夜譚,甚至實現起來也非常簡單。這對基於傳統BIOS的系統來說是件難以實現的任務,在BIOS中添加幾個簡單的USB設備支持都曾使很多BIOS設計師痛苦萬分,更何況除了添加對無數網路硬體的支持外,還得憑空構建一個16位模式下的TCP/IP協議棧。
一些人認為BIOS只不過是由於兼容性問題遺留下來的無足輕重的部分,不值得為它花費太大的升級努力。而反對者認為,當BIOS的出現約制了PC技術的發展時,必須有人對它作必要的改變。
一般認為,UEFI由以下幾個部分組成:
● ● Pre-EFI初始化模塊
● ● EFI驅動程序執行環境
● ● EFI驅動程序
● ● 兼容性支持模塊(CSM)
● ● EFI高層應用
● ● GUID磁碟分區表
在實現中,統一可擴展固件介面(UEFI)初始化模塊和驅動執行環境通常被集成在一個只讀存儲器中。Pre-EFI初始化程序在系統開機的時候最先得到執行,它負責最初的CPU,晶元組及存儲器的初始化工作,緊接著載入EFI的驅動程序執行環境(DXE)。當DXE被載入運行時,系統便具有了枚舉並載入其他EFI驅動程序的能力。在基於PCI架構的系統中,各PCI橋及PCI適配器的EFI驅動程序會被相繼載入及初始化;這時,系統進而枚舉並載入各橋接器及適配器後面的各種匯流排及設備的EFI驅動程序,周而復始,直到最後一個設備的EFI驅動程序被成功載入。正因如此,EFI驅動程序可以放置於系統的任何位置,只要能保證它可以按順序被正確枚舉。例如一個具PCI-E匯流排介面的RAID存儲適配器,其EFI驅動程序一般會放置在這個設備的匹配PCI規範的擴展只讀存儲器(PCI Expansion ROM)中,當PCI匯流排驅動程序被載入完畢,並開始枚舉其子設備時,這個存儲適配器旋即被正確識別並載入它的EFI驅動程序。部分EFI驅動程序還可以放置在某個磁碟的EFI系統分區(ESP)中,只要這些驅動程序不是用於載入這個磁碟的驅動的必要部件。在EFI規範中,一種突破傳統MBR磁碟分區結構限制的GUID磁碟分區系統(GPT)被引入,新結構中,磁碟的主分區數不再受限制(在MBR結構下,只能存在4個主分區),另外EFI/UEFI+GUID結合還可以支持2.1 TB以上硬碟(有測試顯示,3TB硬碟使用MBR,並且安裝Windows 6.x 64位系統,只能識別到2.1TB),並且分區類型將由GUID來表示。在眾多的分區類型中,EFI系統分區可以被UEFI固件訪問,可用於存放操作系統的引導程序、EFI應用程序和EFI驅動程序。EFI系統分區採用FAT文件系統,容量較小,在Windows操作系統下,默認是隱藏的。UEFI固件通過運行EFI系統分區中的啟動程序啟動操作系統。CSM是在x86平台UEFI系統中的一個特殊的模塊,它將為不具備UEFI引導能力的操作系統(如Windows XP)以及16位的傳統Option ROM(即非EFI的Option ROM)提供類似於傳統BIOS的系統服務。Secure Boot和CSM不兼容,因此在UEFI固件設置中打開CSM前,需要在UEFI固件設置中關閉Secure Boot。
UEFI在概念上非常類似於一個低階的操作系統,並且具有操控所有硬體資源的能力。不少人感覺它的不斷發展將有可能代替現代的操作系統。事實上,EFI的締造者們在第一版規範出台時就將EFI的能力限制於不足以威脅操作系統的統治地位。首先,它只是硬體和預啟動軟體間的介面規範;其次,UEFI環境下不提供中斷的機制,也就是說每個EFI驅動程序必須用輪詢(polling)的方式來檢查硬體狀態,並且需要以解釋的方式運行,較操作系統下的機械碼驅動效率更低;再則,UEFI系統不提供複雜的緩存器保護功能,它只具備簡單的緩存器管理機制,具體來說就是指運行在x64或x86處理器的64位模式或保護模式下,以最大定址能力為限把緩存器分為一個平坦的段(Segment),所有的程序都有許可權訪問任何一段位置,並不提供真實的保護服務。當UEFI所有組件載入完畢時,便會啟動操作系統的啟動程序,如果UEFI固件內置EFI Shell,也可以啟動EFI Shell命令提示(部分UEFI固件內置EFI Shell),在這裡,用戶可以調入執行EFI應用程序,這些EFI程序可以是OEM提供的硬體檢測軟體,OEM提供的備份軟體,引導管理軟體,操作系統的啟動程序等等,也可以載入EFI分區(ESP)中的EFI驅動程序(如文件系統驅動程序)。EFI應用程序和EFI驅動程序可以是PE格式的.efi文件,可用C語言編寫。在UEFI引導模式下,操作系統的啟動程序也是EFI應用程序,啟動程序的EFI文件存儲在EFI系統分區(ESP)上。理論上來說,對於EFI應用程序的功能並沒有任何限制,任何人都可以編寫這類軟體,並且效果較以前MS-DOS下的軟體更華麗,功能更強大。一旦引導軟體將控制權交給操作系統,所有用於引導的服務代碼將全部停止工作,部分運行時,代服務程序還可以繼續工作,以便於操作系統一時無法找到特定設備的驅動程序時,該設備還可以繼續被使用。
UEFI固件區分架構,在UEFI引導模式下,通常只能運行特定架構的UEFI操作系統和特定架構的EFI應用程序(EBC程序除外)。比如,採用64位UEFI固件的PC,在UEFI引導模式下只能運行64位操作系統啟動程序;而在Legacy引導模式(即BIOS兼容引導模式)下,通常不區分操作系統的比特數,既可以運行16位的操作系統(如DOS),也可以運行32位或64位的操作系統,和BIOS一樣。
英特爾無疑是推廣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引導。
類別0,這類系統使用x86 BIOS固件,只支持傳統操作系統。
類別1,這類系統採用支持UEFI和Pi規範的固件,激活CSM層功能,只支持傳統操作系統。
類別2,這類系統採用支持UEFI和Pi規範的固件,激活CSM層功能,同時支持傳統和UEFI啟動的操作系統。
類別3,這類系統採用支持UEFI和Pi規範的固件,不再提供或完全關閉CSM層功能,只支持由UEFI啟動的操作系統。
類別3+,在類別3的系統基礎上提供並激活Secure Boot功能。
微軟公司的Windows 8及之後的操作系統適用於上述所有類別的電腦,之前支持UEFI固件的操作系統適用於類別0至類別2型電腦,不支持UEFI固件的操作系統僅可用於類別0和類別1的電腦。所有支持UEFI啟動的Linux操作系統適用於類別0至類別3型電腦,多數現行分發版也支持類別3+中的Secure Boot功能,譬如Ubuntu等。 Intel計劃將於2020年推出的UEFI Class 3規範中,將Legacy BIOS界面完全捨棄,Intel旗下的所有產品將使用UEFI Class 3(有一部分產品可能是3+)。至2018年,部分x86架構設備已經徹底捨棄CSM,或者,在Legacy引導模式下,功能很有限。
BIOS即Basic Input/Output System,翻成中文是“基本輸入/輸出系統”,是一種所謂的“固件”,負責在開機時做硬體啟動和檢測等工作,並且擔任操作系統控制硬體時的中介角色。
因為硬體發展迅速,傳統式(Legacy)BIOS 成為進步的包袱,現在已發展出最新的UEFI(Unified Extensible Firmware Interface)可擴展固件介面,相比傳統 BIOS 的來說,未來將是一個“沒有特定 BIOS”的電腦時代。
與legacy BIOS 相比,UEFI最大的幾個區別在於:
1. 編碼99%都是由C語言完成;
2. 一改之前的中斷、硬體埠操作的方法,而採用了Driver/protocol的新方式;
3. 將不支持X86實模式,而直接採用Flat mode(也就是不能用DOS了,現在有些 EFI 或 UEFI 能用是因為做了兼容,但實際上這部分不屬於UEFI的定義了);
4. 輸出也不再是單純的二進位code,改為Removable Binary Drivers;
5. OS啟動不再是調用Int19,而是直接利用protocol/device Path;
6. 對於第三方的開發,前者基本上做不到,除非參與BIOS的設計,但是還要受到ROM的大小限制,而後者就便利多了。
7.彌補BIOS對新硬體的支持不足的問題。
UEFI使用模塊化設計,它在邏輯上可分為硬體控制和OS軟體管理兩部分:操作系統—可擴展固件介面—固件—硬體。
根據UEFI概念圖的結構,可把uEFI概念劃為兩部分:uEFI的實體(uEFI Image)跟平台初始化框架。
UEFI的實體-UEFI Image
(圖中藍框圍起部分)
根據UEFI規範定義,UEFI Image包含三種:uEFI Applications, OS Loaders and UEFI Drivers。
UEFI Applications是硬體初始化完,操作系統啟動之前的核心應用,比如:啟動管理、BIOS設置、uEFI Shell、診斷程式、調度和供應程式、調試應用...等等
OS Loaders是特殊的uEFI Application,主要功能是啟動操作系統並退出和關閉UEFI應用。
UEFI Drivers是提供設備間介面協議,每個設備獨立運行提供設備版本號和相應的參數以及設備間關聯,不再需要基於操作系統的支持。
平台初始化框架
UEFI框架主要包含兩部分,一是PEI(EFI預初始化),另一部分是驅動執行環境 (DXE)。
PEI主要是用來檢測啟動模式、載入主存儲器初始化模塊、檢測和載入驅動執行環境核心。
DXE是設備初始化的主要環節,它提供了設備驅動和協議介面環境界面。
與BIOS顯著不同的是,UEFI是用模塊化、C語言風格的參數堆棧傳遞方式、動態鏈接的形式構建系統,它比BIOS更易於實現,容錯和糾錯特性也更強,從而縮短了系統研發的時間。更加重要的是,它運行於32位或64位模式,突破了傳統16位代碼的定址能力,達到處理器的最大定址,此舉克服了BIOS代碼運行緩慢的弊端。
與BIOS不同的是,UEFI體系的驅動並不是由直接運行在CPU上的代碼組成的,而是用EFI Byte Code(EFI位元組代碼)編寫而成的。Java是以“Byte Code”形式存在的,正是這種沒有一步到位的中間性機制,使Java可以在多種平台上運行。UEFI也借鑒了類似的做法。EFI Byte Code是一組用於UEFI驅動的虛擬機器指令,必須在UEFI驅動運行環境下被解釋運行,由此保證了充分的向下兼容性。
一個帶有UEFI驅動的擴展設備既可以安裝在使用安卓的系統中,也可以安裝在支持UEFI的新PC系統中,它的UEFI驅動不必重新編寫,這樣就無須考慮系統升級后的兼容性問題。基於解釋引擎的執行機制,還大大降低了UEFI驅動編寫的複雜門檻,所有的PC部件提供商都可以參與。
UEFI內置圖形驅動功能,可以提供一個高解析度的彩色圖形環境,用戶進入后能用滑鼠點擊調整配置,一切就像操作Windows系統下的應用軟體一樣簡單。
UEFI將使用模塊化設計,它在邏輯上分為硬體控制與OS(操作系統)軟體管理兩部分,硬體控制為所有UEFI版本所共有,而OS軟體管理其實是一個可編程的開放介面。藉助這個介面,主板廠商可以實現各種豐富的功能。比如我們熟悉的各種備份及診斷功能可通過UEFI加以實現,主板或固件廠商可以將它們作為自身產品的一大賣點。UEFI也提供了強大的聯網功能,其他用戶可以對你的主機進行可靠的遠程故障診斷,而這一切並不需要進入操作系統。
目前UEFI主要由這幾部分構成:UEFI初始化模塊、UEFI驅動執行環境、UEFI驅動程序、兼容性支持模塊、UEFI高層應用和GUID磁碟分區組成。
UEFI初始化模塊和驅動執行環境通常被集成在一個只讀存儲器中,就好比如今的BIOS固化程序一樣。UEFI初始化程序在系統開機的時候最先得到執行,它負責最初的CPU、北橋、南橋及存儲器的初始化工作,當這部分設備就緒后,緊接著它就載入UEFI驅動執行環境(Driver Execution Environment,簡稱DXE)。當DXE被載入時,系統就可以載入硬體設備的UEFI驅動程序了。DXE使用了枚舉的方式載入各種匯流排及設備驅動,UEFI驅動程序可以放置於系統的任何位置,只要保證它可以按順序被正確枚舉。藉助這一點,我們可以把眾多設備的驅動放置在磁碟的UEFI專用分區中,當系統正確載入這個磁碟后,這些驅動就可以被讀取並應用了。在這個特性的作用下,即使新設備再多,UEFI也可以輕鬆地一一支持,由此克服了傳統BIOS捉襟見肘的情形。UEFI能支持網路設備並輕鬆聯網,原因就在於此。
值得注意的是,一種突破傳統MBR(主引導記錄)磁碟分區結構限制的GUID(全局唯一標誌符)磁碟分區系統將在UEFI規範中被引入。MBR結構磁碟只允許存在4個主分區,而這種新結構卻不受限制,分區類型也改由GUID來表示。在眾多的分區類型中,UEFI系統分區用來存放驅動和應用程序。很多朋友或許對這一點感到擔心:當UEFI系統分區遭到破壞時怎麼辦?而容易受病毒侵擾更是UEFI被人詬病的一大致命缺陷。事實上,系統引導所依賴的UEFI驅動通常不會存放在UEFI系統分區中,當該分區的驅動程序遭到破壞,我們可以使用簡單方法加以恢復,根本不用擔心。
X86處理器能夠取得成功,與它良好的兼容性是分不開的。為了讓不具備UEFI引導功能的操作系統提供類似於傳統BIOS的系統服務,UEFI還特意提供了一個兼容性支持模塊,這就保證了UEFI在技術上的良好過渡。
uEFI啟動項
啟動項2