很多朋友对于给BIOS增加一个ACPI SLIC表来激活OEM Windows Vista(Windows 7?)乐此不疲,对于Legacy BIOS他们有成熟的工具链支持,那些从BIOS厂流出的工具可以帮助大家轻松给ROM里增加一个新的SLIC表,从而达到激活Windows的目的。
但是对于UEFI BIOS,就没有那么简单了。现在能够修改的主板100%是Legacy的,我还从没有听说过有人可以成功的修改UEFI的主板,比如Intel的原装主板。
原因很简单,UEFI ROM的存储格式与过去的BIOS完全不同,现有工具根本无法读取ROM里面的配置信息,添加SLIC自然也就无从说起了。好在UEFI ROM的存储格式是完全公开的,只是大家不知道而已。它完全没有cover在某一个NDA的限制下,所以我才可以撰文毫无保留的给大家来谈谈UEFI ROM的存储格式。
关于存储格式的详情,感兴趣的朋友们可以去:
http://www.uefi.org/
下面的Specification下面,下载Platform Initialization Specification(俗称PI),里面的第四卷Firmware Storage Specification就详细的描述了存储格式的详情。
由于本文是一片抛砖引玉类似的东西,且存储格式实在很是复杂,所以我只能大致上说说,具体还真的要诸位去看spec了。
整个存储格式有个正式的名字,叫FFS。Firmware File System(固件文件系统),事实上这是一个定义良好的一个只读(写非常困难,但是并不是完全不可能)文件系统实现。
1. FD
整个ROM,在逻辑上被看作成一个设备。叫FD,就是Firmware Device。你可以把FD想象成一块硬盘,想象成硬盘的好处是下面我们提及其他的概念的时候,可以和硬盘上的类似概念有个类比。总的来说,FD只是为了表示方便。
2. FV
硬盘要分区,FD也不例外,整个ROM(FD)就被分成一些区域,这些独立的区域叫做FV。硬盘上的分区有时也叫Volume。FD上的类似的东西也这么叫,于是FV就是Firmware Volume了。
3. File
谈这个概念之前,我要先澄清一下文件系统下的文件(File)的概念。什么是文件?什么又是文件名?文件是存储区域上的一个区域的表示,文件名则是这个区域的一个唯一表达。这样说有些抽象,其实文件系统可以看作是一个逻辑转换。转换了什么东西?说的再明白一点,文件系统是把物理上的概念转换成逻辑概念。
举个例子,硬盘的物理概念包括磁道,扇区,柱面等等。我们要存储的时候,总不能这样告诉Windows吧:把这些数据存储在2柱面,176磁道,35扇区!我想没人这么干。我们一定是这样告诉Windows的,创建一个文件DATA.TXT存储。换言之,在我们这个列子里,文件名DATA.TXT被正确的通过文件系统,转换成了2柱面,176磁道,35扇区。这就是文件系统的概念。依次类推,文件的概念也就清楚了。
那么在FV内,File也有同样的作用。只不过它的名字是固定的格式,每个FV内的File都必须以一个GUID命名,且不准有重复。还记得GUID不?我们之前的Protocol的文章里有谈到GUID。
4. Section
FFS比较特别,允许每个File里面分成不同的段(Section),每种类型的Section都存储特定的数据。比如PE32类型的Section存储的是代码。而RAW类型的Section则存储包括ACPI Tables这样的纯数据。段的类型很多。甚至允许存储另一个FV的压缩。这另一个FV如果被解压缩,就又是一片天地了。
----------------------------------------
BIOS ROM --- FD
|
|---- FV
|---- FV
|---- FV
|
|--- File
|--- File
|--- File
|
|---- Section
|---- Section
|---- Section
Section can contain any data depends on their type, even the another compressed FV