ServerReady項目技術(shù)白皮書-D

1、ServerReady項目技術(shù)白皮書執(zhí)行摘要本白皮書介紹了 ServerReady 項目，認證過程以及 Arm 的基于標準的系統(tǒng)開發(fā)方法。如果使用標準操作系統(tǒng)，這種方法不僅限于服務器，而且適用于其他用例，包括邊緣和客戶端設備。本文的目標受眾是基于 Arm 處理器和系統(tǒng)的開發(fā)人員和集成商。通過閱讀本文，您將了解 Arm 基于標準的開發(fā)方法以及如何通過 Arm ServerReady 項目來設計和認證系統(tǒng)。介紹為了設計一個對最終用戶“立即可用”的系統(tǒng)，并具有開箱即用地安裝和運行標準操作系統(tǒng)（例如 Windows， RHEL，VMWare 等）的能力，那么就必須遵循最低硬件和固件要求。對于 Arm

2、生態(tài)系統(tǒng)而言，服務器市場最先引發(fā)此需求的細分市場。Arm ServerReady 合規(guī)項目為服務器提供了這種“立即可行”的解決方案，使合作伙伴可以放心地部署 Arm 服務器。該項目基于行業(yè)標準，并附有合規(guī)性測試套件以及相應的認證過程。并非所有服務器都需要支持標準操作系統(tǒng)。例如，一些云服務提供商僅支持自己的 Linux 操作系統(tǒng)。但是，符合Arm ServerReady 項目的服務器將會減少操作系統(tǒng)需要的定制工作。其它細分市場也是如此。邊緣或客戶端 PC 系統(tǒng)為了“立即可用”這些標準操作系統(tǒng)，他們需要遵循與 Arm ServerReady 項目類似（如果不完全相同）的基于標準的方法。本白皮書介紹

3、了 ServerReady 項目和 Arm 基于標準的方法進行系統(tǒng)開發(fā)。本文還說明了參與這個項目的合作伙伴的認證過程。Arm ServerReady 計劃背景和歷史作為基于 Arm 的服務器 Neoverse CPU 正式發(fā)布的一部分，Arm ServerReady v1.0 認證是在 Arm TechCon 2018 上發(fā)布的。Arm ServerReady 是一個基于標準的合規(guī)計劃，依此允許合作伙伴有信心地部署 Arm 服務器。該計劃補充了服務器基本系統(tǒng)架構(gòu)（SBSA）和服務器基本啟動需求（SBBR）的早期版本，以及 Arm 服務器體系結(jié)構(gòu)合規(guī)性測試（ACS）。合作伙伴可以運行基于 ACS

4、 的測試組以核實其系統(tǒng)是符合 Arm ServerReady 的。Arm ServerReady 在 SBSA 和 SBBR 中建立了最小的硬件和固件需求，并且在 ACS 工具集提供了測試組參照SBSA/SBBR 的標準對系統(tǒng)測試。Arm ServerReady 計劃對于購買這些合規(guī)性產(chǎn)品給予了價值產(chǎn)業(yè)鏈；這些產(chǎn)品具有兼容性和互用性，并且在全球 Arm 生態(tài)系統(tǒng)中擁有廣泛可選范圍。Arm ServerReady 保證了基于 Arm 的服務器的開箱即用， 提供了操作系統(tǒng)和軟件的無縫的互操作性。遵守 Arm ServerReady 之條款和條件的合規(guī)系統(tǒng)會被授予合規(guī)性認證。Arm ServerRe

5、ady 計劃涉及到：一套合規(guī)性測試：這些測試覆蓋了 Arm 標準規(guī)范，即 SBSA 和 SBBR。這些測試也包含了啟動標準操作系統(tǒng)和收集啟動日志。認證過程：合作伙伴自行或者在 Arm 支撐團隊的幫助下運行合規(guī)性測試。Arm 幫助調(diào)試發(fā)現(xiàn)的問題。在測試成功完成之后，認證將被提供。市場營銷材料一旦通過認證程序，合作伙伴可以使用 ServerReady 標識作為其產(chǎn)品推廣的一部分。我們也在Arm 開發(fā)者網(wǎng)站上主持存放了合作伙伴的標識。/architectures/platformdesign/server-systems/serverready-partners-and- supporters。Fi

