隨著 ICT 技術(shù)的發(fā)展，單 SOC 算力可以承擔(dān)更多業(yè)務(wù)，網(wǎng)絡(luò)帶寬拓展及低時延、區(qū)分服務(wù)等特性使得業(yè)務(wù)部署、功能分配更加靈活，比如 : 感知、融合、規(guī)劃、控制、執(zhí)行可分離解耦，汽車業(yè)務(wù)功能可分可合、可軟件定義。電子電氣架構(gòu)從分布式架構(gòu)到域集中式架構(gòu)，再到中央集中式架構(gòu)轉(zhuǎn)變，分散的 ECU功能集成到域控制器甚至車載中央計算機(jī)，這就是多域融合。

汽車電子底層硬件不再是由單一芯片提供簡單的邏輯計算，而是需要復(fù)雜的多核 SoC 芯片提供更為復(fù)雜控制邏輯以及強(qiáng)大的算力支持。但是多域業(yè)務(wù)具有不同的技術(shù)需求，比如座艙域 IVI 業(yè)務(wù)強(qiáng)調(diào)交互體驗、應(yīng)用生態(tài)豐富，比較適合的操作系統(tǒng)是 Android；儀表盤、輔助駕駛有實(shí)時性、可靠性要求，操作系統(tǒng)傾向于 RTLinux、RTOS；智駕域強(qiáng)調(diào)大算力融合感知、推演規(guī)劃，也有實(shí)時性、可靠性要求，也會選擇 RTLinux、RTOS。在域融合的同時，要保證關(guān)鍵業(yè)務(wù)的安全可靠，也要考慮應(yīng)用生態(tài)的可持續(xù)性兼容，這就需要有資源隔離技術(shù)來支撐在同一 SOC 上切分資源，可并發(fā)運(yùn)行多種操作系統(tǒng)，保障互不干擾。

資源隔離技術(shù)有多種，從硬件底層逐層向上包括硬件隔離、虛擬化隔離、容器隔離、進(jìn)程隔離等。硬件隔離的隔離性最好，單隔離域的性能、安全可靠性最好，但靈活性、可配置性差，不能實(shí)現(xiàn)硬件共享，導(dǎo)致整個系統(tǒng)的資源利用率差，不能充分達(dá)到軟件定義汽車的目標(biāo)。容器隔離、進(jìn)程隔離可以更輕量級地實(shí)現(xiàn)業(yè)務(wù)隔離，但還是在同一個操作系統(tǒng)內(nèi)，存在著資源干擾、相互安全攻擊的隱患，并且無法支持異構(gòu)操作系統(tǒng)業(yè)務(wù)域融合，影響傳統(tǒng)業(yè)務(wù)繼承，不利于生態(tài)發(fā)展。在眾多的資源隔離技術(shù)中，虛擬化是安全可靠、彈性靈活的優(yōu)選方案，是軟件定義汽車的重要支撐技術(shù)。典型應(yīng)用場景如圖 1 所示：



圖1 虛擬化典型應(yīng)用場景

技術(shù)形態(tài)

Hypervisor 直譯即 “超級監(jiān)督者” ，也稱為虛擬機(jī)監(jiān)控程序（VMM）。如圖 2 所示，Hypervisor處于 SoC 硬件平臺之上，將實(shí)體資源（如 CPU、內(nèi)存、存儲空間、網(wǎng)絡(luò)適配器、外設(shè)等 ) 轉(zhuǎn)換為虛擬資源，按需分配給每個虛擬機(jī)，允許它們獨(dú)立地訪問已授權(quán)的虛擬資源。Hypervisor 實(shí)現(xiàn)了硬件資源的整合和隔離，使應(yīng)用程序既能共享 CPU 等物理硬件，也能依托不同的內(nèi)核環(huán)境和驅(qū)動運(yùn)行，從而滿足汽車領(lǐng)域多元化應(yīng)用場景需求。



圖2 虛擬化在系統(tǒng)中的位置

在汽車領(lǐng)域，Hypervisior 主要完成以下任務(wù)：

CPU 虛擬化：為虛擬機(jī)提供 VCPU 資源和運(yùn)行環(huán)境；

內(nèi)存虛擬化：負(fù)責(zé)為其自身和虛擬機(jī)分配和管理硬件內(nèi)存資源；

中斷虛擬化：發(fā)生中斷和異常時，按需將中斷和異常路由到虛擬機(jī)進(jìn)行處理；

虛擬機(jī)設(shè)備模擬：根據(jù)需求創(chuàng)建虛擬機(jī)可以訪問的虛擬硬件組件；

