本页使用了标题或全文手工转换

统一可延伸韧体介面

维基百科,自由的百科全书
跳转至: 导航搜索
可扩展固件接口在软件层次中的位置

统一可延伸韧体介面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厂商AMIInsydePhoenix

规格[编辑]

可延伸韧体介面(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.6(Errata A)版是最新的公开的版本。

统一可延伸韧体介面(UEFI)的产生[编辑]

EFI开机管理员与 EFI drivers的沟通方式

众所周知,英特尔在近二十年来引领以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年间会投入全力的技术支持。

比较统一可延伸韧体介面(UEFI)和BIOS[编辑]

二者显著的区别就是UEFI是用模块化,C语言风格的参数堆栈传递方式,动态链接的形式构建的系统,较BIOS而言更易于实现,容错和纠错特性更强,缩短了系统研发的时间。它可以执行于x86-64、IA32、IA64等架构上(在个人电脑上通常是x86-64平台),突破传统16位代码的寻址能力,达到处理器的最大寻址。它利用加载EFI驱动程序的形式,识别及操作硬件,不同于BIOS利用挂载真实模式中断的方式增加硬件功能。后者必须将一段类似于驱动程序的16位代码(如RAID卡的Option ROM)放置在固定的0x000C00000x000DFFFF之间存储区中,运行这段代码的初始化部分,它将挂载实模式下约定的中断向量向其他程序提供服务。例如,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)和操作系统[编辑]

UEFI在概念上非常类似于一个低阶的操作系统,并且具有操控所有硬件资源的能力。不少人感觉它的不断发展将有可能代替现代的操作系统。事实上,EFI的缔造者们在第一版规范出台时就将EFI的能力限制于不足以威胁操作系统的统治地位。首先,它只是硬件和预启动软件间的接口规范;其次,UEFI环境下不提供中断的机制,也就是说每个EFI驱动程序必须用轮询(polling)的方式来检查硬件状态,并且需要以解释的方式运行,较操作系统下的机械码驱动效率更低;再则,UEFI系统不提供复杂的缓存器保护功能,它只具备简单的缓存器管理机制,具体来说就是指运行在x64x86处理器的64位元模式或保护模式下,以最大寻址能力为限把缓存器分为一个平坦的段(Segment),所有的程序都有权限存取任何一段位置,并不提供真实的保护服务。当UEFI所有组件加载完毕时,便会启动作业系统启动程式,也可以启动一个类似于操作系统Shell的命令解释环境(即EFI Shell,部分UEFI固件内置EFI Shell),在这里,用户可以调入执行任何EFI应用程序,这些程序可以是硬件检测及除错软件,开机管理软体,设置软件,作业系统的启动程式等等,也可以载入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一样。

统一可延伸韧体介面(UEFI)的组成[编辑]

一般认为,UEFI由以下几个部分组成:

  1. Pre-EFI初始化模块
  2. EFI驱动程序执行环境
  3. EFI驱动程序
  4. 兼容性支持模块(CSM)
  5. EFI高层应用
  6. 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档案系统(UEFI不支援exFAT),容量小,在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的积极因素,近年来由于业界对其认识的不断深入,更多的厂商正投入这方面的研究。包括英特尔,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下的启动程式。

安腾版本的Windows 2000已于2002年加入对EFI 1.10的支持。安腾版本的Windows Server 2003Windows XP 64-Bit Edition(以IA-64架构作为执行平台)已支援EFI。

Windows Vista SP1开始,x86-64架构的Windows作业系统已支援UEFI。但是,若在UEFI模式下安装和启动Windows Vista SP1或Windows 7,需要在UEFI韧体设定中开启CSM。32位元的Windows Vista和Windows 7不支援UEFI启动。从Windows 8开始,支援SecureBoot,UEFI模式下的启动亦无须CSM,32位元版本的Windows 8亦支援32位元的UEFI(不支援64位元的UEFI)。

现在,x86-64架构的FreeBSDOpenBSDNetBSD已支援UEFI。

虚拟机器对UEFI的模拟[编辑]

VMware Workstation支援对UEFI的模拟,但是在VMware Workstation 11以前,VMware Workstation并未正式支援UEFI,需要手动编辑虚拟机的.vmx档案以开启虚拟机器的UEFI。VMware Workstation 11及以后的版本正式支援对UEFI的模拟。

VirtualBox支援对UEFI的模拟,但是VirtualBox的UEFI并不支援Windows Vista和Windows 7。

QEMU/KVM可通过OVMF支援对UEFI的模拟。

微软Hyper-V英语Hyper-V的第二代虚拟机器支援对UEFI的模拟,以及Secure Boot。

批评[编辑]

