[RTEMS Project] #3710: Improve Coverity Scan Integration
trac at rtems.org
Thu Feb 28 21:06:29 UTC 2019
#3710: Improve Coverity Scan Integration
Reporter: Gedare | Owner: Gedare
Type: project | Status: assigned
Priority: normal | Milestone: Indefinite
Component: admin | Version:
Severity: normal | Keywords: SoC,testing
Blocked By: | Blocking:
The goal of this project is to create better workflows to incorporate
static analysis using Coverity Scan into the RTEMS development and release
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
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
for special cases where the data flow analysis breaks, for example due to
missing functions that are linked outside the analyzed source code. A
file usually is used to identify functions that terminate execution,
memory, or free memory. Second, source code annotations in specially
comments can also be used to suppress warnings. This project should
determine which approach to take, and design/implement a path forward.
Since security tools tend to be costly in terms of time or compute
they are normally run on nightly or even weekly builds rather than on
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
integrates with Github and can be triggered to scan by merging new code to
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.
Ticket URL: <http://devel.rtems.org/ticket/3710>
RTEMS Project <http://www.rtems.org/>
More information about the bugs