硬件支持 BSP：提供 Hypervisor 在 SoC 上運(yùn)行的板級支持包，如串口驅(qū)動；

虛擬機(jī)資源配置：對虛擬機(jī)的 CPU，內(nèi)存，IO 外設(shè)等資源進(jìn)行配置和管理；

虛擬機(jī)通信：為虛擬機(jī)提供 IPC，共享內(nèi)存等通信機(jī)制。

虛擬機(jī)調(diào)度：為虛擬機(jī)提供優(yōu)先級和時間片等調(diào)度算法；

虛擬機(jī)生命周期管理：創(chuàng)建，啟動和停止虛擬機(jī)；

虛擬機(jī)調(diào)測服務(wù)：提供控制臺，日志等調(diào)試功能；

在汽車領(lǐng)域，Hypervisior 還面臨如下挑戰(zhàn)：

輕量高效。Hypervisor 在帶來軟件定義的靈活性的同時，也導(dǎo)致了軟件棧層次增加，不可避免會有性能損耗。汽車領(lǐng)域的成本敏感特性，注定了降低 CPU、存儲、網(wǎng)絡(luò)、GPU 等外設(shè)性能損耗的需求貫穿整車項目始終，因此 Hypervisor 的輕量和高效十分重要；

安全可靠。相較于互聯(lián)網(wǎng)領(lǐng)域看重的資源動態(tài)分配和閑置利用，汽車領(lǐng)域更看重 Hypervisor 的實(shí)時性、可靠性、安全性；

便捷適配。在汽車領(lǐng)域，芯片類型和操作系統(tǒng)豐富多樣，嵌入式虛擬化的一大特點(diǎn)就是異構(gòu)，Hypervisor 必須具備快速適配不同的底層硬件和上層操作系統(tǒng)的能力。

技術(shù)發(fā)展趨勢

2.1 云邊端虛擬化關(guān)鍵技術(shù)差異化

虛擬化技術(shù)最早可以追溯到 20 世紀(jì) 60 年代，IBM 開發(fā)了虛擬機(jī)監(jiān)視器軟件，將計算機(jī)硬件虛擬分割成一個或多個虛擬機(jī)，可支持多名用戶對大型計算機(jī)的同時、交互的訪問。隨著 21 世紀(jì)通用服務(wù)器算力的提升，云計算蓬勃發(fā)展，作為底層支撐技術(shù)的云虛擬化也快速迭代演進(jìn)。后來算力從云、邊、端逐步下沉，也就伴隨著出現(xiàn)了邊緣虛擬化、端側(cè)嵌入式虛擬化。它們的典型架構(gòu)、關(guān)鍵技術(shù)需求如圖 3 所示。



圖3 云邊端虛擬化典型架構(gòu)及關(guān)鍵技術(shù)需求

（1） 云側(cè)虛擬化

其特點(diǎn)是硬件平臺基本同構(gòu)，大量節(jié)點(diǎn)構(gòu)成集群，架構(gòu)設(shè)計以吞吐能力優(yōu)先，要支持多業(yè)務(wù)并發(fā)，虛擬化要滿足集群負(fù)載均衡、節(jié)能降耗的資源調(diào)度策略，在進(jìn)行跨節(jié)點(diǎn)虛擬機(jī)調(diào)配過程中，要保證業(yè)務(wù)無中斷遷移。虛擬機(jī)故障時，要能保證從檢查點(diǎn)恢復(fù)，減少業(yè)務(wù)損失，虛擬機(jī)要能支持 CPU 算力、內(nèi)存、存儲空間、網(wǎng)絡(luò)、GPU、外設(shè)等能力的彈性擴(kuò)展，還要能超分配，以便提升數(shù)據(jù)中心的運(yùn)營收益。

（2） 邊側(cè)虛擬化

是在某些特定業(yè)務(wù)的邊緣節(jié)點(diǎn)上，采用通用 ICT 架構(gòu)，支持多種業(yè)務(wù)的動態(tài)部署，典型如 SDN、NFV。其技術(shù)特點(diǎn)是：基于通用硬件平臺、行業(yè)定制的管理部署平臺，實(shí)現(xiàn)軟硬解耦、軟件定義，多功能節(jié)點(diǎn)按需部署、彈性組網(wǎng)，一般會采用 1+1 或者 N+1 冗余方式保證業(yè)務(wù)高可用，在 5G 電信網(wǎng)元中需要考慮 5G 業(yè)務(wù)端到端實(shí)時性，Hypervisor、虛擬機(jī)、通信協(xié)議棧都需要設(shè)計考慮。