Ronald G. Minnich(coreboot的共同作者)和 Cory Doctorow(科幻小说家)和数位权利运动者批评EFI是企图借由禁止使用者完整控制他们的电脑,来保护智慧财产权[2][3]它并没有解决BIOS长期以来对多数硬体需要两种不同驱动程式的问题--一个给韧体,一个给作业系统[4]

TianoCore(一个提供制作基于UEFI自由韧体工具的开放原始码专案)[5]缺乏用来启动晶片组的专门的驱动程式,因此需要晶片组厂商提供额外的功能。TianoCore是coreboot的一个附加选项,它包含了启动晶片组的程式码。

由于UEFI比起原先的BIOS技术可以对远端网路开机提供更高的弹性,因此在标准的安全规定有一些疑虑。[6]

Secure Boot[编辑]

在UEFI 2.3.1 Errata C规范中定义了一项名为“Secure Boot”的协定,Secure Boot只允许载入有适当数位签章的EFI驱动程式和EFI启动程式,因此Secure Boot可让开机过程更安全。但是Red Hat开发者Matthew Garrett在他的文章"UEFI secure booting"中忧虑UEFI的Secure Boot功能可能会影响Linux(贴有Windows 8认证贴纸的机器,预设Secure Boot启动,只预载了OEM微软金钥,可能无法以Linux开机)。[7][8]微软回应称顾客可以停用UEFI韧体中的secure boot。[9][10]然而,某些OEM厂商仍然可能在其产品中省略这项功能。稍晚,报告指出微软显然禁止在ARM系统上实作停用Secure Boot的功能。[11][12]

自由软体基金会(FSF)的Josh Gay对UEFI的"Secure Boot"实作提出忧虑,并发表公开声明及连署说:

我们—连署者—敦促所有实作了UEFI中称为"Secure Boot"的电脑制造商立即允许自由的作业系统可以被安装。基于尊重使用者的自由权以及确切保护使用者安全,制造商必须允许电脑拥有者停用开机限制,或是提供一个确切可能的方法让他们安装并执行自由的作业系统。我们承诺我们将不会购买、也不会推荐剥夺使用者重要自由的电脑,并且,我们将积极地敦促社会大众避免如此禁锢使用者的系统。[13][14]

2012年1月,微软释出一份关于OEM硬体认证的文件,指出所有的x86x86-64装置应该将UEFI Secure Boot启动,不过可以改用一个可让使用者增加数位签章的自订secure boot模式。然而,在执行Windows的ARM装置上使用自订secure boot模式或停用都是不可能的[15]。这份称为Windows硬体认证需求(英语:Windows Hardware Certification Requirements[16]证实了执行Windows 8、基于ARM的装置被禁止了任何安装其他作业系统的可能性。现在,UbuntuFedoraopenSUSERHEL(从RHEL 7开始)、CentOS(从CentOS 7开始)等Linux发行版已经支援SecureBoot。Windows 7并不支援Secure Boot。

注释[编辑]

  1. ^ Kinney, Michael. Solving BIOS Boot Issues with EFI (PDF). Intel DeveloperUPDATEMagazine: 1. 
  2. ^ Interview: Ronald G Minnich. Fosdem. 2007-02-06 [2010-09-14]. 
  3. ^ Cory Doctorow, The Coming War on General Purpose Computation, 2011-12-27 [2013-07-11] 
  4. ^ coreboot (aka LinuxBIOS): The Free/Open-Source x86 Firmware. YouTube. 2008-10-31 [2010-09-14]. 
  5. ^ Welcome, TianoCore, SourceForge .
  6. ^ Risks, UK: NCL .
  7. ^ Garrett, Matthew. UEFI secure booting. [2011-09-20]. 
  8. ^ Garrett, Matthew. UEFI secure booting. [2011-09-23]. 
  9. ^ MS denies secure boot will exclude Linux. The Register. 2011-09-23 [2011-09-24]. 
  10. ^ Protecting the pre-OS Environment with UEFI. Microsoft. 2011-09-22 [2011-09-24]. 
  11. ^ http://www.softwarefreedom.org/blog/2012/jan/12/microsoft-confirms-UEFI-fears-locks-down-ARM/
  12. ^ 存档副本. [2017-03-07].  已忽略文本“2012-03-09” (帮助)
  13. ^ Gay, Josh. Will your computer's "Secure Boot" turn out to be "Restricted Boot"?. www.fsf.org. Free Software Foundation. [2011-10-25]. 
  14. ^ Stand up for your freedom to install free software. www.fsf.org. Free Software Foundation. [2011-10-25]. 
  15. ^ http://www.softwarefreedom.org/blog/2012/jan/12/microsoft-confirms-UEFI-fears-locks-down-ARM/
  16. ^ 存档副本 (PDF). [2014-04-24].  已忽略文本“2014-06-11” (帮助)

参看[编辑]

外部链接[编辑]