[RTEMS Project] #3710: Improve Coverity Scan Integration

[RTEMS trac]

#3710: Improve Coverity Scan Integration
-------------------------------------------+---------------------------
 Reporter:  Gedare Bloom                   |       Owner:  Gedare Bloom
     Type:  project                        |      Status:  assigned
 Priority:  normal                         |   Milestone:  Indefinite
Component:  admin                          |     Version:
 Severity:  normal                         |  Resolution:
 Keywords:  SoC,ecosystem, testing, small  |  Blocked By:
 Blocking:                                 |
-------------------------------------------+---------------------------
Description changed by Gedare Bloom:

Old description:

> The goal of this project is to create better workflows to incorporate
> static analysis using Coverity Scan into the RTEMS development and
> release cycle.
>
> Coverity Scan is a static analyzer that can identify various types of
> potential software defects. Coverity offers free use of this analyzer for
> free software projects. Issues identified for RTEMS are at
> https://scan.coverity.com/projects/rtems.
>
> Coverity Scan identifies POTENTIAL issues. Some may be real bugs. Others
> may indicate that Coverity Scan does not have full awareness of the
> program life. For example, memory allocated during RTEMS initialization
> may appear to be leaked because it is never freed, but this is deliberate
> and the issue marked as such in Coverity Scan.
>
> You can get an account on [https://scan.coverity.com Coverity Scan] and
> request access to the [https://scan.coverity.com/projects/rtems RTEMS
> Project] to contribute.
>
> The current process for dealing with Coverity Scan is entirely manual.
> See, for example, [wiki:GCI/Coding/CoverityIssues Google Code-In task
> instructions for Coverity]. This manual process has several drawbacks.
> The purpose of this GSoC Project would be to simplify the process of
> working with Coverity, and to automate it where possible. We have
> identified two starting directions, and encourage interested students to
> brainstorm on other ways to improve the Coverity Scan integration.
>
> **Reducing False Positives**
> Static analysis suffers from a high number of false positives. Coverity
> Scan provides two methods for removing false positives.  First is by
> creating an optional ''modeling file'' to accommodate for special cases
> where the data flow analysis breaks, for example due to missing functions
> that are linked outside the analyzed source code. A modeling file usually
> is used to identify functions that terminate execution, allocate memory,
> or free memory. Second, source code annotations in specially formatted
> comments can also be used to suppress warnings. This project should
> determine which approach to take, and design/implement a path forward.
>
> **Testing Fixes**
> Since security tools tend to be costly in terms of time or compute
> resources, they are normally run on nightly or even weekly builds rather
> than on every commit as done for typical continuous integration (CI). It
> can be tedious to merge commits to the development master and trigger a
> scan to determine if the issue has been fixed. Instead, we would like to
> develop fixes and trigger Coverity Scan as needed (subject to staying
> within the allowed scan rates). Coverity Scan integrates with Github and
> can be triggered to scan by merging new code to a specific git repository
> branch. As a first step, a special 'coverity' branch could be created for
> scanning commits that are pushed there, so that developers who are
> testing changes can work through the coverity branch before merging fixes
> into the master. Alternate solutions should be discussed with any
> mentors.
>
> **Coding Rule Scans**
> Investigation on this direction is needed. Coverity supports for example
> a couple of MISRA rules:
> https://www.synopsys.com/content/dam/synopsys/sig-assets/datasheets
> /coverity-misra-standards-ds-ul.pdf
>
> These rules are not enabled currently. Would it be possible to enable a
> subset of these rules in our current setup?

New description:

 The goal of this project is to create better workflows to incorporate
 static analysis into the RTEMS development and release cycle. This project
 can be done with other static analyzers such as Codiga

 == Mentors ==

 Gedare Bloom, Joel Sherrill

 == Skills ==

 Python, Data manipulation

 == Difficulty ==

 This is a small (175-hour) project of medium difficulty.


 == More Information ==

 Coverity Scan is a static analyzer that can identify various types of
 potential software defects. Coverity offers free use of this analyzer for
 free software projects. Issues identified for RTEMS are at
 https://scan.coverity.com/projects/rtems.

 Coverity Scan identifies POTENTIAL issues. Some may be real bugs. Others
 may indicate that Coverity Scan does not have full awareness of the
 program life. For example, memory allocated during RTEMS initialization
 may appear to be leaked because it is never freed, but this is deliberate
 and the issue marked as such in Coverity Scan.

 You can get an account on [https://scan.coverity.com Coverity Scan] and
 request access to the [https://scan.coverity.com/projects/rtems RTEMS
 Project] to contribute.

 The current process for dealing with Coverity Scan is entirely manual.
 See, for example, [wiki:GCI/Coding/CoverityIssues Google Code-In task
 instructions for Coverity]. This manual process has several drawbacks. The
 purpose of this GSoC Project would be to simplify the process of working
 with Coverity, and to automate it where possible. We have identified two
 starting directions, and encourage interested students to brainstorm on
 other ways to improve the Coverity Scan integration.

 **Reducing False Positives**
 Static analysis suffers from a high number of false positives. Coverity
 Scan provides two methods for removing false positives.  First is by
 creating an optional ''modeling file'' to accommodate for special cases
 where the data flow analysis breaks, for example due to missing functions
 that are linked outside the analyzed source code. A modeling file usually
 is used to identify functions that terminate execution, allocate memory,
 or free memory. Second, source code annotations in specially formatted
 comments can also be used to suppress warnings. This project should
 determine which approach to take, and design/implement a path forward.

 **Testing Fixes**
 Since security tools tend to be costly in terms of time or compute
 resources, they are normally run on nightly or even weekly builds rather
 than on every commit as done for typical continuous integration (CI). It
 can be tedious to merge commits to the development master and trigger a
 scan to determine if the issue has been fixed. Instead, we would like to
 develop fixes and trigger Coverity Scan as needed (subject to staying
 within the allowed scan rates). Coverity Scan integrates with Github and
 can be triggered to scan by merging new code to a specific git repository
 branch. As a first step, a special 'coverity' branch could be created for
 scanning commits that are pushed there, so that developers who are testing
 changes can work through the coverity branch before merging fixes into the
 master. Alternate solutions should be discussed with any mentors.

 **Coding Rule Scans**
 Investigation on this direction is needed. Coverity supports for example a
 couple of MISRA rules:
 https://www.synopsys.com/content/dam/synopsys/sig-assets/datasheets
 /coverity-misra-standards-ds-ul.pdf

 These rules are not enabled currently. Would it be possible to enable a
 subset of these rules in our current setup?

--

--
Ticket URL: <http://devel.rtems.org/ticket/3710#comment:6>
RTEMS Project <http://www.rtems.org/>
RTEMS Project