（3） 端側(cè)虛擬化

端側(cè)典型特點(diǎn)是異構(gòu)，其芯片架構(gòu)、處理能力都差異較大。一般是單芯片方案，不存在著集群、主備間的虛擬機(jī)遷移，因此比較強(qiáng)調(diào)高安全、單節(jié)點(diǎn)高可靠，比如會有功能安全 ASIL 等級要求，同時對于實(shí)時性、確定性有更強(qiáng)的要求。另外，端側(cè)資源更加有限、成本更敏感，因此要求 Hypervisor 輕量化、高性能。

2.2 虛擬化模型趨勢

Hypervisor 可以劃分為兩大類，一類是 Type1 裸機(jī)型，Hypervisor 直接運(yùn)行在硬件設(shè)備上的，也叫做 Bare-Metal Hardware Virtualization（裸機(jī)虛擬化環(huán)境）；一類是 Type2 主機(jī)托管型，也叫做 Hosted Virtualization （主機(jī)虛擬化環(huán)境）。圖 4 展示了兩種 Hypervisor 的分層架構(gòu)。



圖4 Type1和Typer2型Hypervisor

Type2 型 Hypervisor 需要借助宿主操作系統(tǒng)來管理 CPU、內(nèi)存、網(wǎng)絡(luò)等資源，由于 Hypervisor 和硬件之間存在一個宿主操作系統(tǒng)，Hypervisor 及 VM 的所有操作都要經(jīng)過宿主操作系統(tǒng)，所以就不可避免地會存在延遲、性能損耗，同時宿主操作系統(tǒng)的安全缺陷及穩(wěn)定性問題都會影響到運(yùn)行在之上的 VM（虛擬機(jī)），所以 , Type-2 型 Hypervisor 主要用于對性能和安全要求不高的場合，比如 : 個人 PC 系統(tǒng)。

Type1 型的 Hypervisor 不依賴主機(jī)操作系統(tǒng)，其自身具備操作系統(tǒng)的基礎(chǔ)功能。設(shè)計上更簡潔，直接運(yùn)行于硬件之上，整體代碼量和架構(gòu)更為精簡，對內(nèi)存和存儲資源要求更少，可滿足自動駕駛車控系統(tǒng)功能安全等級要求，也具備進(jìn)行形式化驗證的條件。所以汽車操作系統(tǒng)更適合使用 Type 1 型 Hypervisor。

隨著微內(nèi)核操作系統(tǒng)技術(shù)的發(fā)展，很多基于微內(nèi)核操作系統(tǒng)設(shè)計的 Hypervisor 依賴的 Host OS 已經(jīng)非常精簡，只包括基本的、不變的功能，如 : CPU 調(diào)度和內(nèi)存管理，設(shè)備驅(qū)動和其他可變組件處于內(nèi)核之外，這類 Hypervisor 應(yīng)當(dāng)歸于 Type1、還是 Type2，業(yè)內(nèi)存在分歧?？傮w來說，微內(nèi)核 Hypervisor 更小、更穩(wěn)定、擴(kuò)展性更好，更適合用于嵌入式虛擬化場合。

2.3 Hypervisor 與虛擬機(jī)協(xié)作技術(shù)路線

（1） 全虛擬化

最初的虛擬化是通過軟件模擬具有完整硬件系統(tǒng)功能的、運(yùn)行在一個隔離環(huán)境中的計算機(jī)系統(tǒng)，即通過軟件虛擬硬件設(shè)備提供給 GuestOS 使用，優(yōu)點(diǎn)是 GuestOS 不感知外部真實(shí)硬件環(huán)境、不用改動。由于 Guest OS 中每次訪問全虛擬化硬件都要陷入到 Hypervisor 中，直接導(dǎo)致該方式虛擬的硬件性能較差，一般只用來模擬如串口等比較簡單的硬件。對硬件的模擬可以在 Hypervisor 中直接模擬，也可以將請求傳遞到其他 VM 中進(jìn)行模擬，如在某一 VM 中通過 QEMU 進(jìn)行模擬。

（2） 硬件輔助虛擬化

Intel 最早提出硬件輔助虛擬化技術(shù)，由硬件直接提供共享功能，支持多 GuestOS 的訪問，減少軟件虛擬技術(shù)帶來的延時和性能損耗。Intel 提出了分別針對處理器 & 內(nèi)存、IO、網(wǎng)絡(luò)的 Intel VT-x、Intel VT-d 和 Intel VT-c 技術(shù)等。隨著 ARM 算力提升，從移動端向邊緣、甚至云算力中心發(fā)展，ARM 也在不斷增強(qiáng)其硬件輔助虛擬化技術(shù)，比如 stage 2 頁表轉(zhuǎn)換、虛擬異常等。

