摘要：作者浪潮信息技術(shù)研發(fā)部吳海波背景月日，字節(jié)跳動(dòng)宣布全球首批基于云固件的服務(wù)器實(shí)現(xiàn)批量化上線(xiàn)運(yùn)行。指是提出的對(duì)目前固件的開(kāi)源優(yōu)化解決方案。已被基金會(huì)接受。

作者： 浪潮信息技術(shù)研發(fā)部 吳海波

背景

9 月 15 日，字節(jié)跳動(dòng)宣布全球首批基于LinuxBoot云固件的x86服務(wù)器實(shí)現(xiàn)批量化上線(xiàn)運(yùn)行【1】。該產(chǎn)品固件由字節(jié)跳動(dòng)系統(tǒng)技術(shù)與工程團(tuán)隊(duì)(STE團(tuán)隊(duì))、浪潮信息技術(shù)研發(fā)團(tuán)隊(duì)以及Intel聯(lián)合開(kāi)發(fā)實(shí)現(xiàn)。

產(chǎn)品采用UEFI Minplatform（Minimum?Platform的縮寫(xiě)）進(jìn)行芯片初始化和最小化的平臺(tái)初始化功能，將其它大部分傳統(tǒng)UEFI固件初始化的流程代碼移植到LinuxBoot模塊中進(jìn)行實(shí)現(xiàn)。通過(guò)精簡(jiǎn)UEFI 功能模塊，在底層固件模塊中引入Linux軟件生態(tài)，面向云平臺(tái)原生需求開(kāi)發(fā)云固件解決方案，使得服務(wù)器系統(tǒng)固件更易于開(kāi)發(fā)和維護(hù)。

將Linux生態(tài)引入到系統(tǒng)固件中是目前開(kāi)源固件技術(shù)發(fā)展的一種趨勢(shì)，本文簡(jiǎn)單介紹了浪潮服務(wù)器在開(kāi)源系統(tǒng)固件方面的創(chuàng)新實(shí)踐。

目前系統(tǒng)固件問(wèn)題

在服務(wù)器領(lǐng)域，經(jīng)常會(huì)聽(tīng)到“固件”這個(gè)名詞，什么是固件呢？

“固件”就是存儲(chǔ)在EEPROM或者FLASH中的程序。它是在電子硬件系統(tǒng)最基礎(chǔ)最底層的軟件，在系統(tǒng)上電后，首先要執(zhí)行的程序就是固件。固件負(fù)責(zé)完成硬件的初始化，讓電子設(shè)備系統(tǒng)處于一個(gè)正常的狀態(tài)，然后才能讓上層的操作系統(tǒng)或者應(yīng)用軟件正常使用。

對(duì)于服務(wù)器領(lǐng)域，BIOS是服務(wù)器最重要的固件，BIOS負(fù)責(zé)完成CPU、內(nèi)存和外設(shè)的初始化，將硬件系統(tǒng)的抽象信息報(bào)告給操作系統(tǒng)，操作系統(tǒng)才能正常使用硬件。

目前服務(wù)器的BIOS均采用UEFI/Tiano的方案[2]，但是隨著目前云服務(wù)和數(shù)據(jù)中心的快速發(fā)展，UEFI BIOS也逐漸顯露了一些問(wèn)題：

（1）隨著技術(shù)的發(fā)展，UEFI越來(lái)越復(fù)雜，門(mén)檻高，在UEFI專(zhuān)業(yè)領(lǐng)域的開(kāi)發(fā)人員相比其他軟件開(kāi)發(fā)而言非常稀少。

（2）目前大多都是服務(wù)器廠(chǎng)商在購(gòu)買(mǎi)BIOS軟件廠(chǎng)商的UEFI BIOS代碼基礎(chǔ)上進(jìn)行增強(qiáng)開(kāi)發(fā)。 不同BIOS軟件廠(chǎng)商提供代碼風(fēng)格和架構(gòu)差別很大，一個(gè)服務(wù)器廠(chǎng)商的UEFI　BIOS開(kāi)發(fā)人員需要熟悉多套代碼；另外，UEFI BIOS代碼結(jié)構(gòu)和內(nèi)容有時(shí)還會(huì)隨著服務(wù)器CPU的更新升級(jí)發(fā)生較大變動(dòng)；這些都增加了BIOS固件的開(kāi)發(fā)難度。

（3）由于UEFI BIOS固件中包含了服務(wù)器廠(chǎng)商和IBV（獨(dú)立BIOS）廠(chǎng)商的知識(shí)產(chǎn)權(quán)，所以大部分BIOS代碼都是閉源的，通過(guò)二進(jìn)制的形式分發(fā)給服務(wù)器廠(chǎng)商使用。閉源會(huì)帶來(lái)三方面的問(wèn)題：i) 如果BIOS固件出現(xiàn)問(wèn)題，只能讓廠(chǎng)商來(lái)解決，這可能延長(zhǎng)故障處理時(shí)間。ii) 由于代碼是閉源的，對(duì)客戶(hù)而言也隱藏著一些安全風(fēng)險(xiǎn)。Iii) 代碼閉源，也將導(dǎo)致用戶(hù)難以增添定制化功能，無(wú)法滿(mǎn)足當(dāng)前云環(huán)境下的快速迭代更新的需求。

