Beyond BIOS

BIOS FLASH 保护机制浅析

辛晓晨 — Tue, 26 Jan 2010 23:13:00 +0800

一，引言

多年前有一个很著名的病毒名叫CIH，当年CIH的流行曾经造成了巨大的经济损失。CIH可以攻击主板上的BIOS FLASH芯片，破坏里面的内容，从而使得受害者的计算机无法正常使用。这是人类历史上第一个可以破坏硬件的病毒。CIH可以攻击基于Intel 430FX芯片组的主板，由于FX芯片组在那个年代属于主流芯片组，所以无数的电脑在感染CIH后无法开机。只得返厂维修。至此人们第一次意识到对BIOS FLASH芯片的保护至关重要。之后的年代里，人们开始不断的改进FLASH的保护策略。

现代的主板上配备的BIOS FLASH芯片并不像过去那样不可更改。在286，386，486甚至早期Pentium时代，受制于芯片组的限制或者本身成本上的考虑，主板上装的往往是真正的ROM芯片。换言之那个时代的BIOS的确是不可写的东西。但是BIOS需要更新，因为BIOS也是人编的，也是软件。既然是软件就一定有BUG，BUG需要修复，所以人们需要重新对FLASH芯片进行编程以便能够升级BIOS。且人们还可以通过升级BIOS获得新的功能，于是后来的

祝大家新年快乐！新的一年发大财，撞大运！

辛晓晨 — Sat, 02 Jan 2010 11:07:00 +0800

再见2009，
欢迎2010！

prostar在这里祝每一位朋友都能在2010年里有更好的发展！

谢谢大家在过去的一年对我的支持！

大家今后有什么技术问题，也欢迎直接给我写邮件询问：xinxiaoc AT gmail DOT com

从一个小问题说开去 - 兼论编程责任

辛晓晨 — Sat, 19 Dec 2009 19:14:00 +0800

最近在写一个更新平台固件的程序，我们采用的方法基本上是在固件运行阶段安装一个SMI Handler，这个Handler在进入Windows/DOS/Linux等OS后依然存在。这个SMI把系统后台的一个runtime driver（主要访问SPI的）的几个读/写FLASH的接口给expose出来。这样当OS下的程序需要更新固件的时候，它们可以通过触发软件SMI，调用这些接口。这样就实现了更新FLASH。之所以这么设计，主要是考虑到最大限度的复用代码，因为现在BIOS都把FLASH本身存放Setup设置的场所，所以BIOS本身就可以写FLASH。事实上每一次开机，FLASH里面都会被更新几个值。这样一来，如果一个更新FLASH的代码再次实现一边读/写的代码，就有点重复了，且不同的平台读写的方法有可能因为芯片组的不一样而不太一样，为了避免要不断升级更新程序，这种实现方式是最好的。它第一可以保证仅有本公司的固件可以被更新（因为只有我们自己的固件才会内建这些服务）；其次可以最大限度的保证刷新工具的通用性。

不过我今天不打算继续谈及这个技术问题，

更好的UEFI组件构建工具：向大家介绍UEFI Module Builder

辛晓晨 — Tue, 20 Oct 2009 13:57:00 +0800

不知道诸位做UEFI开发的时候，是不是觉得UEFI下面构建一个单独的组件（.EFI文件）太麻烦了？每次都要写一个INF文件，而且写完了还要放到DSC文件里面。并且更讨厌的是，我明明只想生成一个EFI，为什么要向生成一个BIOS那样操作呢？虽然新版本的EDK具备了Build Module这样的功能，但是那些繁琐的步骤一个没少，并且有些明显是多余都build steps一个都不能少：如必须先生成tools，之后还要调用一些对构建单独Module根本不需要的tool来处理，如ProcessDsc等。
我们很多时候可能只需要生成一个驱动而已，想想大家在做开发的时候，基本上都是先写一个单独的驱动，然后在Shell下面用load指令加载到内存里，之后进行调试。当调试成功才会集成到BIOS内。如果是写UEFI应用程序，则更是如此，根本不需要那些多余的步骤。

可是受限于目前的EDK构建流程，想做但单独生成组件比较困难，而且更要命的是那另人发狂的生成时间！最新版的EDK具备了多线程编译技术，但是所谓的多线程只能达到组件级，换言之，单个组件内的源文件仍然是顺序编

UEFI BIOS ROM文件格式揭秘

辛晓晨 — Tue, 04 Aug 2009 15:17:00 +0800

很多朋友对于给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/

下面的Spec

UEFI BIOS OS Loader -- Q&A

辛晓晨 — Mon, 20 Jul 2009 15:33:00 +0800

