基于LinuxBoot的云固件创新实践_云技术

摘要：作者浪潮信息技术研发部吴海波背景月日，字节跳动宣布全球首批基于云固件的服务器实现批量化上线运行。指是提出的对目前固件的开源优化解决方案。已被基金会接受。

作者： 浪潮信息技术研发部 吴海波

背景

9 月 15 日，字节跳动宣布全球首批基于LinuxBoot云固件的x86服务器实现批量化上线运行【1】。该产品固件由字节跳动系统技术与工程团队(STE团队)、浪潮信息技术研发团队以及Intel联合开发实现。

产品采用UEFI Minplatform（Minimum Platform的缩写）进行芯片初始化和最小化的平台初始化功能，将其它大部分传统UEFI固件初始化的流程代码移植到LinuxBoot模块中进行实现。通过精简UEFI 功能模块，在底层固件模块中引入Linux软件生态，面向云平台原生需求开发云固件解决方案，使得服务器系统固件更易于开发和维护。

将Linux生态引入到系统固件中是目前开源固件技术发展的一种趋势，本文简单介绍了浪潮服务器在开源系统固件方面的创新实践。

目前系统固件问题

在服务器领域，经常会听到“固件”这个名词，什么是固件呢？

“固件”就是存储在EEPROM或者FLASH中的程序。它是在电子硬件系统最基础最底层的软件，在系统上电后，首先要执行的程序就是固件。固件负责完成硬件的初始化，让电子设备系统处于一个正常的状态，然后才能让上层的操作系统或者应用软件正常使用。

对于服务器领域，BIOS是服务器最重要的固件，BIOS负责完成CPU、内存和外设的初始化，将硬件系统的抽象信息报告给操作系统，操作系统才能正常使用硬件。

目前服务器的BIOS均采用UEFI/Tiano的方案[2]，但是随着目前云服务和数据中心的快速发展，UEFI BIOS也逐渐显露了一些问题：

（1）随着技术的发展，UEFI越来越复杂，门槛高，在UEFI专业领域的开发人员相比其他软件开发而言非常稀少。

（2）目前大多都是服务器厂商在购买BIOS软件厂商的UEFI BIOS代码基础上进行增强开发。 不同BIOS软件厂商提供代码风格和架构差别很大，一个服务器厂商的UEFI　BIOS开发人员需要熟悉多套代码；另外，UEFI BIOS代码结构和内容有时还会随着服务器CPU的更新升级发生较大变动；这些都增加了BIOS固件的开发难度。

（3）由于UEFI BIOS固件中包含了服务器厂商和IBV（独立BIOS）厂商的知识产权，所以大部分BIOS代码都是闭源的，通过二进制的形式分发给服务器厂商使用。闭源会带来三方面的问题：i) 如果BIOS固件出现问题，只能让厂商来解决，这可能延长故障处理时间。ii) 由于代码是闭源的，对客户而言也隐藏着一些安全风险。Iii) 代码闭源，也将导致用户难以增添定制化功能，无法满足当前云环境下的快速迭代更新的需求。

综上所述，目前UEFI生态环境面临着开发人员短缺，代码不够开放，开发难度大，隐藏着安全风险等问题。

开源固件解决方案

为解决当前UEFI BIOS固件的问题，尤其是针对当前云环境下的应用，目前开源社区提出了多种优化解决方案，包括Minplatform[3,4],CoreBoot[5]和LinuxBoot[6]等；主要是希望通过引入开源的方式来解决和优化目前UEFI BIOS固件遇到的问题。下面分别简单介绍下这些方案的内容。

Minplatform

Minplatform指Mininum Platform, 是Intel 提出的对目前UEFI固件的开源优化解决方案。如下图1所示，Minplatform定义了平台启动的多个BootStage，通过BootStage的配置实现了UEFI BIOS开发过程中依据不同需求选择配置相应的功能模块实现完整UEFI BIOS的最终解决方案。

图1 Minplaform定义的多个BootStage

在具体的实现上，如图2所示，Minplatform是依赖于UEFI Tiano EDK2[7]的开源代码，以搭积木的方式逐渐添加系统固件的功能，最终实现完整的BIOS固件。Minplatfom相比当前全功能的UEFI BIOS而言，先是一个做减法的操作，能快速启动。它定义了UEFI　BIOS的最小平台代码；然后才做加法，根据不同需求来增加功能，继而实现较完整的UEFI BIOS。通过这种方式有效的减少了UEFI固件开发难度，增加功能代码的复用，是对当前UEFI BIOS固件开发的一种优化方案。