6、gure 1 Arm ServerReady 1.0 Logo有關(guān)Arm ServerReady計劃的更多信息，和現(xiàn)在合作伙伴和支持者的清單，訪問Arm ServerReady網(wǎng)址： /architectures/platform-design/server-systemsArm 基于標準的方法Arm 架構(gòu)支持各種生態(tài)系統(tǒng)的設備，范圍從嵌入式和移動設備，到自動駕駛，工業(yè)部件和基礎設施服務器?；A設施空間也是多種多樣的，覆蓋到物聯(lián)網(wǎng)網(wǎng)關(guān)，邊緣服務器，云端和企業(yè)數(shù)據(jù)中心。盡管多樣性是一件好事，但不可控的多樣性是有問題的，特別是對于服務器。服務器與嵌入式設備不同。服務器是開放式系統(tǒng)，需要與其他服務器

7、和 IT 設備在多元化的環(huán)境中被部署，配 置和管理。服務器市場是典型的橫向市場，沒有一個單獨的廠商可以擁有從硬件到操作系統(tǒng)的整個產(chǎn)業(yè)鏈。服務器需要支持現(xiàn)成的企業(yè)級操作系統(tǒng)。服務器客戶習慣于開箱即用的經(jīng)驗，以此他們能夠從包裝箱中拿出服務器并能夠輕易的配置操作系統(tǒng)。這其中常常包括了早于芯片的操作系統(tǒng)，比如一個操作系統(tǒng)的現(xiàn)有和早期版本。在這個領(lǐng)域，客制化操作系統(tǒng)在指定的芯片上工作是典型的不可行的選擇。工業(yè)標準為硬件和固件提供了通用規(guī)則，以使能支持這些標準的操作系統(tǒng)。他們和生態(tài)系統(tǒng)中的參與者們創(chuàng)建了一個契約，提供了一個互用性的基礎框架。生態(tài)系統(tǒng)中的參與者被期望遵守這個共同的基線，與此同時在操作系統(tǒng)之上

