探究鸿蒙系统底座OpenHarmony 的代码质量改进:编译OpenHarmony | 搭建Docker环境 | 编译源码 | Klocwork静态分析 | 分析结果 | MISRA规则分析结果

提到鸿蒙操作系统(Harmony OS),想必大家并不陌生。其底座OpenHarmony是由华为捐出的鸿蒙开源系统,并且由开放原子开源基金会孵化及运营, 目标是面向全场景、全连接、全智能时代, 搭建一个智能终端设备操作系统的框架和平台, 促进万物互联产业的繁荣发展i。数月前,华为再度突破新的领域——与国航签约,华为将助力国航在以OpenHarmony为底座的HarmonyOS框架上构建应用/服务。作为汽车行业的新势力,华为在汽车领域拥有卓越的表现,市面上很多汽车已将Harmony OS作为其车机系统。

然而,OpenHarmony并不是专为汽车行业而研发。由于汽车行业的特殊性,车载软件对代码安全性的要求非常严格,在之前的文章《沉浸式测试 | 鸿蒙(HarmonyOS)生态下的智能汽车静态代码分析》中,我们使用了汽车行业主流的静态测试工具QAC验证OpenHarmony的安全性,过了这么久,OpenHarmony代码对汽车行业编码规范的合规性是否有所提升呢?接下来本文将使用汽车行业的另一款权威静态测试工具Klocwork,基于汽车行业内的常用编码规范MISRA C 2012(符合汽车功能安全要求,了解更多请见《带你走近MISRA C 2012》)和CERT(符合网络信息安全要求),对鸿蒙代码的合规情况进行测试。

本文对OpenHarmony主干源码1348版本的wifiiot_hispark_pegasus工程进行静态测试。

编译OpenHarmony

当前阶段,大部分的开发板源码还不支持在Windows环境下进行编译,如Hi3861、Hi3516系列开发板,因此需使用Ubuntu的编译环境对源码进行编译。

而在虚拟机中搭建Hi3861开发板环境步骤极为复杂,所以本文选择在OpenHarmony为开发者提供的Docker环境下进行编译,该方案在很大程度上简化了编译前的环境配置。伴随着越来越多的开发者使用Docker作为其开发环境,Klocwork也提供了Docker环境下静态分析方案支持。

搭建Docker环境

在使用Docker环境前需要先完成以下操作:
1、安装Docker。
2、获取OpenHarmony源码。
具体操作请见官方文档。

编译源码

完成Docker环境搭建并获取源码后,我们就可以对源码的wifiiot_hispark_pegasus工程进行编译了。具体步骤如下:

  • 进入源码根目录,执行hb set,根据提示选择wifiiot_hispark_pegasus工程。
    探究鸿蒙系统底座OpenHarmony 的代码质量改进:编译OpenHarmony | 搭建Docker环境 | 编译源码 | Klocwork静态分析 | 分析结果 | MISRA规则分析结果_第1张图片

  • 执行hb build -f编译wifiiot_hispark_pegasus工程。显示build success说明编译成功。
    探究鸿蒙系统底座OpenHarmony 的代码质量改进:编译OpenHarmony | 搭建Docker环境 | 编译源码 | Klocwork静态分析 | 分析结果 | MISRA规则分析结果_第2张图片

编译的成功证明环境搭建成功,进而可以顺利进行Klocwork静态分析。

Klocwork静态分析

Klocwork是一款针对开发人员生产力、SAST和DevOps/DevSecOps的最佳静态代码分析工具,支持C、C++、C#、Java、JavaScript、Python和Kotlin,可以与CI/CD工具、容器、云服务和机器配置集成,使自动化安全测试变得容易。

下面是Klocwork测试OpenHarmony代码的步骤。

  • 执行如下命令创建Klocwork工程openharmony_test:

    kwadmin --url http://192.168.9.116:8089/ create-project openharmony_test
    

Klocwork Validate平台是一个集中存储分析数据、趋势、度量和整个组织代码库配置的平台,可通过web浏览器访问。我们来到web端Validate中就可以看到刚才所创建的工程openharmony_test。