（3） 半虛擬化

在硬件輔助虛擬化技術(shù)不完善、不強(qiáng)大的發(fā)展階段，或者對于某些復(fù)雜外設(shè)的共享復(fù)用，為避免全虛擬化的性能問題，可以采用 GuestOS 與 Hypervisor 協(xié)作的半虛擬化技術(shù)。這種技術(shù)一般應(yīng)用于 IO 設(shè)備虛擬化，采用前后端的方式來實(shí)現(xiàn) IO 設(shè)備虛擬化，在 Guest OS 中實(shí)現(xiàn)前端驅(qū)動，在 Hypervisor 或 Host OS 中實(shí)現(xiàn)后端驅(qū)動，前后端一般按照 VirtIO 標(biāo)準(zhǔn)來實(shí)現(xiàn)，后端驅(qū)動作為硬件的實(shí)際訪問方。

Guest OS 中前端驅(qū)動通過 Virt Queue 等通信機(jī)制與后端驅(qū)動進(jìn)行通信，前端驅(qū)動將 Guest OS 的請求傳遞給后端驅(qū)動，后端驅(qū)動將請求發(fā)送給硬件驅(qū)動，處理完后將結(jié)果再傳回給前端驅(qū)動。半虛擬化相對全虛擬化實(shí)現(xiàn)的硬件性能較好，且可實(shí)現(xiàn)相對比較復(fù)雜的硬件，比如 : 塊設(shè)備，網(wǎng)卡，顯示設(shè)備等。具體如圖 5 所示。



圖5 半虛擬化Pass-through資源分配

Hypervisor 支持將硬件資源直接分配給其上虛擬機(jī)中 Guest OS 使用，無需通過 Hypervisor 進(jìn)行地址和指令翻譯。例如 : 串口資源、USB 資源等接口比較豐富的資源可以通過 Pass-through 直接分配給某虛擬機(jī)使用。設(shè)備控制器一般都是以 MMIO 方式來訪問的，所以只需要將控制器地址區(qū)域映射到 VM 就可實(shí)現(xiàn)設(shè)備控制器的分配，同時還需要分配一個設(shè)備硬件中斷對應(yīng)的虛擬中斷到該 VM，直接透傳的方式就是 VM 獨(dú)占訪問該硬件，所以在性能上是最好的。

關(guān)鍵技術(shù)解讀

3.1 CPU 虛擬化和節(jié)能降耗技術(shù)

車載高性能處理器一般采用多核 CPU 架構(gòu)。在 SMP（Symmetric Multi-Processing 對稱多處理）架構(gòu)下，Hypervisor 調(diào)度器會根據(jù) CPU 的親和性配置讓客戶機(jī)操作系統(tǒng)在指定的 CPU 上運(yùn)行，虛擬機(jī)的操作系統(tǒng)可按照自己的調(diào)度方式，比如:優(yōu)先級方式在 CPU 上進(jìn)行任務(wù)調(diào)度。為了最大化地利用系統(tǒng)資源，Hypervisor 也支持多個虛擬機(jī)對某個 CPU 的共享使用。

在共享核上，Hypervisor 可通過優(yōu)先級或時間分區(qū)方式對虛擬機(jī)進(jìn)行調(diào)度，確保虛擬機(jī)運(yùn)行時間和調(diào)度策略是確定的。Hypervisor 的調(diào)度算法需要確保不能夠出現(xiàn)分區(qū)內(nèi)某個虛擬機(jī)出現(xiàn)死循環(huán)或故障而長期占用處理器資源，導(dǎo)致其他虛擬機(jī)的業(yè)務(wù)無法得到合理時間配額的問題。 虛擬機(jī)調(diào)度還需要考慮節(jié)能降耗問題，在工作負(fù)載較高的情況下系統(tǒng)提升主頻提升用戶體驗，在工作負(fù)載較低的情況下系統(tǒng)自動節(jié)能降頻提升續(xù)航。

車載高性能處理器本身為了節(jié)能降耗需求設(shè)計為大小核架構(gòu)，CPU 以及之上運(yùn)行的復(fù)雜操作系統(tǒng)需要支持大小核調(diào)度，動態(tài)調(diào)頻，低功耗設(shè)置，關(guān)閉 CPU 核，休眠（Suspend to RAM/Suspend to Disk）等節(jié)能降耗功能。系統(tǒng)虛擬化后，CPU 等物理資源都需要Hypervisor 才能直接訪問，Hypervisor 調(diào)度算法也需要完成對虛擬機(jī)節(jié)能降耗的支持。

