Skip to main content


Making CodeChecker Ready for Kernel Developers

By Blog

Contributed by Jay Rajput, ELISA 2020-2021 Mentee

The following is a brief report of my project carried out as a part of the ELISA/LFX mentorship program. 

The primary goal of the mentorship is to extend the Codechecker report converter to support a variety of tools such as: 

  • Coccinelle
  • Smatch
  • Sphinx
  • Kernel-Doc
  • Sparse


Many developers contribute to the Linux kernel. And these kernel developers are not exempted from typical programming errors in their patches, such as  null pointer referencing, array buffer overflow.  Thus, the kernel community has developed some code analyzers, such as sparse, coccinelle and smatch, for reporting such potential error patterns.

The tools mentioned above are some of the well-known tools for analyzing the code of Linux kernel. These tools however only print the warnings and errors on the command-line interface.Below is the output of some example: 

arch/x86/kernel/signal.c:338:9: warning: incorrect type in argument 1 (different address spaces)arch/x86/kernel/signal.c:338:9:    expected void const volatile [noderef] __user *ptrarch/x86/kernel/signal.c:338:9:    got unsigned long long [usertype] *arch/x86/kernel/signal.c:338:9: warning: cast removes address space ‘__user’ of expressionarch/x86/kernel/signal.c:338:9: warning: cast removes address space ‘__user’ of expressionarch/x86/kernel/pci-dma.c:20:26: warning: symbol ‘dma_ops’ was not declared. Should it be static?arch/x86/kernel/pci-dma.c:27:5: warning: symbol ‘panic_on_overflow’ was not declared. Should it be static?arch/x86/kernel/pci-dma.c:31:5: warning: symbol ‘iommu_merge’ was not declared. Should it be static?

It is tedious for developers to look up and keep track of all the errors through the text file/terminal. Manually searching the line of the error also becomes a tedious job.  Furthermore, sending the findings or comments to another developer is not feasible. Thus, it becomes very difficult for developers to keep track of all the errors. CodeChecker offers a nice and convenient web interface for viewing all the errors and even giving them some tags such as confirmed, false positive, etc. 

CodeChecker’s report converter tool provides an interface for viewing all the reports produced by the code-analyzing tools in a nice and simple web interface. It also provides the functionality to comment and mark the bugs as confirmed, false positive, etc. Thus, I wanted to extend the report converter to the tools mentioned above and also implement the functionality for importing and exporting the changes to and from CodeChecker. 

Report Converters for Analyzer Tools

My first and primary task was to create report converters for the tools mentioned above. These report converters would parse the output of tools, using regex into the format:  

File PathLine NumberColumnError MessageChecker Name

Once the report converter parses the output file of the tools it stores them into plist files which can be opened and viewed into the browser. All the plist files are stored in a folder specified by the user while running the report converter. 

CodeChecker also provides a feature to store these plist files into the CodeChecker server and then we can perform multiple operations on the reports like marking the status( confirmed, false positive, etc) and adding comments on each bug. 

Importer and Exporter for CodeChecker

The CodeChecker command-line interface provides a variety of options for listing, filtering all the runs/results present in the CodeChecker server. I have added two more commands to the CodeChecker CLI for Importing and Exporting the results to and from the CodeChecker Server.

The Export command lets the user export the findings i.e comments and review the status of one or more reports specified by the user. Below is the sample output of the reports: 