UEFI BIOS的出现绝对不是仅仅为了执行CSM --- 否则要UEFI干什么。有必要先澄清一个概念：什么是UEFI-aware OS？

UEFI-aware OS是指完全基于UEFI开发的操作系统，完全不需要legacy bios参与。操作系统使用UEFI提供的调用，彻底抛弃传统的interrupt方式的实模式调用，并且将自己的操作系统加载程序实现为UEFI应用程序的形式。

如此一个操作系统就可以被称作UEFI-aware OS了。这样的OS Loader可以利用UEFI系统的提供的诸多功能。实现更为强大的操作系统加载程序。

操作系统加载程序是什么？传统环境下就是MBR代码，这些代码一般都很短，理论上不能超过512字节。基本上用汇编写。而且要求必须小精简。不过这些限制在UEFI下统统remove。

------------------------------------------------------------------------------------------

祝贺大家端午节快乐～！

辛晓晨 — Thu, 28 May 2009 22:25:00 +0800

RT。

希望每一位访问这里的朋友都能心想事成，永远快乐开心～～

再谈UEFI下的Protocol概念

辛晓晨 — Sun, 24 May 2009 09:40:00 +0800

很久写过一个关于protocol的入门文章，但是那个时候说实话写的的确不是很用心。今天在一个论坛看到有朋友又问道protocol如何学习的问题，考虑到protocol是整个UEFI系统的核心所在，我想还是再次重新写一个UEFI protocol的文章吧，希望能够给初学protocol的朋友们一个指路明灯。Protocol ：为什么要有Protocol大家都知道，UEFI的英文翻译过来应该叫“可扩展固件接口”。这个名词中最重要的事实上是“可扩展”这三个字。换言之，相比传统的系统固件而言，UEFI固件具备了完善的可扩展支持。这个概念对软件行业不是一个新概念，但是对bios这样一个陈旧腐朽的东西而言，的确是一个创新的思想。所谓可扩展的含义就是可以在系统完成后（编译为binary）之后，再次为系统增加新的功能，而不用重新rebuild整个系统。在这个大的需求的前提下，还有一些其他的重要的含义，比如必须支持不同的组件的独立开发。比如A厂商今天针对某硬件开发了一个驱动，他们发布了一个二进制包APackage

给大家推荐一个网站：LinkedIn

辛晓晨 — Tue, 12 May 2009 23:59:00 +0800

最近一直在上LinkedIn（http://www.linkedin.com/）。我自己从这个网站获益匪浅，好网站不敢独享，发到博客里和大家共同分享吧。

LinkedIn是一个面向专业人士的社交网站，是英文的。上面有很多业界的大牛，很多过去对中国的开发者来说只存在于传说中的大牛们都在这个网站上有注册，且一直活跃。这个网站类似我们国内的校内，但是也有很多不同，我下面大概说一下，具体的还要大家自己去注册，去体会哦！

1. Connections。这个网站把你的好友叫Connectons。且有一个connection level的概念，你的直接好友是你的第一层level 1，你的connection的connection是你的level 2，一次类推。但是一个注册用户只能看到做多3层connection。换句话说，这类似人际交往圈。你只能看到你认识的人的资料。而且你如果不认识一个人，是不能将其直接添加为好友的。你必须至少知道这个人的Email才可以。这就保证了没有国内的类似网站的那种什么人都加的弊端。保证了仅仅只是专业人士才能互相c

UEFI 2.3 Specification Released! First UEFI ARM Binding Support!

辛晓晨 — Tue, 12 May 2009 23:49:00 +0800

今天上了UEFI联盟的网站，忽然发现UEFI 2.3规范已经发布了！大家可以立刻去

http://www.uefi.org/上下载最新的规范版本。

这是一个令人激动的发布，2.3版本的UEFI版本相对前几个版本最大的不同就是增加了对ARM的支持。这说明UEFI开始真正的从规范上支持非x86体系架构的系统了。这对UEFI的推广无疑是利好的消息。

为了支持ARM，UEFI下辖的USWG工作组特别成立了ARM Binding Working Group负责将UEFI和ARM联系到一起。这个工作组的主席是ARM界非常有名的大牛Andrew Sloss（没错，就是大名鼎鼎的《ARM Software Developer's Guide》）的作者。能请到Sloss出山，可见UEFI的影响力之大。

事实上UEFI一只寻求非X86的应用机会，而且也得到了一些成功。我们大家熟悉的IPHONE，其核心固件便是基于UEFI实现的。Intel把XScale卖掉之前，已经在XScale上实现了UEFI。这