綜上所述，目前UEFI生態(tài)環(huán)境面臨著開(kāi)發(fā)人員短缺，代碼不夠開(kāi)放，開(kāi)發(fā)難度大，隱藏著安全風(fēng)險(xiǎn)等問(wèn)題。

開(kāi)源固件解決方案

為解決當(dāng)前UEFI BIOS固件的問(wèn)題，尤其是針對(duì)當(dāng)前云環(huán)境下的應(yīng)用，目前開(kāi)源社區(qū)提出了多種優(yōu)化解決方案，包括Minplatform[3,4],CoreBoot[5]和LinuxBoot[6]等；主要是希望通過(guò)引入開(kāi)源的方式來(lái)解決和優(yōu)化目前UEFI BIOS固件遇到的問(wèn)題。下面分別簡(jiǎn)單介紹下這些方案的內(nèi)容。

Minplatform

Minplatform指Mininum Platform, 是Intel 提出的對(duì)目前UEFI固件的開(kāi)源優(yōu)化解決方案。如下圖1所示，Minplatform定義了平臺(tái)啟動(dòng)的多個(gè)BootStage，通過(guò)BootStage的配置實(shí)現(xiàn)了UEFI BIOS開(kāi)發(fā)過(guò)程中依據(jù)不同需求選擇配置相應(yīng)的功能模塊實(shí)現(xiàn)完整UEFI BIOS的最終解決方案。

圖1 Minplaform定義的多個(gè)BootStage

在具體的實(shí)現(xiàn)上，如圖2所示，Minplatform是依賴(lài)于UEFI Tiano EDK2[7]的開(kāi)源代碼，以搭積木的方式逐漸添加系統(tǒng)固件的功能，最終實(shí)現(xiàn)完整的BIOS固件。Minplatfom相比當(dāng)前全功能的UEFI BIOS而言，先是一個(gè)做減法的操作，能快速啟動(dòng)。它定義了UEFI　BIOS的最小平臺(tái)代碼；然后才做加法，根據(jù)不同需求來(lái)增加功能，繼而實(shí)現(xiàn)較完整的UEFI BIOS。通過(guò)這種方式有效的減少了UEFI固件開(kāi)發(fā)難度，增加功能代碼的復(fù)用，是對(duì)當(dāng)前UEFI BIOS固件開(kāi)發(fā)的一種優(yōu)化方案。

圖2 MinPlatform實(shí)現(xiàn)

由于Minplatform是基于UEFI Tiano EDK2的開(kāi)源實(shí)現(xiàn)，從BIOS代碼廠(chǎng)商那購(gòu)買(mǎi)UEFI BIOS，服務(wù)器廠(chǎng)商可以直接將功能代碼做簡(jiǎn)單移植就可以作為Minplatform。這種方案對(duì)目前服務(wù)器廠(chǎng)商而言影響最小，因?yàn)橐呀?jīng)積累了豐富的UEFI開(kāi)發(fā)經(jīng)驗(yàn)。

CoreBoot

CoreBoot的前身是LinuxBios，是Ron Minnich于上世紀(jì)發(fā)起的項(xiàng)目，一種Linux代碼風(fēng)格的開(kāi)源固件解決方案，跟UEFI固件架構(gòu)完全不同。CoreBoot的目標(biāo)是做最小的操作來(lái)完成硬件功能初始化，盡快的啟動(dòng)到操作系統(tǒng)中。

圖3 CoreBoot的發(fā)展

UEFI的平臺(tái)啟動(dòng)初始化流程為SEC->PEI->DXE->BDS->TLS->RT這幾個(gè)階段，其中SEC是指安全驗(yàn)證階段，PEI是指EFI前期初始化階段，DXE是驅(qū)動(dòng)執(zhí)行環(huán)境階段，BDS是指啟動(dòng)設(shè)備選擇階段，TSL是指操作系統(tǒng)加載前期階段，RT是指運(yùn)行時(shí)階段。

而CoreBoot將啟動(dòng)流程分為bootblock->romstage->ramstage->payload這幾個(gè)主要階段, 如下圖4所示。其中booblock是匯編編寫(xiě)的，主要為C運(yùn)行環(huán)境做準(zhǔn)備；romstage階段主要是來(lái)初始化內(nèi)存和一些早期初始化操作；ramstage階段主要執(zhí)行系統(tǒng)設(shè)備的初始化，比如pcie初始化，創(chuàng)建ACPI表等；到了payload階段CoreBoot的初始化操作實(shí)際上已經(jīng)完成，payload可以作為最終的Bootloader來(lái)加載操作系統(tǒng)。

