UEFI和UEFI论坛 2021-10-08 操作系统 暂无评论 2628 次阅读 在上一篇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（adapter ROMS），操作系统的预诊断程序（pre-OS diagnostics），工具（utilities）以及操作系统运行时服务（OS runtimes-services）。通常，UEFI是关于如何进行引导过程的。引导就是一个将控制权限连续，逐级地移交，从而启动整个OS的过程，这就是OS Loader所肩负的职责，如下图所示：  与UEFI的开放不同，PI，对pre-OS引导程序，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的protocol，平台以及组件的硬件细节（参数，实时状态等等）被高度抽象了。Data Hub的支持也被放弃了，其大部分功能在后来被SMBIOS table的相关功能所代替。 除了框架以外，PI还包含了以下内容：添加多处理器协议（MP CPU），Itanium E-SAL和MCA支持，状态码报告器（status code），SMBIOS协议，ACPI支持以及SIO protocol等等。在PI基本成型后，对SMM协议和基础架构进行了重大更新，更好地抽象了CPU和芯片组的接口。在PEI对更多的总线进行支持，例如PCIE。所有这些，都是为了让SMM，PEI和DXE驱动程序更方便地迁移到PI。针对固件文件系统和卷进行了扩展，以便使其可以识别更大的文件和其他编码方式。 PI的显着特点是数量众多的UEFI论坛成员的参与，这将在稍后进行更详细的描述。 这些参与者代表了PI技术的使用者和生产者。PI组件的最终使用者是搭载了系统板的供应商，包括诸如Apple，Dell，HP，IBM，Lenovo等许多其他跨国公司。PI组件的生产商包括通用基础设备生产商，如独立BIOS供应商（IBV），如AMI，Byosoft，Insyde和Phoenix等。最后，制造芯片组，CPU和其他硬件设备的供应商（如AMD，ARM和Intel）将为其各自的硬件编写驱动程序，而IBV和OEM将会使用这些驱动。如果没有不同公司的交叉调用需求，这样一个统一的DXE和PEIM的标准就没有什么意义了。尤其是这些基于GUID的API，编组接口，发现和调度代码等都会占据更多的空间，增加引导过程的用时。考虑到我们永远都要节省ROM空间，而且客户对启动时间都有刚性需求，例如需要“即时启动”，企业必须综合考量启用PI模块所能带来的业务价值和其性能损失之间的平衡。如果只有一个供应商可以访问所有的程序和拥有所有知识产权来构建一个平台，那么静态绑定的实现将确实会变得更有效率。但是在二十一世纪，计算行业有着如此之多的各类硬件和软件的参与者，这一情况基本不可能发生。就目前来说，面对着资源不断减少和新品更新速度加快的严峻的市场形势，PI技术成为UEFI论坛成员提升其商业竞争力的最佳技术手段。 UEFI和PI还在继续演进中，最新的规范是UEFI 2.5和PI 1.4。在GitHub网站上（tianocore），你可以找到大量的源代码实现，例如EDK I（EFI Developer Kit版本1）和EDKII的实现。 #UEFI论坛 我们现在重点介绍UEFI论坛是如何对UEFI和PI这两个规范进行管理的。或者说，UEFI论坛究竟如何制定这两种规范。 可以说，UEFI论坛的基本成型的过程就是UEFI初版规范的制定过程，毕竟，论坛就是为规范而生的，在制定规范过程中的自然分工就是论坛的初期结构。 论坛经历了以下几个重要的事件： （1）UEFI论坛利益相关者就EFI方向达成一致意见 （2）行业标准的统一（Industry commitment）催生了行业集体参与管理的需求 （3）Intel和Microsoft提供了最初的技术资料以更新规范 （4）EFI 1.10版本提供了最初的规范草案 （5）Intel同意提供EFI测试套件（SCT） 因为Intel其实已完成了初版的EFI规范和实现，在得到全行业的认同之后，论坛已算是基本形成。 UEFI论坛在华盛顿注册为非营利性公司。 它负责开发，促进和管理UEFI规范的演进，并不断推动UEFI采用的低门槛化。 UEFI成员管理采用分级制：发起者，贡献者和使用者。关于该分级，Welcome to Unified Extensible Firmware Interface Forum上有更详尽的描述。发起者一级包括：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 Spec中添加了安全基础设施部分的内容。 #PIWG和USWG 两个很重要的工作组分别是：PI工作组（The Platform Initialization Working Group，简称PIWG）是专门制定Spec中PI部分的工作组。UEFI规范工作组（The UEFI Specification Working Group，简称USWG）则是主要负责UEFI Spec推进工作的部门。下图展示了平台的布局以及这两组的大致构成：  再次强调一下，UEFI Spec 是关于OS，附加驱动（add-in driver）以及系统固件的规范。 操作系统和其他的高级软件能且只能通过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的飞速发展和全面普及， 它迎来了全新的挑战——嵌入式设备。尤其是消费类电子产品，每个用户的需求都不尽相同，单单嵌入式OS即时上电这一项，就有五花八门的要求。这些系统中多数都有其独特的固件和固件接口，且通常不能很好地适应PC固件生态系统模型。 该难题的核心在于：如何使嵌入式平台固件具有与传统模型类似的功能，比如例如不依赖于操作系统，可跨不同平台硬件扩展，如此一来，就能够减少开发时间并采用UEFI标准。 我们来看一下常规引导和优化/嵌入式引导有什么不同。从UEFI架构的观点来看，常规引导与优化引导间并没有设计差异。优化平台的性能也并不意味着一定要违反哪条设计规范。还应注意，符合UEFI规范，不意味着要实现其下所有的标准PC架构，而是对平台自身初始化必要的组件进行重新设计，使其符合UEFI规范（UEFI Spec 2.3中的第2章详细列举了符合UEFI的各种组件以及要求）。  #总结 希望阅读完本篇文章后读者能对UEFI论坛的运作有所了解，如果还能提升你对UEFI的兴趣，想去更深入的了解和学习，那我们将不胜荣幸。 转自https://zhuanlan.zhihu.com/p/25676417 标签: uefi 本作品采用 知识共享署名-相同方式共享 4.0 国际许可协议 进行许可。