从平台重启直到构建出UEFI兼容环境所需的完整过程

从平台重启直到构建出UEFI兼容环境所需的完整过程

在UEFI的最后一段历史中，我们看到了UEFI和PI的概念和渊源。我们现在来看看 UEFI 和 PI 到底是什么，以及 UEFI 组织是如何工作的。

UEFI 和 PI

“UEFI纯粹是一个接口规范，并不具体涉及平台固件是如何实现的，‘如何实现’是PI（Platform Initialization）要解决的问题。”

在上一篇UEFI的历史中，我们了解了UEFI的由来。现在让我们详细了解一下UEFI和PI是什么，它们的区别是什么。这里要强调一个概念：UEFI纯粹是一个接口规范，不会具体涉及平台固件是如何实现的。“如何实现”是PI（Platform Initialization）要解决的问题。UEFI 用户包括但不限于操作系统加载器（OS Loader）、安装器（installers）、来自引导设备的 ROM（适配器 ROMS）、操作系统预诊断（pre-OS diagnostics）、工具（utilities）和操作系统运行时服务（OS runtimes-services）。一般来说贷款技术新口子论坛，UEFI 是关于引导过程如何发生的。引导是一个连续和逐步转移控制权以启动整个操作系统的过程。这是OS Loader的职责，如下图所示：

与 UEFI 的开放性不同，PI 在很大程度上与 pre-OS bootloader、OS 及其加载程序无关，因为 PI 在平台构建中有太多与这些 UEFI 用户无关的程序。PI描述了从重启平台到搭建UEFI兼容环境的完整过程，如下图所示：

在该框架逐渐演变为今天的 PI 的过程中，PI 规范中没有包含一些“渣滓”。例如：CSM 规范定义了如何在 PC/AT 系统上启动。该系统必须包含一个x86架构处理器、PC/AT硬件组合（如8254、8259、RTC）。CSM 还继承了其他正常的 BIOS 引导限制，例如主引导记录 (MBR) 分区表的 2.2 TB 磁盘限制。对于 PI 和 UEFI 构建的自由世界，您可以获得 x86（IA-32 和 x64）、ARM、Itanium? 和未来各种 CPU 的所有功能。此外，通过模块化设计、UEFI APIs和PI DXE协议，平台和组件的硬件细节（参数、实时状态等）被高度抽象。也放弃了对Data Hub的支持，

除了框架，PI还包括以下内容：添加多处理器协议（MP CPU）、Itanium E-SAL和MCA支持、status code reporter（状态码）、SMBIOS协议、ACPI支持和SIO协议等。PI基本形成后，对SMM协议和基础设施进行了重大更新，更好地抽象了CPU和芯片组之间的接口。PEI 支持更多的总线，例如 PCIE。所有这些都是为了更轻松地将 SMM、PEI 和 DXE 驱动程序迁移到 PI。固件文件系统和卷已扩展以识别更大的文件和其他编码。

PI的一个显着特点是有大量的UEFI论坛成员参与，后面会详细介绍。这些参与者代表 PI 技术的用户和生产者。PI 组件的最终用户是携带系统板的供应商，包括苹果、戴尔、惠普、IBM、联想等跨国公司。PI 组件的生产商包括通用基础设施生产商，例如 AMI、Byosoft、Insyde 和 Phoenix 等独立 BIOS 供应商 (IBV)。最终，制造芯片组、CPU 和其他硬件设备的供应商（如 AMD、ARM 和 Intel）将为各自的硬件编写驱动程序，IBV 和 OEM 将使用这些驱动程序。如果没有不同公司的交叉调用要求，那么统一的DXE和PEIM标准是没有意义的。特别是，这些基于 GUID 的 API、编组接口、发现和调度代码等会占用更多空间并增加引导过程所花费的时间。考虑到我们总是会节省ROM空间，而客户对开机时间有刚性要求，比如“即时开机”，企业必须综合考虑启用PI模块带来的商业价值与其性能损失之间的平衡。如果只有一个供应商可以访问所有程序并拥有构建平台的所有知识产权，那么静态绑定实现确实会变得更加高效。但在 21 世纪，当计算行业拥有如此多的各种硬件和软件参与者时，这不太可能发生。目前，

UEFI和PI还在不断发展，最新的规范是UEFI 2.5和PI 1.4。在GitHub网站（tianocore）上，可以找到大量的源码实现，比如EDK I（EFI Developer Kit version 1）和EDKII的实现。

UEFI论坛

我们现在关注 UEFI 论坛如何管理 UEFI 和 PI 这两个规范。也就是说，UEFI论坛是如何制定这两个规范的。

可以说，UEFI论坛的基本形成过程就是第一版UEFI规范的制定过程。毕竟论坛是为规范而生的，规范制定过程中的自然分工才是论坛的初始架构。

本届论坛经历了以下重要事件：

(1) UEFI论坛利益相关者就EFI方向达成共识

（2）行业标准（Industry commitment）的统一催生了行业集体参与管理的需求

(3) 英特尔和微软提供初始技术信息更新规范

(4) EFI 1.10 版本提供初始草案规范

(5) Intel同意提供EFI测试套件(SCT)

