華為的Harmony手機操作系統已經發布了幾個月了，作為國產操作系統，其寄托了我們的深切希望。在Harmony系統發布會上，手機、平板、智能手表等消費電子類產品固然是主角，而作為華為冉冉升起的新興業務領域——智能汽車，亦被包含在系統生態之中，也引起了行業的廣泛關注。

Harmony作為一個新生的系統，其不可避免的會存在很多問題，而汽車領域對代碼的編碼規范要求又極為嚴格。因此本文將通過使用汽車行業主流的靜態分析工具，來分析測試Harmony系統代碼對汽車行業內常用編碼規范（CERT、MISRA C 2012、CWE C）的遵循情況。

考慮到標準Harmony系統的代碼量非常龐大，本文僅以OpenHarmony_1.0.1_release分支中的Hi3861 WLAN模組代碼為例進行部分代碼的靜態測試。

編譯Harmony系統

Ubuntu編譯環境準備

系統要求：Ubuntu16.04及以上64位系統版本。

本文使用的是搭建在虛擬機中的Ubuntu 18.0系統，編譯環境搭建分為如下步驟：

▲獲取源碼

▲安裝和配置Python

▲安裝gn

▲安裝ninja

▲安裝LLVM

▲安裝hb

了解詳細的配置步驟請移步Harmony開源項目教程指南，本文就不做詳細的介紹了，按照文檔一步一步進行操作，就可以獲取Harmony輕量系統源碼，并完成編譯環境的搭建。

請注意，此時我們還無法編譯Harmony系統，需要完成后續開發板環境搭建后才能正常編譯Harmony系統。

Hi3861開發板環境搭建

為了能正常編譯源碼中的wifiiot_hispark_pegasus工程，我們需要在剛才設置的Ubuntu編譯環境中搭建Hi3861開發板環境搭建，如果需要編譯別的工程，搭建對應的開發板環境即可。

了解詳細的搭建步驟請移步安裝Hi3861開發板環境。

編譯Harmony系統

完成Hi3861開發版環境搭建后，我們就可以正常編譯源碼中的wifiiot_hispark_pegasus工程了，具體步驟如下：

▲到下載的源碼根目錄下，執行hb set，然后會提示讓你輸入源碼根目錄，輸入當前路徑后回車，選擇wifiiot_hispark_pegasus項目就完成了編譯準備工作。

▲執行hb build即可進行wifiiot_hispark_pegasus工程的編譯，如果編譯結果如下圖所示，即表示你成功地編譯了該工程。

成功實現wifiiot_hispark_pegasus工程的編譯后，我們就可以進行后續的靜態分析工作了。

Harmony系統靜態分析

Harmony系統編譯環境配置

通過編譯器環境配置文件生成工具，我們可以很方便地生成Harmony編譯環境的配置文件，由于wifiiot_hispark_pegasus工程是C工程，因此只配置C編譯器的環境即可，考慮到Harmony使用的是C99標準，因此需要在生成配置文件時需要添加-std=C99，具體如下圖：

然后在靜態測試工具中導入該配置文件即可。

靜態分析執行

為了方便后續將Harmony的靜態分析過程部署到持續集成平臺上，本文以命令行的方式進行靜態分析操作的演示。具體步驟如下：

• 創建QAC工程，命令如下：

qacli admin --qaf-project-config --qaf-project . --cct "/home/zhou/.config/Perforce/Helix-QAC-2021.1/config/cct/GNU_GCC-riscv32-unknown-elf-gcc_7.3.0-riscv32-unknown-elf-C-c99.cct" --acf "/home/zhou/.config/Perforce/Helix-QAC-2021.1/config/acf/HMOS.acf" --rcf "/home/zhou/.config/Perforce/Helix-QAC-2021.1/config/rcf/HMOS.rcf"

為了更全面地了解Harmony系統的代碼質量，本文在QAC工程的分析配置文件HMOS.acf中添加了MISRA C 2012合規模塊、CERT C合規模塊及CWE C合規模塊。

