GRUB基础 — Multiboot规范_grub multiboot header规范

背景

• 每个操作系统(OS)在设计时都会考虑对boot loader的支持，OS的安装通常也涉及boot loader的预安装。在支持多OS的物理服务器使用场景中，通过链式机制让一个OS去引导另一个OS显然效率低下；定义一套boot loader和OS之间的接口，让遵循接口的所有boot loader都可以引导遵循相同接口的OS，才是更合理的解决方案。多OS兼容的场景我们称为Multiboot，boot loader和OS之间的接口规范我们称为Multiboot Specification。
• GRUB是遵循Multiboot Specification的boot loader之一。1995年，Erich Boleyn和Brian Ford在GNU Hurd项目的开发过程中设计了Multiboot规范，并将GNU Hurd的boot loader作为规范的实现引导并其微内核GNU Mach。之后Erich尝试修改FreeBSD的boot loader让其兼容Multiboot规范，发现与其修改FressBSD的boot loader，不如直接从零开始单独写一个软件，至此GRUB诞生。可以说，GRUB就是为兼容多OS场景而生的。
• GRUB在之后不断扩展以满足新的需求和场景，但很快，开发者发现GRUB遵循的Multiboot规范存在一些致命的缺陷导致对某些新功能的支持非常困难，并且设计导致的bug也不断增多，因此在2002年，Yoshinori K. Okuji开始重写GRUB的核心代码并将其重命名为GRUB2，原来的GRUB被重命名为GRUB Legacy，GRUB2遵循了Multiboot2规范。约2007年，GNU/Linux的发行版开始使用GRUB2，到2009年，大多数的Linux发行版已经将GRUB2作为默认版本安装。

目标

• 分析多OS使用场景，Multiboot规范需要考虑以下需求：

1. 支持多种方式的OS启动；包括光盘启动，硬盘启动以及网络等
2. 支持启动阶段对OS的动态配置；规范需要定义配置的标准方式
3. 避免对OS紧耦合；方便OS功能的独立开发
4. 支持启动模块；部分OS的启动无法独立完成，它们依赖其它预先启动的模块，如微内核操作系统Mach，规范需要考虑对启动模块的通用支持

• 分析boot loader和OS的交互逻辑，可以将两者的接口定义从以下三个方面拆分：

1. OS image format - 对OS镜像格式的定义，便于boot loader识别镜像并加载其内核到内存
2. Machine state - 对boot loader状态的定义，便于OS判断其引导者boot loader的状态
3. Boot information format - 对boot loader与OS之间传输信息的格式定义，便于控制OS的某些行为

• Multiboot与Multiboot2都基于以上的分析而设计，Multiboot2在具体定义上扩展性更强，标准化做的更好，下面我们基于以上三点对比介绍两个规范的具体内容。

OS image format

• OS image通常是一个普通的可执行文件（遵循ELF规范），其payload就是OS的section。通常boot loader将OS image加载到load address（ELF规范中section entry的sh_addr）对应的内存，之后跳转到entry address，最后将控制权交给OS。
• 如果所有的OS image都遵循ELF规范，那么boot loader总是可以根据规范找到OS image中包含的section并提取其load address，将其正确加载到load address指定的地址，但是，Mulitiboot规范需要考虑不支持ELF规范的OS image，也能被boot loader顺利地找到，就是说boot loader可以不需要理解ELF规范或者其它规范，也能正确地将OS image加载运行，要实现这个目标，需要将ELF规范中关于二进制程序加载相关的接口在Multiboot中也定义一遍，因此我们推测，OS image format必然包含了如何加载OS image的信息。
• 另外，某些OS image还会指定其倾向的图形模式，因此Multiboot提供了供OS image描述其推荐的图形信息可选字段。
  除此之外还会有其它一些信息作为OS image format的内容，这里不赘述。

Multiboot

• Mulitboot设计的OS image format分为了三个部分，其格式如下：
  
• 每个字段的长度和偏移如下：
  

Magic fields

• Magic - 魔数，值为0x1BADB002，标示一个兼容Multiboot规范的OS image
• Flags - 标识域，用于OS images向boot loader展示加载其自身涉及的一些依赖特性和可选特性。其中bit 0 ~ bit 15是依赖特性，如果boot loader无法理解这些特性，boot loader会直接报错；bit 16 ~ bit 31是可选特性，boot loader无法理解可以忽略。我们简单介绍以下特性：

1. bit 0，内存页对齐标记位，如果置位，OS image要求boot loader在加载启动模块（boot modules）时将其地址按照4k对齐。其原因是某些操作系统希望直接将启动模块映射到地址空间，4k对齐可以方便映射
2. bit 1， 内存信息标记位，如果置位，OS image期望boot loader将系统的可用内存信息按照Boot information format中的定义，写入到mem_*字段，方便OS启动后解析，如果boot loader有能力获取整个内存映射的视图，写入mmap_*字段
3. Bit 2，图形信息标记位，如果置位，OS image期望boot loader填入图形信息到Boot information format定义的对应字段
4. Bit 16，加载信息标记位，可选，如果置位，标示地址字段（address fields）有效，boot loader不再根据ELF header中的地址计算加载地址，而是按照该字段包含的地址加载OS image。当OS image遵循ELF格式时，该字段不需要OS image提供，boot loader可以直接根据ELF头部解析OS image并正确加载；当OS image不是ELF格式时，该字段就是必填项了，boot loader会从这个字段提取加载地址并加载OS image到对应的内存位置。