3.2 IO 設(shè)備虛擬化

出于性能考慮，一般嵌入式領(lǐng)域多使用半虛擬化技術(shù)。半虛擬化技術(shù)需要 Guest OS 中的前端驅(qū)動與Hypervisor 中的后端驅(qū)動配合實(shí)現(xiàn)。前端驅(qū)動將 Guest OS 的請求通過 Hypervisor 提供的通信機(jī)制發(fā)送給后端驅(qū)動，后端驅(qū)動通過調(diào)用物理驅(qū)動實(shí)現(xiàn)對設(shè)備的訪問。這就涉及到不同廠商的 Guest OS 與不同廠商的 Hypervisor 生態(tài)對接問題。

Virtio 是目前最流行的一種 I/O 半虛擬化解決方案。Virtio 是 OASIS 標(biāo)準(zhǔn)組管理的開放協(xié)議和接口，以使得虛擬機(jī)能夠標(biāo)準(zhǔn)化方式訪問 IO 設(shè)備。Virtio 于 2016 年 3 月正式標(biāo)準(zhǔn)化，2020 發(fā)布 V1.1 版本。Virtio 標(biāo)準(zhǔn)采用通用和標(biāo)準(zhǔn)化的抽象模型，支持設(shè)備類型不斷增加，性能高效，在云計算領(lǐng)域廣泛應(yīng)用，開源活躍度高，Linux 等操作系統(tǒng)已有穩(wěn)定的前端驅(qū)動代碼。

大部分商業(yè)和開源 Hypervisor 都已經(jīng)支持Virtio 標(biāo)準(zhǔn)。 Virtio 是車載行業(yè)比較常用的半虛擬化技術(shù)的實(shí)現(xiàn)，如圖 6 所示，在 Guest OS 內(nèi)部虛擬一條設(shè)備總線 Virtio-bus，通過 Virtio Ring 雙向通信機(jī)制，前端驅(qū)動與掛載在 Virtio-bus 上遵循 Virtio 標(biāo)準(zhǔn)的后端虛擬設(shè)備，進(jìn)行訪問與通信。Virtio 提供了全面的 Virtio 總線和設(shè)備控制接口，包括 virtio-net， virtio-blk， virtio-console， virtio-input 等。



圖6 Virtio虛擬化實(shí)現(xiàn)模型

利用 virtio-blk 技術(shù)實(shí)現(xiàn)塊設(shè)備共享

塊設(shè)備是使用緩存機(jī)制讀寫的存儲設(shè)備，分配給 Hypervisor 所在的操作系統(tǒng)進(jìn)行管理。virtio-blk driver 是符合 virtio 標(biāo)準(zhǔn)的塊設(shè)備驅(qū)動，vdev virtio block 是后端的虛擬塊設(shè)備，virtio blk driver 通過該vdev 設(shè)備完成對物理塊設(shè)備的讀寫，并獲取執(zhí)行結(jié)果。

利用 virtio-net 技術(shù)實(shí)現(xiàn)跨系統(tǒng)通信

Virtio-net 實(shí)現(xiàn)了多系統(tǒng)間點(diǎn)對點(diǎn)的通信，Guest 系統(tǒng)內(nèi)部的 virtio-net driver 通過 virtqueue 與Hypervisor 所在系統(tǒng)的 virtio-net 設(shè)備進(jìn)行全雙工通信，實(shí)現(xiàn)多系統(tǒng)之間的控制類、配置類的指令、數(shù)據(jù)的交互。適合音視頻流以外的數(shù)據(jù)傳輸，穩(wěn)定性較好，因 virtqueue 的控制邏輯復(fù)雜，對實(shí)時性有一定影響。

利用 virtio 技術(shù)實(shí)現(xiàn)觸摸共享

觸摸設(shè)備是字符型設(shè)備，通過 virtio-input driver、vdev-input 實(shí)現(xiàn)前端驅(qū)動和后端設(shè)備。設(shè)備端通過 virtqueue 向驅(qū)動上報觸摸坐標(biāo)數(shù)據(jù)。

3.3 實(shí)時性技術(shù)

