GRUB2 分析 (三)

上一篇

 

从地址0x8200开始的是lzma_decompress.img。这是由startup_raw.S编译生成的。这个文件稍微复杂点。首先一开始就是个跳转指令:

ljmp $0, $ABS(LOCAL (codestart)) /* 机器码:ea 1c 82 */

跳转到0x821c,这里是真正的开始代码。0x8203到0x821b之间存放的是一些特殊数据,如压缩数据前后的长度、冗余数据的长度等,由GRUB安装时填写,后面会用到。

 

接下来设置实模式堆栈后,切换到保护模式:DATA32 call real_to_prot

然后打开Gate A20,即第21根地址线的控制线: call grub_gate_a20 这是在80286时代IBM想出来的通过开闭Gate A20来兼容8086/8088实模式的方法。在保护模式下,为了正常寻址必须把Gate A20打开。


然后开始利用里德-所罗门(Reed Solomon)算法对GRUB受保护数据进行检查和修复:

call EXT_C (grub_reed_solomon_recover)

RS恢复代码是用C写的,文件是lib/reed_solomon.c。编译时会先编译成rs_decoder.S然后被startup_raw.S包含。(最新的GRUB版本应该生成的文件名是rs_decoder.h,只是改了个名字。)

RS保护的范围以reed_solomon_part标记开始(Gate A20代码后,多重启动代码前),到lzma_decompress.img结尾,再到后面接着的压缩过的kernel.img映像结尾。在此后面是冗余数据区。冗余数据是被算法利用对受保护数据进行修复的。

这样算来GRUB数据的前5个扇区(0-4)以及部分第6个扇区是不受保护的,其他都受到了保护。 


为什么要做这件事情?如之前提到的,硬盘2-62号扇区是不安全的,有可能被其他软件写入数据破坏。利用冗余数据,GRUB有能力从这种破坏中正常引导,如果破坏的数据量在可接受范围内的话。我记得GRUB社区有一场讨论,关于如何处理与其他软件冲突的问题。就像一场罗马元老院辩论一样,有人忿忿不平,觉得这种在保留扇区写隐藏数据的行为是邪恶的,GRUB应该以牙还牙,数据恢复过来后,就应该写回硬盘,虽然这会造成其他软件不能工作。也有人认为,普通用户并不会理解这里面的是非曲折,而把一切问题怪罪到GRUB头上,GRUB应仅仅支持防御性的操作。


RS恢复操作执行完后跳转到标记post_reed_solomon对余下的压缩过的kernel.img进行解压缩:

jmp post_reed_solomon /* 偏移量:0x07a6,不同版本会有差异 */

解压后的数据存放在地址0x100000开始的内存区域。

解压算法采用LZMA算法。具体实现在lzma_decode.S中,是手工优化精简的版本。


最后执行跳转指令:

jmp *%esi /* GRUB_MEMORY_MACHINE_DECOMPRESSION_ADDR = 0x100000 */

跳转到地址0x100000执行下一条指令。也就是刚才解压缩出来的第一条指令。


至此startup_raw.S执行完毕。

GRUB2 分析 (三)

上一篇:Http的请求的全过程


下一篇:自己项目管理的一些实用表格