让“BIOS”自由飞翔——UEFI技术解析
技术空间
最近，硬盘行业传出一则好消息，希捷宣布将在今年底发布3TB容量的硬盘。不过，要使用这种超大容量的硬盘，计算机就必须要抛弃传统的BIOS，采用UEFI界面。也许有人会奇怪，UEFI是何方神圣？如果形象一点来形容，使用UEFI的计算机可以让任何一个电脑用户像使用智能手机一样，不但可以增添各种功能，同时还能即时操作！怎么样，听到这里的时候心动了？那么不妨跟着我们进入今天所要讨论的话题——UEFI技术。
不堪重负的BIOS
提到BIOS，相信很多人都知道这个玩意，但如果要普通用户真正熟悉了解它，却要花精力认真学习！BIOS是Basic Input/Output System的缩写，早在1981年IBM推出的首款个人电脑以及1984年推出的IBM AT电脑中就带有这样的设计。它为计算机提供最低级的、最直接的硬件控制，计算机的原始操作都是依照固化在BIOS里的内容来完成的。准确地说，BIOS是硬件与软件程序之间的一个“转换器”或者说是接口(虽然它本身也只是一个程序)，负责解决硬件的即时需求，并按软件对硬件的操作要求具体执行。计算机用户在使用计算机的过程中，都会接触到BIOS，它在计算机系统中起着非常重要的作用。尽管BIOS为PC的发展做出了重要的贡献，也在进行不断地改进，但仍存在许多天生的架构限制。
采取汇编语言进行编写就是BIOS的一大缺陷。作为由低级汇编语言写成的软件，BIOS以16位汇编代码的形式存在了很长一段时间，即使CPU经过了几番革新，但是加电启动的16位模式却仍然保留了下来。正是这一陈旧的运行方式，迫使Intel、AMD在开发新款CPU时，必须考虑加入导致系统性能大大降低的兼容模式，这就像保时捷新一代的全自动挡跑车被人生套上一个蹩脚的挂挡器。另一方面无论是系统开发商、硬件厂商，还是芯片厂商都对BIOS 在功能与设计方面的要求越来越高，比如系统开发商要求更容易让固件整合特色功能，达到产品差异化的市场需求；芯片厂商要求能以最快的速度将新的系统硬件选择加入BIOS 中等等……这样导致的结果就是，当芯片厂商将芯片交付系统开发商前，必须要将硬件规格或是参考固件代码交给BIOS 厂商，然后等待BIOS 厂商将达到出货品质的驱动程序加入BIOS 中。这一个冗长的沟通联系过程，对产品上市进程造成了很大的制约。
而从操作层面来说，虽然目前操作系统已将不少需要通过 BIOS 完成的硬体控制程序放在系统低层完成，但有时需要用户进入BIOS手动进行调整，这个时候字符化的BIOS设置界面却把很多人搞得一头雾水。更为夸张的是，当出现某些新硬件的时候，必须要刷新BIOS版本才支持。因此，BIOS无论在开发，还是应用方面都遇到了很大的瓶颈，业界希望发展出一个标准介面，从而更容易扩展底层功能，这时UEFI标准出现了。
三大优势吃定BIOS
UEFI 的英文全称为：Universal Extensible Firmware Interface（统一可扩展固件接口），属于一个可扩展的、标准化的统一固件接口规范。在谈UEFI之前我们有必要认识到一下它的前辈——EFI（Extensible Firmware Interface）。EFI也是 Intel 为PC 固件的体系结构、接口和服务提出的建议标准，最初目标也是取代BIOS，并早已应用到服务器领域，甚至苹果在其x86 PC机上也采用EFI。虽然EFI技术非常优秀，很多厂商也曾支持该技术，但是由于各家制作标准不统一，致使各个厂商的EFI存在兼容性问题。因此2005年，Intel将EFI规范交给了一个由微软、AMD、惠普等公司共同参与的工业联盟进行管理，并更名为UEFI(统一可扩展固件接口)，从而让UEFI能兼容更多硬件，具有更广泛的通用性。
采用C语言进行编写
与传统BIOS相比一个显著不同点是，UEFI使用全球最广泛的高级语言——C语言进行编写，摆脱了传统BIOS复杂的16位汇编语言代码编写方式，比BIOS更易于实现，容错和纠错特性也更强，从而缩短了系统研发的时间。正是基于这个重要特点，UEFI可以拥有更为先进的驱动模式，可以让PC在不进入操作系统时就能实现很多附加功能。
例如它支持通用显卡驱动，可以在硬件和高级操作系统之间为用户提供了一个支持鼠标的图形化操作界面。它可以支持TCP/IP协议，支持通用网络设备驱动，可以在不进入操作系统的情况下浏览网页。这样消费者就可以在UEFI界面中使用各种网络资源。例如一些硬件故障可以进行网络诊断与恢复，通过网络进行硬件驱动和固件的升级。UEFI如果使用闪存作为自己的存储空间，还可以执行一些常用的程序，如硬盘分区、多操作系统的引导、硬盘数据备份与恢复等。
模块化管理，更具开放性
UEFI的另一大特点就是采用模块化设计的UEFI BIOS，基本上一个UEFI被区分成硬件控制和系统软件两大模块，前者主要由Pre-UEFI初始化模块、UEFI驱动执行环境、UEFI驱动程序、兼容性支持模块、UEFI高层应用、GUID 磁盘分区等几个部分组成。
在目前的相关产品中，UEFI初始化模块和驱动执行环境通常被集成在一个只读存储器中。Pre-UEFI初始化程序在系统开机时最先执行，负责最初的CPU、主桥及存储器的初始化工作，紧接着载入UEFI驱动执行环境。当UEFI驱动执行环境被载入运行时，系统便具备了加载运行其他硬件（比如网卡）的能力。而之后的软件模块则是给厂商用C语言撰写应用功能的开放接口，厂商可以在UEFI里面通过C语言实现各种自己想要的功能。
通过这个开放接口，厂商就可以自行编写出各种功能的插件(Plug-in)，像是类似Ghost的系统备份/还原插件、类似IE的浏览器插件、类似Anti-Virus的防病毒插件等来增加自家产品的功能特色，这些都是BIOS无法实现的。由于UEFI留给厂商的发挥空间很大，所以厂商都可以在这里加入了很多自己独有的东西，不再像以往的BIOS那样抹杀个性了。
更具灵活性，兼容性更好
在UEFI论坛的成员公司的大力支持和促进下，UEFI还针对EFI中的UGA协议、SCSI传输、USB主件控制还有I/O设备方面都作出了改进，而且还添加了网络应用程序接口、X64绑定、服务绑定等新的内容。更重要的一点，由于UEFI是由UEFI论坛的所有成员公司共同商讨确定的，所以它能兼容更多的硬件，具有更广泛的通用性。
与BIOS不同的是，UEFI体系的驱动并不是由直接运行在CPU上的代码组成的，而是用EFIByteCode（EFI字节代码）编写而成的，这有点类似于Java。Java的编译代码是以“ByteCode”形式存在的，正是这种没有一步到位的中间性机制，使Java可以在多种平台上运行。UEFI也借鉴了类似的做法。EFIByteCode是一组用于UEFI驱动的虚拟机器指令，在UEFI驱动运行环境下被解释运行就可以充分的向下兼容性。同时UEFI定义的固件接口并不针对某些特定的处理器架构，与只针对Intel x86处理器架构的Bios相比具有更大的灵活性。比如一个带有UEFI驱动的扩展设备既可以安装在使用安腾的系统中，也可以安装在支持UEFI的新PC系统中， UEFI驱动不必重新编写，这样就无须考虑系统升级后的兼容性问题。这大大降低了UEFI驱动编写的复杂门槛，所有的PC部件提供商都可以参与。
UEFI前景广阔
正是因为UEFI拥有了比BIOS更高级的功能，UEFI才获得业界的广泛认定，而它的可扩展性，也为大厂提供展示个性与实力的机会。比如以 UEFI 为基础的固件可以被一些简单硬件所应用，采用此标准可以简化新硬件技术的整合，定制化也变得简单，这对于市场份额较小的系统而言很有益处。又比如不少专业领域所使用的手持电脑可能包含的功能无法在传统的OS 上使用，如果使用传统BIOS来开发类似的系统将会需要相当多的软件开发投资，但是在UEFI 系统下，研发成本就可大幅降低。以 UEFI 为基础的固件的通用性也同时给予系统开发者更多的选择自由。无论他们所选择的板卡设计为何，他们只需开发定制化的程序一次，即可将其应用于所有UEFI 固件上。
当然，UEFI架构的先进性也让很多人认为在UEFI成为电脑固件后，对BIOS厂商和微软都是威胁——BIOS业者将不再有绝对的主控地位，而用户在开机后执行系统的选择性增加，就不见得一定得依赖微软的Windows了。其实不尽然。尽管UEFI比BIOS更先进，但是一些固件运作平台必须为了某些系统布局和配置而需要BIOS的功能，所以BIOS在未来依然有一定作用。至于说UEFI取代操作系统更是漫漫长路，事实上UEFI 只是硬件和预启动软件之间的接口规范，它的运行效率并不如操作系统直接高效，而且UEFI只具备简单的存储器管理机制，还不足以适应多任务环境的运行需求。
从发展趋势来看，业界将BIOS 转移至UEFI 的趋势已经不可避免。目前UEFI标准已经升级到开放标准的UEFI 2.x，不少厂商都已经投入了UEFI开发。比如Intel 目前已经停止其EFI 标准上的开发而全面转移到UEFI上，AMD 也选择拥抱UEFI 2.X 版本，给Phoenix提供了新的CPU 和芯片UEFI 驱动程序支持。现在的UEFI BIOS都是以Intel所撰写的UEFI功能核心Framework为基础，再加挂其编写的架构模块。甚至微软的Windows Server 2008、Windows Vista SP1和Windows7也都支持UEFI。随着UEFI的不断完善，将会有更多的公司愿意生产支持UEFI的产品。
当然，世上没有十全十美的东西，表面上看似很美好的UEFI其实也并非完美无暇。UEFI使用闪存作为存储介质，它的所有程序和代码都将保存在主板上的一颗闪存芯片中。如果这颗芯片发生损坏电脑将无法正常启动。从本质上讲采用C语言编写的UEFI存在着数据安全的隐患，只要是能使用C语言来编程的人可以很容易破译UEFI，这对UEFI的安全性提出了更高的要求。