因为Intel其实已经完成了第一版的EFI规范和实施，并且得到了整个行业的认可之后，论坛已经基本形成了。

UEFI 论坛在华盛顿注册为非营利性公司。负责制定、推动和管理UEFI规范的演进，不断推动UEFI采用的低门槛。

UEFI成员管理采用层级体系：发起人、贡献者和使用者。可以在欢迎使用统一可扩展固件接口论坛上找到有关此分类的更详细说明。发起者层级包括：Intel、AMD、AMI、Apple、Dell、HP、IBM、Insyde、Lenovo、Microsoft 和 Phoenix。

下图为论坛的基本构成及对应的角色：

每当发现有足够深度的话题，需要大家集思广益时，就会在相应的工作组下成立子组。这些分组的成员来自不同的公司（这些公司都是UEF论坛的成员），与主题相关的公司的技术人员聚集在一起解决问题，并将主题的相关材料和反馈反馈回各自的工作组. 通过决议后纳入现有规范。图中展示了三个子组，下面将对其进行详细介绍，以方便理解UEFI论坛的工作模式。

1. UCST-UEFI配置子组，该组负责所有配置相关的资料。同时，UEFI Spec中的UEFI配置基础设施贷款技术新口子论坛，统称为HII，也是由这个小组创建的。

2. UNST – UEFI 网络子团队。该小组负责网络相关资料，更新和维护UEFI Spec中的相关内容。该团队过去最突出的贡献是制定了 Spec 的 IPV6 网络基础设施部分。

3. USST-UEFI 安全子组负责安全信息。该团队已将安全基础设施部分的内容添加到 UEFI 规范中。

PIWG 和 USWG

两个非常重要的工作组是： PI工作组（The Platform Initialization Working Group，简称PIWG）是专门负责制定Spec的PI部分的工作组。UEFI Specification Working Group（简称USWG）是主要负责推进UEFI Spec的部门。下图显示了平台的布局和这两组的大致组成：

同样，UEFI 规范是关于操作系统、附加驱动程序和系统固件的。操作系统和其他高层软件可以也只能通过UEFI Spec中的接口或服务进行交互。

PI 是关于 UEFI 如何实现的规范：

(1) 促进固件组件供应商之间的互操作性

(2) 所有接口和服务仅由固件生成和使用

下图展示了PI是如何将各个部分演变成UEFI的。在表的左半部分，SEC、PEI 和 DXE 指的是 PI 规范。BDS、UEFI+OS Loader和RT一起属于UEFI规范。

平台安全

正如我们前面提到的，PI 提高了模块生产商和系统构建商之间的互操作性。此外，还有更多行业参与者可以从 UEFI 规范中受益。其中包括： 构建操作系统安装程序和基于 UEFI 的运行时服务的操作系统供应商；提供 UEFI 实现的 BIOS 供应商；平台厂商，如采用UEFI标准的跨国公司；为策略创建 UEFI 应用程序和诊断独立软件供应商；为其产品创建驱动程序的独立硬件供应商；和平台所有者，从家庭 PC 用户到企业 IT，基于 UEFI 的系统早已无处不在。

PI和UEFI在安全方面各有优缺点。未来，我们将有机会就这个问题进行更深入的讨论。但总的来说，它们各自职责在安全方面有以下区别：PI必须保证PI元素只能由平台厂商更新、恢复，PI是UEFI功能（包括安全）的安全设施的基础); UEFI 提供基础设施来验证用户、验证 UEFI 可执行文件的来源和完整性、网络验证和传输安全、审计（包括基于硬件的测量启动）以及跨 UEFI 策略对象（包括写保护的 UEFI 变量）控制的管理。

下图显示了 PI 实施中的各种元素如何协同工作以确保安全性。

新挑战：嵌入式系统

随着UEFI的快速发展和全面普及，它迎来了新的挑战——嵌入式设备。尤其是消费类电子产品，每个用户的需求都不一样，光是嵌入式操作系统的即时开机就有各种各样的要求。这些系统中的大多数都有自己独特的固件和固件接口，并且通常不能很好地适应 PC 固件生态系统模型。

难题的核心是如何使嵌入式平台固件与传统模型相似，例如独立于操作系统、可跨不同平台硬件扩展，从而减少开发时间并采用 UEFI 标准。

让我们看看常规启动与优化/嵌入式启动有何不同。从 UEFI 架构的角度来看，常规启动和优化启动之间没有设计差异。优化平台性能并不一定意味着违反任何设计规则。还需要注意的是，符合UEFI规范并不意味着实现其下的所有标准PC架构，而是重新设计平台自身初始化的必要组件，使其符合UEFI规范（UEFI Spec 2.3中的Chapter 2列出了详细说明符合 UEFI 的各种组件和要求）。

总结

希望读者看完这篇文章，能够了解UEFI论坛的运作。如果您也能增加对UEFI的兴趣，想进一步了解它，那我们将不胜荣幸。

BIOS培训云课堂：

其他关于 UEFI 历史和架构的文章：

欢迎大家关注本专栏，微信扫描下方二维码加入微信公众号“UEFIBlog”，您将在这里获取最新文章。同时欢迎大家为本栏目和公众号投稿！

微信扫描二维码加入UEFIBlog公众号