图2 MinPlatform实现

由于Minplatform是基于UEFI Tiano EDK2的开源实现，从BIOS代码厂商那购买UEFI BIOS，服务器厂商可以直接将功能代码做简单移植就可以作为Minplatform。这种方案对目前服务器厂商而言影响最小，因为已经积累了丰富的UEFI开发经验。

CoreBoot

CoreBoot的前身是LinuxBios，是Ron Minnich于上世纪发起的项目，一种Linux代码风格的开源固件解决方案，跟UEFI固件架构完全不同。CoreBoot的目标是做最小的操作来完成硬件功能初始化，尽快的启动到操作系统中。

图3 CoreBoot的发展

UEFI的平台启动初始化流程为SEC->PEI->DXE->BDS->TLS->RT这几个阶段，其中SEC是指安全验证阶段，PEI是指EFI前期初始化阶段，DXE是驱动执行环境阶段，BDS是指启动设备选择阶段，TSL是指操作系统加载前期阶段，RT是指运行时阶段。

而CoreBoot将启动流程分为bootblock->romstage->ramstage->payload这几个主要阶段, 如下图4所示。其中booblock是汇编编写的，主要为C运行环境做准备；romstage阶段主要是来初始化内存和一些早期初始化操作；ramstage阶段主要执行系统设备的初始化，比如pcie初始化，创建ACPI表等；到了payload阶段CoreBoot的初始化操作实际上已经完成，payload可以作为最终的Bootloader来加载操作系统。

图4 CoreBoot平台初始化流程

相比UEFI架构的代码，CoreBoot代码跟Linux风格类似，完全开源, 它结合CPU厂商的芯片初始化二进制包（FSP/ATF/AGASA等）一起使用，来完成封闭的芯片初始化功能，同时可以集成Tianocore、LinuxBoot等各种payload，来满足各种需求。

目前CoreBoot主要在Chromebook等PC机器上应用，由于CoreBoot的开源以及Linux风格的代码架构的原因, 以及在Linux领域的人才优势，也在推进支持使用CoreBoot作为服务器的UEFI BIOS的替代选择。

LinuxBoot

LinuxBoot来源于NERF（Non-Extensible Reduced Firmware）项目，是用Linux作为固件的一部分的解决方案，它不是一个完整的固件方案，无法独立完成所有的硬件初始化功能，必须依赖于UEFI 、CoreBoot等完成CPU和内存初始化，然后使用Linux Kernel来完成外设初始化和启动操作系统的功能。

图5 LinuxBoot架构图

对于当前服务器固件解决方案UEFI BIOS而言，LinuxBoot主要是通过开源的Linux Kernel来取代UEFI DXE和BDS阶段的功能，比如通过Linux下的开源driver来取代UEFI下的设备驱动，用Linux完备的网络功能取代UEFI的。UEFI结合LinuxBoot可以减少UEFI代码和开发难度。

LinuxBoot已被 Linux 基金会接受。目前在服务器领域，它作为固件部分的方案得到了许多厂商的支持，但是这种方案要求有较强的Linux开发能力，否则难以享受LinuxBoot带来的优势。

固件发展趋势

虽然目前基于UEFI的BIOS系统固件还是绝对的主流，但是UEFI BIOS面临的闭源、安全和开发难问题也是无法回避的问题。尤其是对于具有大型数据中心的大型互联网服务提供商来说，如何将符合自己业务场景需求的功能添加到固件中，如何实现系统固件的快速开发和维护，从而减少因为固件维护导致的停机时间，如何保证固件代码的安全可靠, 如何具备系统固件开发能力和掌控能力，都需要考虑。

相比服务器厂商，大型互联网服务提供商，拥有大量的Linux方面的开发人才，所以希望引入LinuxBoot和CoreBoot这些基于Linux或类似的固件方案来增加在服务器固件上的技术掌控能力。另外通过开源的固件解决方案，也能够减少UEFI代码中隐藏的代码安全风险，加快服务器固件开发，减少服务器系统固件的维护时间。

图6 服务器固件 Bootloader各方案对比（引自字节跳动STE团队）

这也要求服务器厂商需要提前了解这些客户的需求，并与之深入合作来保持在未来固件发展中重要地位。在构建智慧时代的“新基建”-智算中心的过程中，浪潮秉承着开放标准、集约高效和普适普惠的理念，以稳健、实干的态度，积极主动地与用户、以及上下游合作伙伴一道，共同推动开放计算生态健康有序的发展。

感谢黄家明、吴安、叶毓睿等对本篇文章的贡献。