{    “comments”: {        “c54004ae9ecfb34b396b46d9e08c4291”: [            {                “id”: 7,                “author”: “Anonymous”,                “message”: “This is a confirmed Bug here”,                “createdAt”: “2020-11-28 00:05:02.034035”,                “kind”: 0            },            {                “id”: 6,                “author”: “Anonymous”,                “message”: “I am doubtful about this bug”,                “createdAt”: “2020-11-28 00:01:48.190914”,                “kind”: 0            }     },   “reviewData”: {        “00eab39f7bb399d446e0794025ab3958”: {            “status”: 1,            “comment”: “This is for the exporter function testing”,            “author”: “Anonymous”,            “date”: “2020-12-20 23:01:02.669476”        },    }}

The Importer command is used for importing the comments and review statuses sent by another user into CodeChecker Server. For importing the comments, for each comment, we check if the date, kind, and the message of the existing comment in the server and the incoming report. If any of them is different, we replace the existing comment with the incoming comment. Similarly, for review status, if the date of the review status is different, then we update the review status in the server with the incoming review. 

Use Case of Review Exchange

Consider there are two users of your System, John, and Maria. Both of them have the output of Coccinelle on the Linux kernel. 

They run the report converter of coccinelle on the output as:

report-converter -t coccinelle -o ./codechecker_coccinelle_reports ./coccinelle_reports.out

The details of how to use the report converter of all tools can be found in Report Converter Readme

They store the findings into the Codechecker server using the command:

CodeChecker store ./codechecker_coccinelle_reports -n coccinelle

Assume that there are 10 errors in coccinelle with report ids 1 to 10. John performs the following changes:

  1. Marks report 1 as false positive and comments “This is not an actual bug
  2. Marks report 2 as Confirmed.
  3. Comments on report 3 “I am not sure about the status of this bug”

Maria makes the following changes in this copy on his machine:

  1. Marks report 3 as  Confirmed and comments “This is a confirmed bug
  2. Comments on report 4 “This error needs to be handled

Now, John runs the export command and obtains the json with the name coccinelle.json

CodeChecker cmd export -n coccinelle 2>/dev/null | python -m json.tool > coccinelle.json

John sends the obtained file to Maria via email or any other communication medium. Maria downloads this file and imports the findings into his CodeChecker server:

CodeChecker cmd import -i coccinelle.json

Now, the reports in Maria’s server will be:

Report 1:Tag: False PositiveComment: This is not an actual bugReport 2:Tag: ConfirmedReport 3:Tag: ConfirmedComments: [I am not sure about the status of this bug, This is a confirmed bug]Report 4:Comment: This error needs to be handled

Pull Requests

  • Coccinelle Parser: Coccinelle report converter tool for parsing coccinelle output of kernel sources.

  • Smatch Parser: Smatch report converter tool for parsing Smatch output of kernel sources.

  • Kernel-Doc Parser: Kernel-Doc report converter tool for parsing Kernel-Doc output of kernel sources.

  • Sphinx Parser: Sphinx report converter tool for parsing Sphinx output of kernel sources.

  • Fix CodeChecker’s cmd results: Comments in the cmd results command were not fetched properly and even showed empty strings in some cases. Added a separate comments section to the details of the results command.

  • Importer & Exporter command: Exporter command for exporting the comments and review statuses for given or all runs into a json file. Importer command for importing the findings sent by another developer in a json file.

  • Sparse Parser: Sparse report converter tool for parsing Sparse output of kernel sources.

Future Work

  • Currently, the import and export commands of CodeChecker are limited only to the Command Line Interface. I would like to implement a feature to make these available in the Web Interface as well. 
  • I would like to extend CodeChecker’s report converter tools to provide proper warning classes for all the report converters.
  • I would like to add support for multiple users within a single instance of CodeChecker coming to different assessments and then moderating or reviewing them in some controlled way.


I would like to thank my mentor Lukas Bulwahn for giving me this opportunity and helping me come up with workflows and ideas for fulfilling my goals. My heartfelt gratitude towards the maintainers of CodeChecker especially Márton Csordás for being patient with me during code reviews and providing his valuable feedback. 

A look back at the 6th ELISA Workshop

By Blog

By Elana Copperman at Mobileye, Philipp Ahmann at ADIT

More than 120 registered participants, half of them first time joiners, can look back to 3 days of the 6th ELISA workshop, again held virtually due to the pandemic. It was filled with various sessions focusing on, of course, Linux and safety, but also on medical and automotive use cases as well as which role testing, tooling and development processes play to achieve the ELISA deliverables. And these ELISA deliverables should lead to making it easier to enable Linux in safety applications. This is the actual mission of the ELISA project

As this is the 3rd time that ELISA held a virtual workshop you can see the learnings from the past. Virtual get together, multiple hosts and cloud recordings of sessions support the rich experience of the workshop. 

The virtual workshop also reduces the hurdle to participate, especially as workshops are open for all and free of charge. This led again to a higher number of average participants per session compared to our previous workshops and confirms the interest in a functional safety product based on LInux. 

During the workshop, besides the regular content such as working group updates and goal settings also completely new areas of interest were presented by members and external speakers. Topics included cybersecurity expectations in the automotive world, code coverage of glibc and Intel’s Linux test robot. The impact to the Linux (Kernel) community was addressed by talks about measuring code review in Linux Kernel, statistics on patch integration or the kernel testing reference process.

The Safety architecture and automotive work groups agreed on their communication interface by sharing requirements and concepts on the Linux architecture. This enabled the momentum these two groups needed to make progress on their goals. Finally, collaboration and contributions from all our ELISA members  resulted in publishing source code and documentation on ELISA github

Tuesday Feb 2 2021

The first day began with updates from the ELISA Working Groups. As ELISA continues to chart  new territory, the collaboration between WGs is being defined.  In addition to the new interfaces described by Philipp Ahmann between the Architecture and Automotive WGs, we are beginning a joint effort between the Architecture and Development Process WG to set up a database of kernel configurations/features amenable for safety analysis.

In addition, two presentations from Intel/Mobileye focused on static analysis for compliance with MISRA and proposed test strategies for safety qualification and FFI evidences.

Both talks were very insightful, with a lot of feedback from the audience and participants turning the end of the day really into a workshop feeling like a workshop. It includes exactly the discussion which is needed when working on a Linux system ready for safety applications.

Looking forward to an even more exciting day tomorrow!

Wednesday Feb 3 2021

Andreas Gasch and Joyabrata Ghosh kick started today’s sessions with a presentation on Cybersecurity Expectations in the Automotive World.  It certainly was interesting to see how the Cybersecurity community is coming around full circle to align with the standards, processes, documentation and management much closer to what we work with in the safety community.  Perhaps in the future, we will (eventually) see Cybersecurity and Safety join forces for risk management and qualification.

Eli Gurvitz then provided a report from the Code Coverage Metrics for GLibC mentorship project (by Ashutosh Pandey) on code coverage analysis for glbc, generating quite some ripples and interest in joining the “Fun and Happiness” group aka Tool Investigation and Code Improvement Sub-WG for further work in this area.   Kudos, Ashutosh, for a great job!


Spirited discussions came up in the session on how to handle documentation in git and github. It could be clearly seen that the interest in a proper version controlled documentation repository is needed, but the standard format, if reST, markdown or LaTeX could not be concluded and reminded on the starting phase of ELISA. With the Automotive and Medical Device WGs starting to add their documents to the ELISA git repository, ELISA is taking a good iterative approach to making their work visible and structured to meet the expectations of safety experts as and the safety standards.

Day #2 was wrapped up with an extended session on defining kernel configurations for safety critical applications.  Focused on the “top down” alignment of the CONFIGs and their analysis within the context of Shuah’s work on CWE classifications for safety.  Medium term (~6 month) goal to establish a basic set of configurations and document effectively on how integrators can potentially use those configurations in safety analysis of their specific use case.  There are a lot of challenges in this area.

Thursday Feb 4 2021

The 3rd workshop day is typically focused on setting goals for the next 3 months. In addition, ELISA members spend time collaborating in long deeper dive Development Process WG’s working sessions. These sessions actually make the turn from the conference character to a workshop character. Also other sessions such as the goal settings for the next quarter leave enough room to have alignment among the active ELISA members including the Technical Steering Committee. These sessions see fewer first time attendees. We encourage new members to attend the goal setting sessions in the hope that they might be able to engage and collaborate with us on achieving our goals for the next quarter. We sincerely hope all the first time attendees will join us in our upcoming 7th workshop in May 2021.

Closing thoughts

Recapping the three days of this workshop, it is nice to see that the ELISA project is making steady progress and providing enough technical content so that the different working groups start to align and work together more effectively. The Development Process WG has become large enough to spin out smaller teams to focus on WG goals. The ELISA workshops are instrumental in collaborating on discussing current work and in collecting feedback to gain valuable insights and generate new ideas.

ELISA Workshop #6 Virtual February 2-4, 2021

By Blog, Workshop

The ELISA Workshop #6 will be held over 3 days, February 2-4, 2021.

Once again the ELISA technical community will gather virtually to continue advancing on topics and work relevant to functional safety and safe linux applications. The ELISA Workshop series are focused on education and outreach for new community members, exchanges of ideas and feedback from the linux kernel and safety communities, as well as productive collaboration to make tangible progress toward achieving the mission and goals of the ELISA Project.


Workshop registration is now closed.

All workshop attendees must register in order to receive session joining details.

Please contact for late registration requests or any other workshop related questions.

Session Schedule (UTC)

Day 1: Tuesday, February 2, 2021

12:00 – 12:30 Welcome and ELISA Strategy (Shuah Khan, Kate Stewart)

12:30 – 13:00 Summary of Safety Architecture WG Activities (Gab Paoloni)

13:00 – 13:30 Summary of Automotive WG Activities (Jochen Kall)

13:30 – 14:00 Summary of Development WG Activities (Elana Copperman)

14:00 – 14:30 Introduction of Tool Investigation and Code Improvement Subgroup (Lukas Bulwahn)

14:30 – 15:00 Summary of Medical Devices WG (Kate Stewart)

15:00 – 16:00 Effective Use of MISRA Checkers (Gabriele Paoloni, Eli Gurvitz, Roberto Paccapeli, Maurizio Iacaruso)

16:00 – 17:00 Testing Strategy for Safety Qualification and FFI Evidences (Gabriele Paoloni, Eli Gurvitz)

Day 2: Wednesday, February 3, 2021

10:30 – 11:30 Cybersecurity Expectations in the Automotive World (Andreas Gasch)

11:30 – 12:30 Code Coverage Analysis for GLibC (Eli Gurvitz, Ashutosh Pandey)

12:30 – 13:30 Intel’s Linux Test Robot (Eli Gurvitz, Oliver Sang, Philip Li)

13:30 – 14:00 Linux in Basic Safety Application White Paper Update (Jason Smith)

14:00 – 15:00 Manage ELISA Documenation in GitHub (Paul Albertella, Pete Brink, Jochen Kall, John MacGregor, Jason Smith)

15:00 – 15:30 Updates on Measuring Code Review in Linux Kernel (Basak Erdamar, Lukas Bulwahn)

15:30 – 16:00 Lightening Talks (Lukas Bulwahn)

16:00 – 18:00 Kernel Configuration for Safety Critical Applications (Shuah Khan, Elana Copperman)

Day 3: Thursday, February 4, 2021

12:00 – 12:30 To Whom It May Concern, Please Integrate My Patch (Pia Eichinger, Lukas Bulwahn, Ralf Ramsauer, Wolfgang Mauerer)

12:30 – 13:30 Networking / Social Mixer (those who express interest will be sent a separate meeting invite)

13:30 – 14: 30 Goal Setting for Next Quarter (Shuah Khan)

14:30 – 15:00 Workshop Wrap-up (Shuah Khan, Kate Stewart)

15:00 – 17:00 Kernel Testing Reference Process and Follow-ups for ELISA (Elana Copperman, Kate Stewart, Paul Albertella, Pete Brink)


Have questions about the ELISA Workshop? Please contact

ELISA Workshop #5 Virtual September 29 – October 1

By Blog, Workshop

The ELISA community will collaborate virtually September 29 to October 1.

Over twenty sessions with topics ranging from Working Group updates to deep dives into linux technologies, follow-ups from Linux Plumber Conference, and extended collaborative working sessions are being planned over the course of the 3 days.


Registration closed at 5pm EDT, Thursday, September 24th.

Attending Workshop Sessions

Please go to Workshop Session Calendar for session virtual meeting details.

Note: Only registered participants are sent session calendar invites/notifications and access the session calendar.

Session Schedule (UTC)

Day 1: Tuesday, September 29

12:00 – 12:30 Welcome to Workshop (Shuah Khan and Kate Stewart)

12:30 – 13:30 Summary of Safety Architecture WG Activities (Gab Paoloni)

13:30 – 14:00 Linux in Basic Safety White Paper Update (Jason Smith)

14:00 – 15:00 stress-ng Update (Colin King and Eli Gurvitz)

15:00 – 16:00 Software Engineering Competency Model (Peter Brink)

Day 2: Wednesday, September 30

11:00 – 12:00 Introduction to Smatch (Dan Carpenter)

12:00 – 12:30 Summary of Automotive WG Activities (Jochen Kall)

12:30 – 13:00 Summary of Medical Devices WG Activities (Kate Stewart)

13:00 – 14:00 EDAC Support in Linux and Implications for Use in FuSa system (Gab Paoloni, Chris Temple, Corey Minyard)

14:00 – 15:00 Kernel Documentation (Jon Corbet)

15:00 – 15:30 An Introduction to MISRA C:2012 (Roberto Bagnara)

15:30 – 16:00 Preliminary Analysis of a Linux Configuration WRT Some MISRA C:2012 Mandatory Guidelines (Roberto Bagnara)

16:00 – 16:30 Continuing Discussion from Linux Plumbers Dependability Session (Shuah Khan, Kate Stewart, Lukas Bulwahn)

17:00 – 18:00 Mining Kernel Development Data (Başak Erdamar)

Day 3: Thursday, October 1

11:00 – 12:00 Safety Analysis of Linux Powered Open Source Medical Device (Shaun Mooney)

12:00 – 13:00 Summary of Kernel Development WG Activities (Elana Copperman)

13:00 – 14:00 Qualification of Linux for Autonomous Driving Applications Targeting ASILB (Gab Paoloni)

14:00 – 15:00 Goal Setting for Next Quarter (Shuah Khan)

15:00 – 15:30 Workshop Wrap-up (Shuah Khan and Kate Stewart)

15:30 – 18:00 Extended Working Session on Mapping Safety Standards to Kernel Evidence (Elana Copperman)

Three Google Summer of Code students accepted to contribute to Linux kernel verification

By Announcement, Blog

The project proposals of three Google Summer of Code students contributing to Linux kernel verification have been accepted. The three students, Isaac Avram (Izzy) , Mark Balantzyan, and Himanshu Jha have proposed the following topics:

  1. Isaac Avram (Izzy) : Extending Coccinelle with Complex Types
  2. Mark Balantzyan: Analysing Race Conditions in the Linux Kernel
  3. Himanshu Jha: Applying Clang Thread Safety Analyser to Linux Kernel

They will be mentored by Julia Lawall, Alexey Khoroshilov and Lukas Bulwahn, respectively. These three Google Summer of Code projects are governed under the umbrella of the Linux Foundation and the projects are contributing to generally relevant activities for the ELISA Project.

More specifically, one of the building blocks to the safety compliance argumentation in the ELISA Project is the research, investigation, experimentation, use and establishment of verification measures and tools in the Linux kernel development. The ELISA Project embraces the activities in these projects and is looking forward to the projects’ results and the inclusion of new members to the verification activities around the Linux kernel development through the Google Summer of Code student program.