探究鸿蒙系统底座OpenHarmony 的代码质量改进:编译OpenHarmony | 搭建Docker环境 | 编译源码 | Klocwork静态分析 | 分析结果 | MISRA规则分析结果_第3张图片

  • 执行下面同步命令,将wifiiot_hispark_pegasus工程源码同步到Klocwork的openharmony_test工程中来。

    kwinject hb build -f
    
  • 分析工程
    执行分析前可在Validate中进行分析配置,勾选分析过程所需的规则。
    探究鸿蒙系统底座OpenHarmony 的代码质量改进:编译OpenHarmony | 搭建Docker环境 | 编译源码 | Klocwork静态分析 | 分析结果 | MISRA规则分析结果_第4张图片

配置完成后执行下面命令开始分析:

kwbuildproject --url http://192.168.9.116:8089/openharmony_test ./kwinject.out --tables-directory ./Openharmony/my_tables

显示下面结果表示分析成功。

探究鸿蒙系统底座OpenHarmony 的代码质量改进:编译OpenHarmony | 搭建Docker环境 | 编译源码 | Klocwork静态分析 | 分析结果 | MISRA规则分析结果_第5张图片

  • 将分析结果上传到Validate

    kwadmin --url http://192.168.110.110:8089/ load openharmony_test my_tables/
    

下面结果表示上传成功:
探究鸿蒙系统底座OpenHarmony 的代码质量改进:编译OpenHarmony | 搭建Docker环境 | 编译源码 | Klocwork静态分析 | 分析结果 | MISRA规则分析结果_第6张图片

分析结果

来到Validate查看Klocwork分析结果。
工程配置的详细信息如下:
探究鸿蒙系统底座OpenHarmony 的代码质量改进:编译OpenHarmony | 搭建Docker环境 | 编译源码 | Klocwork静态分析 | 分析结果 | MISRA规则分析结果_第7张图片

wifiiot_hispark_pegasus工程工1652个文件,共分析了1557个.c文件、95个系统头文件,源码共180720行,注释共138844行。分析模块类别为:C和C++分析、CERT分析以及MISRA分析。

MISRA规则分析结果

Category Details列举了wifiiot_hispark_pegasus工程对MISRA规则违规情况的汇总:
探究鸿蒙系统底座OpenHarmony 的代码质量改进:编译OpenHarmony | 搭建Docker环境 | 编译源码 | Klocwork静态分析 | 分析结果 | MISRA规则分析结果_第8张图片

违反Mandatory Rules规则数量排名前十的文件汇总:
探究鸿蒙系统底座OpenHarmony 的代码质量改进:编译OpenHarmony | 搭建Docker环境 | 编译源码 | Klocwork静态分析 | 分析结果 | MISRA规则分析结果_第9张图片

CERT规则分析结果

列举了wifiiot_hispark_pegasus工程对每条CERT规则违规情况的汇总:
探究鸿蒙系统底座OpenHarmony 的代码质量改进:编译OpenHarmony | 搭建Docker环境 | 编译源码 | Klocwork静态分析 | 分析结果 | MISRA规则分析结果_第10张图片

违反每条CERT规则数量排名前十的文件汇总:
探究鸿蒙系统底座OpenHarmony 的代码质量改进:编译OpenHarmony | 搭建Docker环境 | 编译源码 | Klocwork静态分析 | 分析结果 | MISRA规则分析结果_第11张图片

Validate合规报告

Validate可生成定制化合规报告。这里我选择生成pdf形式的Generic合规报告,列举出了违规情况详情、规则的分类与其对应的检查器、违反规则源码所在文件及行数。
探究鸿蒙系统底座OpenHarmony 的代码质量改进:编译OpenHarmony | 搭建Docker环境 | 编译源码 | Klocwork静态分析 | 分析结果 | MISRA规则分析结果_第12张图片
探究鸿蒙系统底座OpenHarmony 的代码质量改进:编译OpenHarmony | 搭建Docker环境 | 编译源码 | Klocwork静态分析 | 分析结果 | MISRA规则分析结果_第13张图片

下面我们选出部分违反的MISRA C 2012 with Amendment 2 (C11) certified与CERT规则进行简单介绍:
MISRA C 2012规则分为三种不同类别:Mandatory(强制)、Required(要求)和Advisory(建议)。

Mandatory Rules:

  1. FUNCRET.GEN: Non-void function does not return value.
  • 规则说明:FUNCRET.GEN检查器用于查找没有return语句的非void函数。
  • 违规源码:
    探究鸿蒙系统底座OpenHarmony 的代码质量改进:编译OpenHarmony | 搭建Docker环境 | 编译源码 | Klocwork静态分析 | 分析结果 | MISRA规则分析结果_第14张图片