實(shí)時性是嵌入式實(shí)時操作系統(tǒng)的關(guān)鍵性能指標(biāo)。Hypervisor 的實(shí)時性是整個系統(tǒng)實(shí)時性的基礎(chǔ)，如果 Hypervisor 無法及時調(diào)度到客戶機(jī)操作系統(tǒng)運(yùn)行，客戶機(jī)操作系統(tǒng)也不能取得較好的實(shí)時性指標(biāo)。衡量 Hypervisor 實(shí)時性主要指標(biāo)包括中斷延遲和調(diào)度延遲。

中斷延遲以硬件發(fā)生中斷時刻為起始時間，以虛擬機(jī)收到 Hypervisor 注入的中斷時刻為截止時間，在各種壓力情況下最長延時時間即為中斷延時。調(diào)度延遲是指以高優(yōu)先級的虛擬機(jī)進(jìn)程就緒為起始時刻，以該高優(yōu)先的虛擬機(jī)進(jìn)程得到調(diào)度運(yùn)行為截止時刻，在系統(tǒng)各種壓力情況下最長的延時時間即為調(diào)度延遲。

中斷虛擬化后，當(dāng)外界中斷產(chǎn)生時，Hypervisor 收到并以最快的速度注入到虛擬機(jī)，使得 Hypervisor 對虛擬機(jī)中斷處理時間足夠少。Hypervisor 優(yōu)化虛擬機(jī)的切換時間，盡量減少 Hypervisor 上關(guān)中斷和關(guān)搶占的時間，盡量少使用內(nèi)核鎖，當(dāng)高優(yōu)先級的虛擬機(jī)需要切換運(yùn)行時，能最快速度切換至高優(yōu)先級虛擬機(jī)上運(yùn)行。

3.4安全和可靠性技術(shù)

功能安全、信息安全和可靠性是車控操作系統(tǒng)產(chǎn)品可靠安全運(yùn)行的必要組成部分。Hypervisor 為智能汽車域控制器提供基礎(chǔ)運(yùn)行環(huán)境，其安全性和可靠性是保證整個系統(tǒng)功能安全和可靠的基礎(chǔ)和核心。Hypervisor 需按照汽車功能安全 ISO26262 ASIL-D 最高標(biāo)準(zhǔn)進(jìn)行設(shè)計，開發(fā)和測試，其功能安全需求由域控制器產(chǎn)品的安全需求分解產(chǎn)生。

Hypervisor 上運(yùn)行了多個虛擬機(jī)，一個虛擬機(jī)的異常不能傳遞至其他虛擬機(jī)。Hypervisor 能獲取到當(dāng)前系統(tǒng)整體健康狀態(tài)，當(dāng)虛擬機(jī)發(fā)生異常時，Hypervisor 應(yīng)實(shí)時監(jiān)控系統(tǒng)健康狀態(tài)，有效地隔離故障，并在最小波及范圍內(nèi)修復(fù)異常，保障系統(tǒng)持續(xù)可用。

Hypervisor 加入汽車軟件棧，會導(dǎo)致縱向上軟件棧層次增加，橫向上業(yè)務(wù)軟件復(fù)雜度增加，而汽車的安全可靠要求強(qiáng)于既有的云側(cè)虛擬化、邊緣虛擬化，因此虛擬化安全性正日益得到行業(yè)的關(guān)注。這些安全性包括：

虛擬機(jī)管理器和虛擬機(jī)之間的信任鏈問題。利用虛擬化技術(shù)在一個可信物理平臺上創(chuàng)建出多個虛擬機(jī)，并將從硬件可信根開始構(gòu)建的信任鏈傳遞到每一個虛擬機(jī)，從而在一個可信物理平臺上構(gòu)建多個虛擬的可信計算平臺，有些解決方案缺乏虛擬機(jī)管理器到虛擬機(jī)之間的信任鏈驗證；

虛擬機(jī)間的攻擊：惡意入侵者可以通過利用虛擬機(jī)管理程序中的漏洞，通過同一物理主機(jī)上存在的另一個虛擬機(jī)來獲得對虛擬機(jī)的控制，從而破壞目標(biāo)虛擬機(jī)；

虛擬機(jī)逃逸：利用虛擬機(jī)軟件或者虛擬機(jī)中運(yùn)行的軟件的漏洞進(jìn)行攻擊，以達(dá)到攻擊或控制虛擬機(jī)宿主操作系統(tǒng)的目的。

為了提高 Hypervisor 的安全性，建立相應(yīng)的安全性目標(biāo)很重要，下表簡要列出相關(guān)要求：



Hypervisor 的安全性能力可以從三個維度進(jìn)行提升。

