Polyspace应用：Bug Finder检测代码漏洞

1 Bug Finder概述

Polyspace®Bug Finder，顾名思义是一个查找Bug的工具。它可以识别C和C++嵌入式软件中的运行时错误，并发问题，安全漏洞和其他缺陷。
Bug Finder采用语义分析技术检测软件Bug，因此只需要提供源代码，不需要测试用例，也不需要运行代码就能检测出软件Bug。在软件开发过程的早期即可发现漏洞并修复。
另外，Bug Finder也可以检查软件是否符合编码规则标准，例如MISRAC®，MISRA®C ++，JSF®++，并生成检查报告。

2 Bug Finder配置流程图解

本章节通过一个例子演示Bug Finder检查代码漏洞的一般过程，并简要说明一些注意事项。在不同项目中的配置根据实际情况会有所区别。
本例在Polysapce2018a环境下进行。

2.1 准备源代码

首先需要准备被检测的源代码。在汽车嵌入式软件开发流程中，通常是分析模型生成的代码和手写代码。
本文中，自己创建一个带有Bug的C代码demo.c，内容如下：

#include 

void fibonacci(void)
{
    int i;
    int fib[10];
 
    for (i = 0; i < 10; i++) 
       {
        if (i < 2) 
            fib[i] = 1;
         else 
            fib[i] = fib[i-1] + fib[i-2];
       }

    printf("The 10-th Fibonacci number is %i .\n", fib[i]);   
    /* Defect: Value of i is greater than allowed value of 9 */
}

代码中定义了一个10维数组fib，因此它合法的索引应该是0~9。在中间的一次for循环后，整形变量i的数值累加到了10，然后printf语句又引用了fib[i]，也就是说把10作为fib的索引。这是一个常见的数组下标越界的错误。后文会用Bug Finder将它检测出来。

2.2 新建工程

1）打开Polyspace，File–New Project打开新建工程窗口。在创建工程窗口中输入Project Name，Version，Author。工程路径可以默认，也可以去掉勾选Use default location，选择自定义路径。然后点击Next。

2）添加头文件和源文件
接下来的窗口中要选择存放源文件后头文件的文件夹。选中左侧Project Source Files，点击右侧的Browse，选择存放c文件demo.c的文件夹src，点击Open，该路径会出现在Select Source Folder中。

此时还并没有添加进来。需要勾选Add recursively并点击下方的Add Source Folders，然后C代码会被添加到左侧的树状图中。

同理，在Project Include中添加头文件。本示例中没有头文件，如果有头文件但是漏了添加，分析会报错。
3）完成添加后Finish，在Polyspace左侧的Project Browser中会显示项目名demo，Project Source Files文件夹，以及自动新建一个Module_1。Module_1下有一个Module Source Files和Configuration文件夹。这里可以把Module理解成一个检查任务，每个Module（模块）可以根据不同的参数配置卡来检查项目中的某些C文件或所有C文件。

4）同时，在之前选择的项目文件夹路径下，会出现项目文件demo.psprj和Module_1文件夹

2.3 配置项

点击Project Browser Configuration下的demo，就可以在右侧看到的配置栏。下面会说明常用配置的含义。

1）Target&Compiler
这是针对不同的目标处理器和编译器的配置。其中，配置目标语言为C语言，Compiler和Target Processor type根据项目实际来选择即可。这里主要是因为不同的处理器对应的数据类型长度会有区别。本例没有要求，默认即可。其余选项一般默认即可。

2）Macros
宏相关定义。用于宏定义和屏蔽宏，相当于在代码中定义的宏。根据需要来添加相关的宏即可。

3）Enviroment Settings
环境设置。
其中Code from DOS or Windows file system (-dos)表示代码来源，由于是win7系统，此项需要勾选。
Stop analysis if a file does not compile 表示如果编译不通过，则分析中止。此项也要勾选上。

4）Inputs&Stubbing
输入和插桩。
这一项可以限制变量范围，插桩等。属于高级玩法，笔者也不太了解。
5）Coding Rules&Coding Metrix
检查代码规范
右边可以勾选需要检查的代码规范。并且通过勾选Metrix生成代码规范报告等。本例不进行设置。

6）Bug Finder Analysis
这一部分非常重要，这里可以看到BugFinder的所有检查项，并且可以选择custom来自定义检查项。本例默认即可。

7）Reporting
报告部分必须要勾上。

至此，Bugfinder的一些必要的配置项就已经配置完毕。

2.4 运行并生成报告

在运行之前，首先勾选上Create New Bug Finder Result Folder，这样每次运行都会生成一个新的报告，不会覆盖。

然后点击Run Bug Finder运行检测。右侧会显示分析进度。

2.5 分析结果查看

运行完毕后，会自动切换到报告页。报告页包含以下三部分：
1）Result List列出了所有的分析结果，包括Bug类型，严重等级和处理状态等。

2）Result Details显示了某条Bug的详细信息。

3）Dashboard显示了分析结果概要，包括严重等级饼状图，文件数量等。

在左边的Result List中找到Static Memory下的Array access out of bounds，该问题分类就是我们C文件中故意设置的数组下标越界的Bug，点击该条Bug，会在右侧显示详细信息。

右侧的Result Details中也给出了具体的说明。
“Attempt to access to array element 10. Valid index range: [0 … 9].”
意思是索引范围应该是0~9，但是代码试图取第10个元素。

在Result Detail下方可以切换到Source窗口，该窗口定位到了该Bug所在的具体的位置，第16行。

至此，就已经完成了一个Bug Finder 的分析流程。

3 总结

Bug Finder的环境建立流程比较简单，主要需要关注的点在于2.3-6中的检查项分类，以及检查完毕后对结果的研究和处理。后续会研究各个不同的检查项内涵，并总结Bug可能产生的地方以及改进方法。

>>返回个人博客总目录