華為的Harmony手機操作系統(tǒng)已經(jīng)發(fā)布了幾個月了，作為國產(chǎn)操作系統(tǒng)，其寄托了我們的深切希望。在Harmony系統(tǒng)發(fā)布會上，手機、平板、智能手表等消費電子類產(chǎn)品固然是主角，而作為華為冉冉升起的新興業(yè)務(wù)領(lǐng)域——智能汽車，亦被包含在系統(tǒng)生態(tài)之中，也引起了行業(yè)的廣泛關(guān)注。

Harmony作為一個新生的系統(tǒng)，其不可避免的會存在很多問題，而汽車領(lǐng)域?qū)Υa的編碼規(guī)范要求又極為嚴格。因此本文將通過使用汽車行業(yè)主流的靜態(tài)分析工具，來分析測試Harmony系統(tǒng)代碼對汽車行業(yè)內(nèi)常用編碼規(guī)范（CERT、MISRA C 2012、CWE C）的遵循情況。

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

編譯Harmony系統(tǒng)

Ubuntu編譯環(huán)境準備

系統(tǒng)要求：Ubuntu16.04及以上64位系統(tǒng)版本。

本文使用的是搭建在虛擬機中的Ubuntu 18.0系統(tǒng)，編譯環(huán)境搭建分為如下步驟：

▲獲取源碼

▲安裝和配置Python

▲安裝gn

▲安裝ninja

▲安裝LLVM

▲安裝hb

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

請注意，此時我們還無法編譯Harmony系統(tǒng)，需要完成后續(xù)開發(fā)板環(huán)境搭建后才能正常編譯Harmony系統(tǒng)。

Hi3861開發(fā)板環(huán)境搭建

為了能正常編譯源碼中的wifiiot_hispark_pegasus工程，我們需要在剛才設(shè)置的Ubuntu編譯環(huán)境中搭建Hi3861開發(fā)板環(huán)境搭建，如果需要編譯別的工程，搭建對應(yīng)的開發(fā)板環(huán)境即可。

了解詳細的搭建步驟請移步安裝Hi3861開發(fā)板環(huán)境。

編譯Harmony系統(tǒng)

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

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

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

成功實現(xiàn)wifiiot_hispark_pegasus工程的編譯后，我們就可以進行后續(xù)的靜態(tài)分析工作了。

Harmony系統(tǒng)靜態(tài)分析

Harmony系統(tǒng)編譯環(huán)境配置

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

然后在靜態(tài)測試工具中導(dǎo)入該配置文件即可。

靜態(tài)分析執(zhí)行

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

• 創(chuàng)建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系統(tǒng)的代碼質(zhì)量，本文在QAC工程的分析配置文件HMOS.acf中添加了MISRA C 2012合規(guī)模塊、CERT C合規(guī)模塊及CWE C合規(guī)模塊。

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

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

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

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

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

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

該命令是通過監(jiān)測wifiiot_hispark_pegasus工程的編譯過程，自動將編譯過程中調(diào)用的源文件和頭文件添加到QAC工程中。

• 執(zhí)行QAC分析，具體命令如下：

qacli analyze -P . –cf

• 生成合規(guī)報告：

qacli report -P . -t RCR

• 將分析結(jié)果上傳到QAC的網(wǎng)頁端，方便查看，命令如下：

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

靜態(tài)分析結(jié)果分析

模塊wifiiot_hispark_pegasus的總體合規(guī)情況如下：

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

CERT合規(guī)情況

wifiiot_hispark_pegasus源碼的CERT總體違規(guī)情況如下圖：

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

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規(guī)則如下圖：

CERT C規(guī)則的違規(guī)分布情況如下圖：

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

• 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的診斷消息。

圈復(fù)雜度最高的10個函數(shù)如下圖：

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

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

規(guī)則解釋：

根據(jù) C標準，7.1.3 [ISO/IEC 9899:2011]，

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

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

違規(guī)舉例：

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

#define EVENT_VALUE_MAX_NUM16

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

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

2. INT02 Understand integer conversion rules. (recommend)

規(guī)則解釋：

轉(zhuǎn)換可以作為強制轉(zhuǎn)換的結(jié)果顯式發(fā)生，也可以根據(jù)操作的要求隱式發(fā)生。盡管正確執(zhí)行程序通常需要進行轉(zhuǎn)換，但它們也可能導(dǎo)致數(shù)據(jù)丟失或被誤解。將操作數(shù)值轉(zhuǎn)換為兼容類型不會導(dǎo)致值或表示發(fā)生變化。

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

違規(guī)舉例：

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

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

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

規(guī)則解釋：

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

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

此外，根據(jù)第 6.4.2.1款，

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

違規(guī)舉例：

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

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

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

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

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

規(guī)則解釋：

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

違規(guī)舉例：

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

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

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

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

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

規(guī)則解釋：

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

free或realloc函數(shù)的指針參數(shù)與先前由內(nèi)存管理函數(shù)返回的指針不匹配，或者空間已被調(diào)用free或realloc釋放。

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

違規(guī)舉例：

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

FREE((char*)payload);

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

payload=json_to_string(obj_value);

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

結(jié)束語

通過對Harmony系統(tǒng)部分代碼的靜態(tài)測試，我們嘗試了解了Harmony系統(tǒng)針對汽車行業(yè)常用的代碼編程規(guī)范的合規(guī)情況，期望未來Harmony通過不斷迭代開發(fā)，提升代碼的合規(guī)程度，進一步改善代碼的質(zhì)量，成為一個優(yōu)秀的車載操作系統(tǒng)。