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

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

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

編譯Harmony系統(tǒng)

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

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

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

▲獲取源碼

▲安裝和配置Python

▲安裝gn

▲安裝ninja

▲安裝LLVM

▲安裝hb

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

請(qǐng)注意，此時(shí)我們還無法編譯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)境搭建，如果需要編譯別的工程，搭建對(duì)應(yīng)的開發(fā)板環(huán)境即可。

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

編譯Harmony系統(tǒng)

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

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

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

成功實(shí)現(xiàn)wifiiot_hispark_pegasus工程的編譯后，我們就可以進(jìn)行后續(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標(biāo)準(zhǔn)，因此需要在生成配置文件時(shí)需要添加-std=C99，具體如下圖：

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

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

為了方便后續(xù)將Harmony的靜態(tài)分析過程部署到持續(xù)集成平臺(tái)上，本文以命令行的方式進(jìn)行靜態(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)提供編碼標(biāo)準(zhǔn)，廣泛應(yīng)用于汽車軟件開發(fā)。
• CERT：信息安全編碼標(biāo)準(zhǔn)，能確保您的軟件免受潛在的軟件安全漏洞的侵害。
• CWE C：常見弱點(diǎn)枚舉(CWE)列表標(biāo)識(shí)了軟件和硬件中的軟件安全弱點(diǎn)。

• 過濾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工程的編譯過程，自動(dòng)將編譯過程中調(diào)用的源文件和頭文件添加到QAC工程中。

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

qacli analyze -P . –cf

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

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

CERT合規(guī)情況

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

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

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的嚴(yán)重程度，由上圖可以看出，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個(gè)函數(shù)如下圖：

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

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

規(guī)則解釋：

根據(jù) C標(biāo)準(zhǔn)，7.1.3 [ISO/IEC 9899:2011]，

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

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

違規(guī)舉例：

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

#define EVENT_VALUE_MAX_NUM16

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

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

2. INT02 Understand integer conversion rules. (recommend)

規(guī)則解釋：

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

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

違規(guī)舉例：

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

此處代碼不合規(guī)，因?yàn)橐粋€(gè)'essentially signed'類型的整型常量在賦值時(shí)被轉(zhuǎn)換為'unsigned'類型。

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

規(guī)則解釋：

根據(jù) C標(biāo)準(zhǔn) [ISO/IEC 9899:2011]的第 6.2.7條，

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

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

任何在重要字符上不同的標(biāo)識(shí)符都是不同的標(biāo)識(shí)符。如果兩個(gè)標(biāo)識(shí)符僅在非重要字符上不同，則行為未定義。

違規(guī)舉例：

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

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

此處代碼不合規(guī)，因?yàn)橥獠繕?biāo)識(shí)符匹配其他外部標(biāo)識(shí)符(例如:'HiEventPrintf')的前6個(gè)字符-程序不符合嚴(yán)格的ISO:C90。

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

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

規(guī)則解釋：

不可變對(duì)象應(yīng)該使用const限定。使用const限定來強(qiáng)制對(duì)象不變性有助于確保應(yīng)用程序的正確性和安全性。例如，ISO/IEC TR 24772建議將參數(shù)標(biāo)記為常量，以避免無意中修改函數(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ī)，因?yàn)樾螀?type'永遠(yuǎn)不會(huì)被修改，因此可以用'const'限定符聲明它。

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

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

規(guī)則解釋：

C標(biāo)準(zhǔn)附錄J [ISO/IEC 9899:2011]指出，如下行為是未定義的：

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

釋放非動(dòng)態(tài)分配的內(nèi)存可能導(dǎo)致堆棧損壞和其他嚴(yán)重錯(cuò)誤。不要對(duì)非標(biāo)準(zhǔn)內(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ī)，因?yàn)檫@是對(duì)非動(dòng)態(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é)束語

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