int32_t OH_HashMapCreate函数是非空函数,但返回空值,所以此处违规。

2.UNINIT.STACK.MUST: Uninitialized Variable.

  • 规则说明:UNINIT.STACK.MUST检查器查找变量未初始化的行为。
  • 违规源码:
    第28行的变量vargs未初始化,所以此处违规。
    探究鸿蒙系统底座OpenHarmony 的代码质量改进:编译OpenHarmony | 搭建Docker环境 | 编译源码 | Klocwork静态分析 | 分析结果 | MISRA规则分析结果_第15张图片

Required Rules:

  • MISRA.LOGIC.SIDEEFF: Right operand in a logical ‘and’ or ‘or’ expression contains side effects.
  • 规则说明:&&和||运算符的右侧操作数的求值取决于左侧操作数的值。如果右边的操作数包含副作用,那么这些副作用可能会发生,也可能不会发生,这可能与程序员的预期相反。如果程序员依赖于发生的副作用,则对其中一个逻辑运算符的右手操作数的条件求值很容易导致问题。
  • 违规源码:
    探究鸿蒙系统底座OpenHarmony 的代码质量改进:编译OpenHarmony | 搭建Docker环境 | 编译源码 | Klocwork静态分析 | 分析结果 | MISRA规则分析结果_第16张图片

在162行中,将第118行的FOR_EACH_HC_VECTOR函数定义为一个for循环,而在表达式index < (vec).size(&(vec)) && \ (iter = (vec).getp(&(vec), index))中,&&操作符的右操作数中发生了赋值运算,导致该表达式具有副作用,所以此处违规。

Advisory Rules

MISRA.GOTO: Goto statement is used

  • 规则说明:不得使用goto语句,因为无限制地使用goto语句会导致程序的非结构化和极难理解。
  • 违规源码:
    探究鸿蒙系统底座OpenHarmony 的代码质量改进:编译OpenHarmony | 搭建Docker环境 | 编译源码 | Klocwork静态分析 | 分析结果 | MISRA规则分析结果_第17张图片

第669行使用了goto语句,所以此处违规。

CERT C Recommendations: CERT MSC13-C: Detect and remove unused values

VA_UNUSED.GEN: Value is Never Used after Assignment.
  • 规则说明:VA_UNUSED.GEN检查器查找分配给局部变量的值,这些值在下一次赋值或函数结束之前从未使用过。
  • 违规源码:
    探究鸿蒙系统底座OpenHarmony 的代码质量改进:编译OpenHarmony | 搭建Docker环境 | 编译源码 | Klocwork静态分析 | 分析结果 | MISRA规则分析结果_第18张图片

第141行对变量sessionKey赋值,但后面未使用该变量,所以此处违规。

CERT C Recommendations: CERT EXP00-C: Use parentheses for precedence of operation

  • CERT.EXPR.PARENS: The precedence of operators within expressions should be made explicit.
  • 规则说明:运算符在表达式中的优先级应该是显式的。
  • 违规代码:
    在这里插入图片描述

第395行的表达式if (altGroup != NULL && AddStringToJson(reqParam, FIELD_ALTERNATIVE, altGroup) != HC_SUCCESS)优先级不明确,所以此处违规。

总结

本文使用Klocwork对OpenHarmony部分代码进行静态测试,我们了解了OpenHarmony对于汽车行业常用编码规范的合规情况,同时也对MISRA与CERT编码规范有了初步的认识。通过此次分析我们不难看出,与过去的版本相比,OpenHarmony的代码质量在不断提升。但对于想将OpenHarmony应用于汽车行业的开发者来说,还需要根据汽车行业的要求,对OpenHarmony代码进行调整,以符合汽车功能安全与信息安全编码规范。

i出自《OpenHarmony - 应用开发入门指南》。

喜欢本篇文章的话记得评论点赞⭐收藏
➕更多技术文章直播课程,敬请持续关注北汇信息➕
⬇️业务咨询请私信北汇信息或在官网留言⬇️

你可能感兴趣的:(软件测试,静态代码测试,#,Klocwork,harmonyos,汽车,华为,鸿蒙,代码合规性)