8、，參與者們?nèi)匀荒軌騽?chuàng)新以提供差異化和增值的產(chǎn)品給付他們的客戶。對于數(shù)據(jù)中心，邊緣計算和云部署的成功，這個基于標準的系統(tǒng)設計基礎是關(guān)鍵的。但是，這個方案并不局限于這些場景的部署，它是可擴展的，并且可以采用在其他需要支持開箱即用的標準操作系統(tǒng)的細分領(lǐng)域。Arm 基于標準的方案集中在四個方面 (見圖 2）:Figure 2: Arm Standards-based Approach合作 (Collaboration): Arm 采用協(xié)作流程，包括 Arm 服務器生態(tài)系統(tǒng)中的公司。這些公司共同的組成了Arm 服務器咨詢委員會 (ServerAC), 成員來自于原始設備制造商(OEMs), 原始設計制造

9、商(ODMs), 芯片提供商(SiPs), 操作系統(tǒng)廠商(OSVs), 軟件和固件廠商(ISVs and IBVs), 云服務提供商(CSPs)和其他硬件和 IP 廠商。創(chuàng)建 Arm 標準：包括 SBBA 和 SBBR，另外的其他標準，比如電源管理接口(Power State Coordination Interface, PSCI), SMC 呼叫協(xié)定(SMCCC)以及 AMBA 協(xié)議，AMBA 是一個免費試用的開源標準，用來作為片上系統(tǒng)功能模塊的互連和管理的總線協(xié)議。參與工業(yè)標準：在各種工業(yè)標準的組織和團體中，Arm 積極的參與和提供了領(lǐng)導力，以確保這些標準和Arm 架構(gòu)的兼容性。其中包括

10、了例如 UEFI 論壇，PCI 工作組(PCI SIG)，分布式管理任務組(DMTF), 開放計算項目(OCP), 可信計算組織(TCG), CCIX 聯(lián)盟 和 CXL 聯(lián)盟，以及其他。支持開源軟件：Arm 支持開源的軟件和固件項目以幫助加速 Arm 服務器的開發(fā)和采用。這包括了可信固件(Trusted Firmware)，TianoCore，Linux Kernel 和 OpenBMC。Arm 服務器咨詢委員會 (ServerAC)通過 Arm 服務器咨詢委員會，Arm 生態(tài)系統(tǒng)合作創(chuàng)建服務器標準。這個組織包含了服務器生態(tài)系統(tǒng)中的公司，其中包括原始設備制造商(OEMs), 原始設計制造商(O

11、DMs), 芯片提供商(SiPs), 操作系統(tǒng)廠商(OSVs), 軟件和固件廠商(ISVs and IBVs), 云服務提供商(CSPs)和其他硬件和 IP 廠商。委員會通過各種方式溝通，包括電子郵件，定期的電話會議和一年兩次的聚會。與該組織通信的電子郵件可以發(fā)送至：內(nèi)容可公布至社區(qū)的郵件可以發(fā)送至： HYPERLINK mailto:armserverac-discuss armserverac-discuss 私信至 Arm 的郵件可以發(fā)送至： HYPERLINK mailto:armserverac-request armserverac-requestArm 服務器咨詢委員會開發(fā)流程A

12、rm 服務器咨詢委員會使用 Mantis Issue tracker (圖 3)來開發(fā)規(guī)格說明書和跟蹤問題，建議和需求。Arm 服務器咨詢委員會成員可以通過 訪問數(shù)據(jù)庫。任何 Arm 服務器咨詢委員會成員可以提交需求。提出的問題在委員會例會上討論。一旦達成共識，改動會被整合進規(guī)格說明書。Figure 3: ServerAC Mantis DatabaseArm 服務器咨詢委員會開發(fā)流程描述如下：該流程往往開始于合作伙伴和 Arm 的私有討論，提出一個問題或者改動需求。不過，這種討論也可以開始于Arm 服務器咨詢委員會成員的公開交流；針對一版可支持的規(guī)格說明，在 Arm 服務器咨詢委員會 Man

13、tis 上提交一個工程改進需求(ECR)。 ECR 包括問題敘述，改動理由和需求描述。ECR 最終會在 Arm 和其他委員會成員的驅(qū)動下更新，包含了一份關(guān)于規(guī)格說明書改動的建議；ECR 在 Arm 服務器咨詢委員會社區(qū)內(nèi)討論，并根據(jù)從所有成員處收集到的反饋作出改動；一旦 Arm 服務器咨詢委員會批準了該 ECR，Arm 將該改動整合進規(guī)格說明書，并在說明書下一版本發(fā)布的時候使之有效；Arm 服務器標準基礎服務器系統(tǒng)架構(gòu)(SBSA)Arm 架構(gòu)覆蓋廣泛領(lǐng)域的產(chǎn)品，橫跨許多市場細分，從嵌入式控制，到移動端，到服務器。基礎系統(tǒng)架構(gòu)(BSA)提供針對給定產(chǎn)品類型或者市場細分的硬件要求。該要求(SBSA

14、)想要確保標準軟件或者操作系統(tǒng)在合規(guī)于 BSA 的機器上正確運行?；A服務器系統(tǒng)架構(gòu)(SBSA)是針對服務器的基礎系統(tǒng)架構(gòu)。基礎服務器系統(tǒng)架構(gòu)(SBSA)提供了幾種合規(guī)標準。每一個標準符合一組需求在：處理器特點存儲子系統(tǒng)特點中斷處理器(GIC)和系統(tǒng)內(nèi)存管理單元(SMMU)特點PCIe 集成特點其他外設(USB, SATA)的基本標準安全特點電源語義這些標準表現(xiàn)了隨著時間的推移規(guī)格說明書的演進，隨著新架構(gòu)的到來，新的標準被加入。通常每個標準包含了之前標準的全部要求。舉例，SBSA compliance Level 5 是根據(jù) Armv8.4-A 架構(gòu)的新特點加入的，而未來的 SBBR Leve

15、l 6 將根據(jù) Armv8.5-A 架構(gòu)的改動。服務器基本啟動要求(SBBR)運行在標準服務器硬件上的操作系統(tǒng)需要標準的固件接口，以保證正確地啟動和運行。服務器基本啟動要求(SBBR)文檔描述了這些基于 Arm 的基礎結(jié)構(gòu)片上系統(tǒng)的固件需求。與基礎服務器系統(tǒng)架構(gòu)(SBSA)一起，服務器基本啟動要求(SBBR)提供了一套基于構(gòu)建 Arm 服務器及其固件的方法的標準。服務器基本啟動要求(SBBR) 既涵蓋了工業(yè)標準也涵蓋了 Arm 特定的標準，詳見圖 5。特別要說明的，服務器基本啟動要求(SBBR)包含了覆蓋以下標準的需求：UEFI SpecificationACPI SpecificationS

16、MBIOS SpecificationArm Specifications (PSCI, SMCCC, TF-A, etc.)Figure 5: SBBR firmware standards服務器基本啟動要求(SBBR)意在提供與基于標準的開源固件項目提供互用性，以供參考實現(xiàn)。這包括：TianoCore EDK2 ( https:/ HYPERLINK / )Trusted Firmware-A (https:/ HYPERLINK / )服務器基本安全指南 (SBSG)對于服務器系統(tǒng)，平臺安全性越來越重要。服務器基本安全指南 (SBSG) 特別地提出了基于 Arm SBSA 和 SBBR

17、標準的 Armv8 服務器的平臺安全性。該指南提供了需求和指導，以支持維護 Arm 服務器平臺層完整性和支持對平臺狀 態(tài)完整性的安全認證。平臺構(gòu)成了系統(tǒng)的基礎，因此平臺完整性本質(zhì)上就是系統(tǒng)總體的完整性。如果任何硬件或者固件 (代碼或者數(shù)據(jù))組件暴露了，那么整個系統(tǒng)的安全性(私密性，完整性，可用性)可能就是暴露了。服務器基本安全指南(SBSG)詳細說明了對固件和硬件的需求和指導。幫助平臺完整性的指導的關(guān)鍵區(qū)域包括:固件和關(guān)鍵數(shù)據(jù)的保護。 可變的固件和關(guān)鍵數(shù)據(jù)必須是可更新的，其更新是被授權(quán)的和可驗證的。固件和關(guān)鍵數(shù)據(jù)損壞的探測。 可變的固件和關(guān)鍵數(shù)據(jù)必須是署名的，由此其可以在啟動時被驗證，以形成一

18、個來自于不可變的硬件根信任的信任鏈。第一條指令完整性。在片上系統(tǒng)主機或者其他系統(tǒng)組件上運行的第一條可變固件指令必須是被不可變的引導程序調(diào)用之前被認證的。TPM2.0 集成和基于 TPM 的啟動，提供一個對平臺狀態(tài)安全地認證的方法。UEFI 安全指導硬件需求。有助于實現(xiàn)基于固件的安全性需求的硬件需求硬件需求。有關(guān)安全內(nèi)存的硬件需求服務器基礎管理需求(SBMR)服務器系統(tǒng)管理需求需要一個標準化通用能力的基礎，以此滿足服務器基礎用戶的期望。產(chǎn)品仍然可以存在由構(gòu)建在標準化基線之上的功能帶來的差異化，這種差異化給終端用戶提供了真正的價值增值。來自 Arm 的服務器基礎管理需求(SBMR)是一個新標準，提

19、供了路徑使得 Arm 服務器和普遍的工業(yè)標準系統(tǒng)管理規(guī)格具有互通性。服務器基礎管理需求的規(guī)格說明書是在 Arm 服務器咨詢委員會工業(yè)合作伙伴和社區(qū)成員的合作下共同開發(fā)的。的服務器基礎管理需求(SBMR)規(guī)格說明書涵蓋的可管理性標準的用法如圖 6 所示，其中包括了：Redfish接口分布式管理工作組(DMTF) 平臺層數(shù)據(jù)模型(PLDM)管理組件傳輸協(xié)議(MCTP)智能平臺管理接口(IPMI)OCP 相關(guān)管理標準與 SBSA，SBBR 和 SBSG 一起，服務器基礎管理需求(SBMR)提供了一套基于標準的方法， 基于此方法構(gòu)建 Arm服務器及其固件和服務器管理能力。Figure 6: SBMG

20、compliant server management SBMR 開發(fā)的目的在于匹配為參考實現(xiàn)的開源項目，包括：OpenBMC (https:/ HYPERLINK /) /)OpenRMC (https:/ HYPERLINK /wiki/Hardware_Management/Open_RMC) /wiki/Hardware_Management/Open_RMC)架構(gòu)合規(guī)性測試(ACS)在 Arm，我們遵循這樣的聲明: “沒有不需要驗證的規(guī)格說明書”。這是從 Arm 各種各樣的合規(guī)計劃中認識到的，這些合規(guī)程序幫助開發(fā)者確保他們的硬件是完全與 Arm 架構(gòu)規(guī)格合規(guī)的。在同樣的精神下，Arm