• MISRA C 2012：為開發安全關鍵系統提供編碼標準，廣泛應用于汽車軟件開發。
• CERT：信息安全編碼標準，能確保您的軟件免受潛在的軟件安全漏洞的侵害。
• CWE C：常見弱點枚舉(CWE)列表標識了軟件和硬件中的軟件安全弱點。

• 過濾Harmony中包含的第三方源碼，命令如下：

qacli pprops -P . --sync-setting FILE_FILTER --set "/home/zhou/Downloads/openHarmony/third_party"

通過該命令，我們可以將Harmony工程中包含的第三方源碼從QAC工程中過濾出去，這樣我們可以更好地通過QAC的分析結果衡量Harmony蒙源碼的代碼質量。

• 將wifiiot_hispark_pegasus工程源碼加載到QAC工程中，具體命令如下：

qacli sync -P . -t MONITOR "cd /home/zhou/Downloads/openHarmony&&hb clean&&hb build"

該命令是通過監測wifiiot_hispark_pegasus工程的編譯過程，自動將編譯過程中調用的源文件和頭文件添加到QAC工程中。

• 執行QAC分析，具體命令如下：

qacli analyze -P . –cf

• 生成合規報告：

qacli report -P . -t RCR

• 將分析結果上傳到QAC的網頁端，方便查看，命令如下：

qacli upload -P . --qav-upload --upload-project HMOS --snapshot-name v1.0 --upload-source ALL -U https://192.168.9.126:8081/ --username admin --password admin

靜態分析結果分析

模塊wifiiot_hispark_pegasus的總體合規情況如下：

QAC共計報出107618條診斷消息，共計違反規則290264次，違反的規則數目為302條（包含MISRA C、CERT C和CWE C），符合的規則有216條，由于模塊的文件合規率高達94.19%，但是工程合規率卻只有41.70%，所以可以看出違反規則的情況集中在少部分源文件中。

CERT合規情況

wifiiot_hispark_pegasus源碼的CERT總體違規情況如下圖：

圖中的圖例為CERT C的規則組簡寫，詳細信息如下：

02_DCL Declarations and Initialization (DCL)

10_ENV Environment (ENV)

11_SIG Signals (SIG)

04_INT Integers (INT)

09_FIO Input Output (FIO)

14_CON Concurrency (CON)08_MEM Memory Management (MEM)

07_STR Characters and Strings (STR)

03_EXP Expressions (EXP)

違反最多的10條CERT C規則如下圖：

CERT C規則的違規分布情況如下圖：

圖中方塊面積表示代碼量，顏色深淺表示違反CERT的嚴重程度，由上圖可以看出，CERT C的違規情況主要集中在如下源文件中：

• cmsis_task_func_test.c：有3182行代碼，違反了1951條CERT C的診斷消息；
• cmsis_task_pri_func_test.c有1635行代碼，違反了1144條CERT C的診斷消息；
• tcp_session_manager.c：有1230行代碼，違反了912條CERT C的診斷消息；
• huks_adapter.c：有1705行代碼，違反了862條CERT C的診斷消息；
• coap_adapter.c：有638行代碼，違反了579條CERT C的診斷消息。

圈復雜度最高的10個函數如下圖：

下文我們將摘錄部分違反規則的代碼進行分析說明：

1. DCL37 Do not declare or define a reserved identifier. (rule)

規則解釋：

根據 C標準，7.1.3 [ISO/IEC 9899:2011]，

所有以下劃線和大寫字母或其他下劃線開頭的所有標識符都始終保留使用。

所有以下劃線開頭的標識符始終保留，用作普通名稱空間和標簽名稱空間中文件范圍的標識符。

違規舉例：

/HMOS/base/hiviewdfx/hievent_lite/frameworks/hiview_event.c，L28：

#define EVENT_VALUE_MAX_NUM16

此處代碼不合規，因為'EVENT_VALUE_MAX_NUM'宏可能在未來與''中的宏有沖突。