（1） 需要建立安全邊界

如圖 7 所示，這個邊界由 Hypervisor 嚴(yán)格定義并且實(shí)施。Hypervisor 安全邊界的保密性、完整性和可用性需要得到保證。邊界能防御一系列攻擊，包括側(cè)向通道信息泄漏、拒絕服務(wù)和特權(quán)提升。虛擬機(jī)監(jiān)控程序安全邊界還提供網(wǎng)絡(luò)流量、虛擬設(shè)備、存儲、計算資源和所有其他虛擬機(jī)資源的隔離能力。



圖7 安全邊界 整體虛擬化安全架構(gòu)如圖 8 所示。安全邊界的保密性可以通過傳統(tǒng)的密碼學(xué)方法來實(shí)施。完整性通過可信度量機(jī)制來保障，可信報告機(jī)制實(shí)現(xiàn)不同虛擬環(huán)境的可信互通，監(jiān)控機(jī)制動態(tài)度量實(shí)體的行為，發(fā)現(xiàn)和排除非預(yù)期的互相干擾。虛擬技術(shù)提供的隔離機(jī)制將實(shí)體運(yùn)行空間分開。



圖8 整體虛擬化安全架構(gòu)

安全邊界的隔離通過Hypervisor的vCPU調(diào)度隔離安全、內(nèi)存隔離、網(wǎng)絡(luò)隔離和存儲隔離技術(shù)來支持，實(shí)現(xiàn)了同一物理機(jī)上 Hypervisor 和虛擬機(jī)、虛擬機(jī)之間的隔離。

（2） 需要建立深度防御漏洞的緩解機(jī)制 對于安全邊界存在的潛在漏洞，Hypervisor 需要有一定的技術(shù)手段進(jìn)行主動防御，這些技術(shù)手段包括地址空間布局隨機(jī)化（ASLR）、數(shù)據(jù)執(zhí)行保護(hù)（DEP）、任意代碼保護(hù)、控制流保護(hù)和數(shù)據(jù)損壞保護(hù)等。

（3） 建立強(qiáng)大的安全保障流程 與 Hypervisor 相關(guān)的攻擊面包括虛擬網(wǎng)絡(luò)、虛擬設(shè)備和所有跨虛擬機(jī)表面，所有虛擬機(jī)攻擊面都建議實(shí)施威脅建模、代碼審核、模糊（fuzzed）測試，通過建立自動化構(gòu)建及環(huán)境，觸發(fā)定期安全檢查。

虛擬化技術(shù)作為云計算場景的重要技術(shù)，在 10 多年的生產(chǎn)實(shí)踐中已經(jīng)積累了很多安全范式，這些經(jīng)驗也可被汽車場景借鑒。但是與云場景相比，汽車場景的虛擬化技術(shù)也有其特殊性，如虛擬機(jī)不需要動態(tài)遷移 / 創(chuàng)建，Hypervisor 有功能安全等級的要求等等，其安全性手段需要在實(shí)踐中不斷豐富和完善。

典型應(yīng)用案例

在汽車智能化發(fā)展歷程中，虛擬化主要應(yīng)用于智能座艙、智能駕駛、智能網(wǎng)關(guān)等融合場景。智能駕駛受技術(shù)成熟度、政策法規(guī)所限，基本處于預(yù)研、方案原型階段。智能網(wǎng)關(guān)業(yè)務(wù)功能相對同構(gòu)，并且有可能進(jìn)一步融合到其他場景方案中。因此，目前主要的應(yīng)用案例集中在智能座艙中。

智能座艙域融合也是在近幾年啟動，正在不斷迭代演進(jìn)中。受芯片算力、虛擬化技術(shù)成熟度、生態(tài)鏈對于虛擬化解決方案的掌控能力等因素影響，有些廠商同時采用了硬隔離方案來實(shí)現(xiàn)域融合，一方面最大程度地沿用既有技術(shù)能力，有確定性保障，但是缺少了軟件定義的靈活性，智能化程度有限，是域融合的一種可選方案。

在嵌入式虛擬化技術(shù)方面，國外的 QNX、OpenSynergy、PikeOS 等有先發(fā)優(yōu)勢，尤其在汽車領(lǐng)域已耕耘多年，因此在這兩年涌現(xiàn)了較多的應(yīng)用案例。在智能本土化發(fā)展的趨勢帶動下，國內(nèi)這幾年也出現(xiàn)了不少芯片廠商、獨(dú)立軟件廠商研發(fā)嵌入式虛擬化技術(shù)、產(chǎn)品、解決方案，如中瓴智行的 RAITE Hypervisor(RHOS)、中興 GoldenOS、斑馬智行的 AliOS Hypervisor、中汽創(chuàng)智 CAIC Hypervisor 等。