圖4 CoreBoot平臺(tái)初始化流程

相比UEFI架構(gòu)的代碼，CoreBoot代碼跟Linux風(fēng)格類(lèi)似，完全開(kāi)源, 它結(jié)合CPU廠(chǎng)商的芯片初始化二進(jìn)制包（FSP/ATF/AGASA等）一起使用，來(lái)完成封閉的芯片初始化功能，同時(shí)可以集成Tianocore、LinuxBoot等各種payload，來(lái)滿(mǎn)足各種需求。

目前CoreBoot主要在Chromebook等PC機(jī)器上應(yīng)用，由于CoreBoot的開(kāi)源以及Linux風(fēng)格的代碼架構(gòu)的原因, 以及在Linux領(lǐng)域的人才優(yōu)勢(shì)，也在推進(jìn)支持使用CoreBoot作為服務(wù)器的UEFI BIOS的替代選擇。

LinuxBoot

LinuxBoot來(lái)源于NERF（Non-Extensible Reduced Firmware）項(xiàng)目，是用Linux作為固件的一部分的解決方案，它不是一個(gè)完整的固件方案，無(wú)法獨(dú)立完成所有的硬件初始化功能，必須依賴(lài)于UEFI 、CoreBoot等完成CPU和內(nèi)存初始化，然后使用Linux Kernel來(lái)完成外設(shè)初始化和啟動(dòng)操作系統(tǒng)的功能。

圖5 LinuxBoot架構(gòu)圖

對(duì)于當(dāng)前服務(wù)器固件解決方案UEFI BIOS而言，LinuxBoot主要是通過(guò)開(kāi)源的Linux Kernel來(lái)取代UEFI DXE和BDS階段的功能，比如通過(guò)Linux下的開(kāi)源driver來(lái)取代UEFI下的設(shè)備驅(qū)動(dòng)，用Linux完備的網(wǎng)絡(luò)功能取代UEFI的。UEFI結(jié)合LinuxBoot可以減少UEFI代碼和開(kāi)發(fā)難度。

LinuxBoot已被 Linux 基金會(huì)接受。目前在服務(wù)器領(lǐng)域，它作為固件部分的方案得到了許多廠(chǎng)商的支持，但是這種方案要求有較強(qiáng)的Linux開(kāi)發(fā)能力，否則難以享受LinuxBoot帶來(lái)的優(yōu)勢(shì)。

固件發(fā)展趨勢(shì)

雖然目前基于UEFI的BIOS系統(tǒng)固件還是絕對(duì)的主流，但是UEFI BIOS面臨的閉源、安全和開(kāi)發(fā)難問(wèn)題也是無(wú)法回避的問(wèn)題。尤其是對(duì)于具有大型數(shù)據(jù)中心的大型互聯(lián)網(wǎng)服務(wù)提供商來(lái)說(shuō)，如何將符合自己業(yè)務(wù)場(chǎng)景需求的功能添加到固件中，如何實(shí)現(xiàn)系統(tǒng)固件的快速開(kāi)發(fā)和維護(hù)，從而減少因?yàn)楣碳S護(hù)導(dǎo)致的停機(jī)時(shí)間，如何保證固件代碼的安全可靠, 如何具備系統(tǒng)固件開(kāi)發(fā)能力和掌控能力，都需要考慮。

相比服務(wù)器廠(chǎng)商，大型互聯(lián)網(wǎng)服務(wù)提供商，擁有大量的Linux方面的開(kāi)發(fā)人才，所以希望引入LinuxBoot和CoreBoot這些基于Linux或類(lèi)似的固件方案來(lái)增加在服務(wù)器固件上的技術(shù)掌控能力。另外通過(guò)開(kāi)源的固件解決方案，也能夠減少UEFI代碼中隱藏的代碼安全風(fēng)險(xiǎn)，加快服務(wù)器固件開(kāi)發(fā)，減少服務(wù)器系統(tǒng)固件的維護(hù)時(shí)間。

圖6 服務(wù)器固件 Bootloader各方案對(duì)比（引自字節(jié)跳動(dòng)STE團(tuán)隊(duì)）

這也要求服務(wù)器廠(chǎng)商需要提前了解這些客戶(hù)的需求，并與之深入合作來(lái)保持在未來(lái)固件發(fā)展中重要地位。在構(gòu)建智慧時(shí)代的“新基建”-智算中心的過(guò)程中，浪潮秉承著開(kāi)放標(biāo)準(zhǔn)、集約高效和普適普惠的理念，以穩(wěn)健、實(shí)干的態(tài)度，積極主動(dòng)地與用戶(hù)、以及上下游合作伙伴一道，共同推動(dòng)開(kāi)放計(jì)算生態(tài)健康有序的發(fā)展。

感謝黃家明、吳安、葉毓睿等對(duì)本篇文章的貢獻(xiàn)。