UEFI运行时服务在操作系统中的作用及相关技术疑问

初始理解纠正 #

• UEFI运行时服务在DXE阶段完成初始化，但并非在该阶段被调用，其设计目的是供操作系统启动后使用。
• x86架构下，UEFI运行时服务通常运行在Ring 0（与操作系统内核权限相同），而非更高权限环；部分厂商实现可能借助SMM，但这不属于标准规范。
• 操作系统内核启动后，UEFI运行时服务不会后台持续执行，仅在操作系统主动发起调用时才会运行。

问题解答 #

1. UEFI运行时服务运行在何种内存空间？该空间是否标准化？是否属于主内存（如DDR RAM）区域？ #

UEFI运行时服务的代码和数据存放在UEFI Runtime Services Code和UEFI Runtime Services Data类型的内存区域中，这两类区域由UEFI规范明确定义，属于标准化的内存类型。
这些区域完全属于主内存（DDR RAM）的一部分，操作系统或虚拟机管理程序可以访问，但必须遵循规范要求：在OS启动后，不能随意修改这些区域的内容，且在进入不同电源状态（如休眠）时，需要按照UEFI要求对这些内存区域进行相应处理（比如保留内容不被写入交换分区）。

2. UEFI运行时服务如何在CPU上调度？控制权如何转移至这些服务？它们是否必须并行运行？ #

• 调度与控制权转移：UEFI运行时服务由操作系统主动调用——OS内核通过引导加载程序传递的函数指针，直接跳转到UEFI运行时服务的代码执行。调用过程中，OS会先保存自身的执行上下文，切换到UEFI的执行环境（比如切换页表、设置特定寄存器状态），执行服务后再恢复自身上下文继续运行。
• 并行性：UEFI运行时服务不支持并行运行，规范要求同一时间只能有一个CPU核心调用运行时服务，且调用期间必须禁用中断，避免并发冲突。

3. UEFI运行时服务是否存在类似SMM的不可预测控制流转换及延迟问题？ #

UEFI运行时服务的调用是操作系统主动发起的可控操作，不存在SMM那种硬件触发的不可预测控制流转换。但部分UEFI运行时服务的实现可能会执行耗时操作（比如访问BIOS芯片或硬件设备），导致一定的调用延迟；另外，如果厂商实现存在bug，可能会出现服务执行超时或异常的情况，但这属于厂商实现问题，而非规范本身的设计缺陷。

4. UEFI运行时服务对Linux或*BSD这类操作系统的运行是否必不可少？ #

并非必不可少。Linux和*BSD都实现了不依赖UEFI运行时服务的替代方案，比如通过ACPI直接实现电源管理、硬件配置等功能。在禁用UEFI运行时服务的情况下，系统依然可以正常启动并运行大部分功能，仅少数特定功能（如UEFI变量读写、部分特殊硬件的固件更新）会受影响。

5. 其核心功能能否被ACPI替代？运行时服务还提供哪些额外功能？ #

• 核心功能替代：部分核心功能（如电源管理、系统关机/重启）可以通过ACPI替代，但并非全部。
• 额外功能：UEFI运行时服务还提供ACPI无法覆盖的功能，包括：
  • UEFI变量的读写（用于存储系统配置、启动项、安全密钥等信息）
  • 固件版本查询与更新相关的接口
  • 时间服务（读取/设置硬件实时时钟，处理时区和夏令时）
  • 非易失性存储的访问接口
  • 部分特殊硬件的固件级控制接口

7. UEFI运行时服务的可用性是否依赖引导加载程序的支持？ #

是，UEFI运行时服务的可用性依赖引导加载程序的支持。

8. 为何缺少引导加载程序支持会影响UEFI运行时服务的使用？若缺少相关支持，这些服务是否仍在后台运行？ #

• 影响原因：引导加载程序需要完成两项关键工作才能让OS使用UEFI运行时服务：一是将UEFI提供的运行时服务函数指针传递给OS内核；二是按照UEFI规范完成内存映射的处理（比如标记Runtime Services内存区域的属性，确保OS不会误修改这些区域）。如果引导加载程序不支持这些操作，OS无法获取服务入口，也无法安全地调用服务。
• 后台运行状态：UEFI运行时服务本身不会在后台运行，无论引导加载程序是否支持，它们都处于待命状态。但缺少引导加载程序的支持时，OS无法发起合法调用，相当于这些服务对OS不可用。

内容的提问来源于stack exchange，提问作者zee_ro