參考ISO:C90 Language [7.13], ISO:C99 Language [7.26]

2. INT02 Understand integer conversion rules. (recommend)

規則解釋：

轉換可以作為強制轉換的結果顯式發生，也可以根據操作的要求隱式發生。盡管正確執行程序通常需要進行轉換，但它們也可能導致數據丟失或被誤解。將操作數值轉換為兼容類型不會導致值或表示發生變化。

C整數轉換規則定義了 C編譯器如何處理轉換。這些規則包括整數提升、整數轉換等級和通常的算術轉換。規則的意圖是確保轉化導致相同的數值，并且這些值最小化了其余計算中的意外。Prestandard C通常更傾向于保留類型的簽名。

違規舉例：

/HMOS/base/hiviewdfx/hievent_lite/frameworks/hiview_event.c，L57：e.common.mark=EVENT_INFO_HEAD;

此處代碼不合規，因為一個'essentially signed'類型的整型常量在賦值時被轉換為'unsigned'類型。

3. DCL23 Guarantee that mutually visible identifiers are unique. (recommend)

規則解釋：

根據 C標準 [ISO/IEC 9899:2011]的第 6.2.7條，

所有引用同一對象或函數的聲明都應具有兼容的類型；否則，行為未定義。

此外，根據第 6.4.2.1款，

任何在重要字符上不同的標識符都是不同的標識符。如果兩個標識符僅在非重要字符上不同，則行為未定義。

違規舉例：

/HMOS/base/hiviewdfx/hievent_lite/interfaces/native/innerkits/hiview_event.h，L85：

voidHiEventPutInteger(HiEvent*event, int8 key, uint32 value);

此處代碼不合規，因為外部標識符匹配其他外部標識符(例如:'HiEventPrintf')的前6個字符-程序不符合嚴格的ISO:C90。

參考：ISO:C90 Language [6.1.2], Security Problems

4. DCL00 Const-qualify immutable objects. (recommend)

規則解釋：

不可變對象應該使用const限定。使用const限定來強制對象不變性有助于確保應用程序的正確性和安全性。例如，ISO/IEC TR 24772建議將參數標記為常量，以避免無意中修改函數參數 [ISO/IEC TR 24772]。STR05-C.Use pointers to const when referring to string literals描述了此建議的特殊情況。

違規舉例：

/HMOS/base/hiviewdfx/hievent_lite/frameworks/hiview_event.c，L50：

voidHiEventPrintf(uint8 type, uint16 eventId, int8 key, uint32 value)

此處代碼不合規，因為形參'type'永遠不會被修改，因此可以用'const'限定符聲明它。

參考：, ISO:C90 Language [6.5.3], Security Problems

5. MEM34-C. Only free memory allocated dynamically.(rule)

規則解釋：

C標準附錄J [ISO/IEC 9899:2011]指出，如下行為是未定義的：

free或realloc函數的指針參數與先前由內存管理函數返回的指針不匹配，或者空間已被調用free或realloc釋放。

釋放非動態分配的內存可能導致堆棧損壞和其他嚴重錯誤。不要對非標準內存分配函數返回的指針調用free()，如malloc()、calloc()、realloc()或aligned_alloc()。

違規舉例：

/HMOS/base/security/deviceauth/frameworks/deviceauth_lite/source/struct/parsedata.c，第76行代碼：

FREE((char*)payload);

此處代碼不合規，因為這是對非動態內存palyload變量的釋放，payload定義在/HMOS/base/security/deviceauth/frameworks/deviceauth_lite/source/struct/parsedata.c，L53：

payload=json_to_string(obj_value);

限于篇幅，MISRA C和CWE C的合規情況不在這里一一展示。

結束語

通過對Harmony系統部分代碼的靜態測試，我們嘗試了解了Harmony系統針對汽車行業常用的代碼編程規范的合規情況，期望未來Harmony通過不斷迭代開發，提升代碼的合規程度，進一步改善代碼的質量，成為一個優秀的車載操作系統。