基于 LinuxBoot 的云固件创新实践

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

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

产品采用UEFI Minplatform(MinimumPlatform的缩写)进行芯片初始化和最小化的平台初始化功能,将其它大部分传统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固件遇到的问题。下面分别简单介绍下这些方案的内容。

MinplatformMinplatform指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开发经验。

CoreBootCoreBoot的前身是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的替代选择。

LinuxBootLinuxBoot来源于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团队)

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

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

参考:字节跳动首发云固件,成功实现服务器LinuxBoot产品化落地