21、 創(chuàng)造了架構(gòu)合規(guī)性測試(ACS)以對 SBSA 和 SBBR 驗證。架構(gòu)合規(guī)性測試(ACS)是 Arm ServerReady 程序的基本組件，它涵蓋到:SBSA 硬件需求SBSA CPU 性能SBSA 定義的系統(tǒng)組件針對 PCIe 集成的 SBSA 規(guī)則基于 PCIe 的規(guī)格說明書基于標準操作系統(tǒng)標準模式驅(qū)動SBBR 定義的固件要求基于 UEFI SCT 的 UEFI 測試基于 FWTS 的 ACPI 測試SMBIOS 測試，目的于保證標準軟件Figure 7: ACS Test Suite Components該測試組在 GitHub 并且是開源的，用自由許可的 Apachev2 許可證。

22、SBSA 架構(gòu)合規(guī)性測試組：(/ARM-software/sbsa-acs)SBSA 架構(gòu)合規(guī)性測試組(ACS)是一個自檢查的，可移植的基于 C 語言的測試組合。該測試組包含了一組由 SBSA 給出的固定行為的實例，因此實現(xiàn)者可以此驗證他們正確的理解了這些行為。測試中的絕大部分都是通過執(zhí)行 SBSA UEFI Shell 應用而運行在 UEFI Shell 中的。少數(shù)測試的運行要通過執(zhí)行 SBSA ACS Linux 應用，這取決于 SBSA ACS Linux 內(nèi)核模塊。企業(yè)服務器架構(gòu)測試合規(guī)性測試組 (/ARM-software/armenterprise-acs)Arm 企業(yè)服務器架構(gòu)測