4.1 智能座艙域控制器產(chǎn)品

某廠家智能座艙域控制器產(chǎn)品，如圖 9 和圖 10 所示，基于高通 8155、瑞薩 R-Car H3 處理器，采用 QNX Hypervisor，搭載 QNX Host、 Android P/R/S Guest OS, 可配置輸出最多 6 塊高清大屏獨(dú)立顯示，集成了娛樂系統(tǒng)、液晶儀表、車身控制、DMS、APA 等功能，支持獨(dú)立四音區(qū)、多屏互動和音視頻分享，集成度高，在長城、長安、宇通客車等多款車型上適配量產(chǎn)。 另外，國產(chǎn)化方案芯馳 X9HP+ 平臺，采用硬分區(qū)、Hypervisor 兩種方案靈活配置實(shí)現(xiàn)中低端智能座艙域控制器產(chǎn)品。

4.2RHOS 智能座艙域控制器平臺

（1） NXP I.MX8QM 座艙域控制器 某廠家基于自研的 Type-1 型虛擬化軟件 RHOS(Raite Hypervisor OS)，適配支持了 NXP I.MX8QM，提供一個輕量、靈活的汽車智能座艙虛擬化解決方案，已在東風(fēng)車型量產(chǎn)上市。其系統(tǒng)架構(gòu)如圖 11所示：



圖11 NXP I.MX8智能座艙系統(tǒng)架構(gòu)

在 SoC 上運(yùn)行 Hypervisor 后可支持同時運(yùn)行多個操作系統(tǒng)，比如 Linux 系統(tǒng)可以運(yùn)行實(shí)時性和安全性較高的業(yè)務(wù)，如全液晶儀表等，可以擴(kuò)展運(yùn)行 DMS、HUD 等業(yè)務(wù)。另外一個虛擬機(jī)運(yùn)行 Android 操作系統(tǒng)，上面部署信息娛樂等安全性和實(shí)時性要求較低的業(yè)務(wù)。為保證系統(tǒng)具備良好的市場競爭力，域控制器兼容 TBOX 功能需求，系統(tǒng)能夠支持休眠喚醒和快速啟動。

Linux 和 Android 虛擬機(jī)可按需進(jìn)行資源的配置，包括內(nèi)存、CPU、存儲空間、外設(shè)等。該架構(gòu)支持系統(tǒng)升級，包括對虛擬機(jī)和 Hypervisor 的升級，支持異常日志記錄，包括虛擬機(jī)內(nèi)核和 Hypervisor 日志。 多屏交互是智能座艙重要的應(yīng)用場景，Android 的 APP 應(yīng)用程序可以通過 Hypervisor 推送到 Linux儀表進(jìn)行顯示。



圖12 虛擬機(jī)多屏交互架構(gòu)

Android 和 Linux 儀表交互的方案如圖 12 所示。NXP I.MX8QM 芯片有兩個以上顯示接口，每個顯示接口可以接 2 個顯示屏，當(dāng) Android 系統(tǒng)需要投射信息到儀表屏幕時，儀表顯示屏的 Overlay 圖層可以進(jìn)行投屏內(nèi)容的顯示。系統(tǒng)交互零延遲、零拷貝，多系統(tǒng)交互不額外占用 CPU 和 GPU 資源。

通過Hypervisor 虛擬化技術(shù)實(shí)現(xiàn)跨系統(tǒng)多屏交互，有效提高了行車安全性，并降低智能座艙的硬件成本。

（2） MT8675 座艙域控制器

RHOS 通過適配支持MT8675，形成一個功能豐富、性價比高的一機(jī)多屏智能座艙域控制器解決方案，已獲得多個車廠量產(chǎn)項目。其總體系統(tǒng)架構(gòu)如圖 13 所示：



圖13 MT8675智能座艙系統(tǒng)架構(gòu)

MT8675 只提供了一個 GPU，座艙域需要在儀表和中控上共享使用 GPU 資源。RHOS 實(shí)現(xiàn)了 GPU虛擬化共享，并通過性能優(yōu)化，達(dá)到業(yè)界領(lǐng)先的虛擬化效果（損耗 < 6%）。RHOS 支持 Suspend to RAM 功能，MT8675 A 核完全下電，滿足智能座艙待機(jī)靜態(tài)功耗小于 4mA 要求。

審核編輯：劉清