• Checksum

Address fields

• Boot loader加载非ELF格式的OS image file示意图如下所示：
  
• Header_addr - OS image要求boot loader将Multiboot header加载到的内存物理地址。boot loader在加载OS images时，首先查找魔数0x1BADB002在OS image文件的偏移（后文用header_offset表示），然后从header_offset开始，加载header_addr - load_addr长度的内容到Header_addr指向物理内存，完成header的加载。
• Load_addr - OS image的代码段加载地址。boot loader计算Load_end_addr - Load_addr的长度，作为代码段的长度（text segment length），然后从header_offset + (header_addr - load_addr)开始（代码段在OS image文件的偏移text_seg_offset），拷贝text segment length长度的内容到Load_addr指向的物理内存，完成代码段的拷贝。
• Load_end_addr - 代码段结束地址。当该字段存在时，用于计算加载OS image代码段的长度；当该字段为零时，从text_seg_offset到文件结束都是代码段的内容，boot loader会全部加载。
• Bss_end_addr - bss段地址。如果该字段不为零，boot loader会将该地段指向的物理地址预留作OS的bss段使用
• Entry_addr - OS入口地址。完成整个OS image加载后，boot loader程序跳转的物理地址。

Graphics fields

• Graphics fields是OS image期望boot loader设置的显卡图形模式和具体的设置参数，即显卡的framebuffer参数，有4个字段：

1. Mode_type - 期望boot loader设置的模式，0表示线性扫描模式，1表示EGA文本模式。
2. Width - 期望boot loader设置的framebuffer行数
3. Height - 期望boot loader设置的framebuffer列数
4. Depth - 期望boot loader设置的framebuffer分辨率，即每个像素包含的bit

• 可以看到，Multiboot规范在设计OS image format这部分时，针对每个需求场景都考虑了对应的字段，但没有做扩展性设计，一旦有新的需求引入，基于现有的OS image format很难实现其功能。

Multiboot2

• Mulitboot2总结了Multiboot的缺点，设计OS image format时，在功能扩展性和架构扩展性等方面都做了对应考虑。Mulitboot2的OS image format格式设计如下：
  
• Mulitboot2设计了一个通用格式（tag）来表示OS image的需求信息，将每一类信息以tag的形式存放，用特殊的tag（end tag）标识结束。可以看到，Mulitboot中设计的address fields和graphics fields包含的信息被address tag、entry tag、framebuffer tag等tag提供了。同时，Mulitboot2在magic fields中还增加了架构相关的字段，对支持架构进行了扩展。
• 可以看到，Multiboot2不兼容Multiboot规范，因此基于Multiboot2实现的GRUB2也不兼容GRUB。

Machine state

• Boot loader在加载OS image到内存与跳转到entry address将控制权交给OS这个过程中，还有一些准备工作，包括向OS同步一些自己的状态，并向OS传递一些参数，从而实现对OS的动态配置。Boot loader利用CPU的寄存器完成这个工作。

Multiboot

Multiboot规范在设计时仅考虑了intel i386架构，因此它仅仅规定了如何使用i386CPU寄存器完成状态和参数传递。在交出控制权给OS之前，multiboot规范要求CPU具有如下状态：

• EAX
  存放multiboot header的魔数，0x2BADB002，以此向OS表明它是被multiboot-compliant的boot loader引导的，而非其它boot loader。
• EBX
  存放OS启动信息（Boot information）的物理地址，OS启动信息的格式参考下一小节
• CS
  存放OS image代码段（code segment）物理地址
• DS
• ES
• SS
  存放OS image数据段（data segment）物理地址
• A20 gate
  设置为使能
• CR0
  清零PG（Paging）位，禁止分页；使能PE（Protection Enable）位，开启页保护
• EFLAGS
  清零VM（Virtual Real Mode）位，禁止进入虚拟实模式；清零IF（Interrupt Flag）位，屏蔽中断
• ESP
  栈指针，由OS在启动后设置，boot loader不做设置
• GDTR
  全局描述符表寄存器，当OS准备好全局描述描述表之后，设置该寄存器，boot loader不做设置
• IDTR
  中断描述符表寄存器，当OS准备好中断描述符表之后，设置该寄存器，boot loader不做设置

Multiboot2

• Multiboot2规范在设计时考虑了对不同平台的支持，而不同平台的硬件寄存器不相同，因此Multiboot2分平台定义machine state，这里的平台包括但不限于MIPS，i386，EFI i386，EFI amd64等，其内容和Multiboot类似。如下：

MIPS machine state

• TBD

i386 machine state

• TBD

EFI i386 machine state

• TBD

EFI amd64 machine state

• TBD

Boot information format

• 上文提到EBX中存放的物理地址指向了boot loader传递给OS的参数信息，其格式即为Boot information format，OS按照该格式解析启动信息。

Multiboot

• Multiboot定义的格式信息如下：
  

Multiboot2

• Multiboot定义的boot information format和OS image format相同，不具有扩展性，Multiboot2没有这一缺陷，它同样以tag为基本结构对boot information做描述，其格式如下：