23、試合規(guī)性測試組 ACS 包含了一組由企業(yè)服務器系統(tǒng)規(guī)格書(例如 SBSA， SBBR 等等)給出的固定行為的實例，因此實現(xiàn)者可以此驗證他們正確的理解了這些行為。ACS 交付以源形式交付測試，帶著一個創(chuàng)建腳本，創(chuàng)建的輸出是一個可啟動的 Linux UEFI Validation (LUV) 操作系統(tǒng)鏡像，該鏡像可以運行所有規(guī)格書需要的測試。最新版 ACS 是 v2.3。ACSv.16 是與 ServerReady v1.0 相對應。其測試 SBSAv3.1 和 SBBRv1.0 的合規(guī)性。由此， Arm 和合作伙伴合作將其推薦到 SBSAv6.0 和 SBBRv1.2. Arm 也發(fā)布了 SBS

24、Gv1.0. 此外，Arm 正在做 SBMR?？梢云谕氖?，Arm ServerReady 程序未來的工具版本將使用未來服務器更新的標準。5.1 Arm ServerReady 參與者及其責任正如其他細分市場，服務器生態(tài)系統(tǒng)是復雜的，包含著許多廠商(見圖 8)。Figure 8: Arm Server Ecosystem Relationships并不是所有參與者與其他參與者有直接的互動；一個操作系統(tǒng)廠商維護其操作系統(tǒng)與標準合規(guī)并保持最新。但是一個操作系統(tǒng)廠商不能核對所有可能的系統(tǒng)；合規(guī)性測試工具可以幫助廠商核對其從其他廠商輸入：OEMs/ODMs 可以核對芯片提供商的硬件是否與 SBSA 硬

25、件要求合規(guī)；OS 廠商可以核對 OEMs/ODMs 系統(tǒng)是否與 SBSA 硬件要求和 SBBR 固件要求合規(guī)； 參考圖 9 和圖 10 展示的 Arm ServerReady 角色和責任和認證流程。Figure 9: Arm ServerReady roles and responsibilitiesFigure 10: ServerReady certification flowArm 和芯片提供商，ODMs, OEMs 和 BIOS 廠商一起參與運行 ServerReady 合規(guī)性測試集測試。特使由 Arm 架構(gòu)團隊開發(fā)。 Arm 架構(gòu)團隊也和 Arm 服務器咨詢委員會社區(qū)合作開發(fā)規(guī)格說明

26、書。Arm 在臺北設有支持團隊可以幫忙運行測試并調(diào)試問題。Arm 也有一個認證團隊評估測試結(jié)果并運轉(zhuǎn)認證流程。一旦測試通過，Arm 市場團隊授予認證并幫助傳播。結(jié)論本白皮書描述了 Arm ServerReady 程序，其組件及流程。此外，文章描述了 Arm 基于標準的方法和 Arm 特定的標準，這些標準奠定了 Arm ServerReady 程序的基礎。有關(guān)更加細節(jié)的描述可以在 Arm ServerReady 網(wǎng)頁找到，網(wǎng)址：/architectures/platform-design/server-systems.Arm 在臺灣地區(qū)，印度，美國和英國擁有團隊可以幫助您成為 ServerReady 的客戶。我們還與 OpenGCC 合作，在中國推動 ServerReady 的支持工作。聯(lián)系我們以獲取更多信息： HYPERLINK mailto:arm.serverreadyprog arm.serverreadyprog.Arm ServerReady 程序創(chuàng)建的可以被輕易的用于其他細分市場，比如邊緣端和個人電腦市場，如果這些系統(tǒng)只需要標準的操作系統(tǒng)就能工作。我們期望和生態(tài)系統(tǒng)合作為這些細分市場建立必要的標準和認證流程。術(shù)語表 (Glossary)本文檔使用到以下術(shù)語和縮寫： 術(shù)語意思ACSArchite