Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== GSoC Projects around Enabling Linux in Safety Applications (ELISA) ======

[[:gsoc:google-summer-code-2020|Main GSoC Linux Foundation page: How to apply, deadlines, other workgroups, ...]]

To use Linux in high-integrity regulated environment, such as safety-critical systems, security systems or systems subject to other regulatory norms, it requires to show evidences that Linux has a high software quality. High software quality is roughly assessed by two classes of measurements:

  * Observation, Measurement and Assessment of the Software Development Process and Practices
  * Verification, Analysis and Assessment of the Software Artefact

The Google Summer of Code Projects are activities that contribute to those two fields of work.

Primary mentoring contacts: Lukas Bulwahn, lukas.bulwahn at gmail.com; Julia Lawall, julia.lawall at lip6.fr; Nicholas Mc Guire, der.herr at hofr.at; Ralf Ramsauer, ralf.ramsauer at oth-regensburg.de

==== Some background on Enabling Linux in Safety Applications ====

The SIL2LinuxMP project is an collaborative research project to provide procedures and methods to qualify Linux on a multi-core embedded platform at safety integrity level 2 (SIL2) according to IEC 61508 Ed 2.

Some more information on the SIL2LinuxMP project is available here:

http://www.osadl.org/SIL2LinuxMP.sil2-linux-project.0.html

http://events17.linuxfoundation.org/sites/events/files/slides/2017-10-24_ELCE-2017_Bulwahn_Safety-Critical-Linux_v1.2-presentation.pdf

https://www.youtube.com/watch?v=1eyJ6dAqMmg


The SIL2LinuxMP project has ended at the end of 2018 and the activities around Linux in safety-critical systems will be continued in a new organisational structure in 2019.

====== Student Project Proposals 2020 ======


==== Fuzzing System Calls against POSIX Specifications ====

The fuzzer for system calls, syzkaller, is used to detect kernel crashes and issues in the kernel's internal state, but with its current setup, it is not able to detect if a system call provides wrong output, i.e., output that does not follow the POSIX specification. The Linux Test Project has some basic tests that some of the POSIX specification. The GSoC student project proposal should describe how you would implement a fuzzer to fuzz system calls against the POSIX specifications, possibly making use of the aforementioned resources. The GSoC student project proposal should sketch how this would implemented, it would be best to provide an example and foreseen challenges and explain which the first investigations and design decisions need to be done and provide a first working assumption on those design decisions.

Main contact person for this project proposal: Lukas Bulwahn, lukas.bulwahn at gmail.com

==== Patch Trace Analysis with PaStA ====

The PaStA tool, developed by Ralf Ramsauer, relates patch emails sent on the mailing lists to commits in the git repository. This allows to analyse the development process on the mailing list, measure some interesting metrics on the development, and identify outliers with respect to some central properties.

The issue tracker, https://github.com/lfd/PaStA/issues, provides a good overview of possible student activities in a GSoC project related to PaStA. A student start look into those issues and determine a suitable selection of tasks and goals from that issue tracker that can be handled within the timeframe of the GSoC project. A project proposal should breakdown the goals stated in the issue tracker to a more detailed plan of activities, needed extensions of PaStA and the implementation tasks. 

Main contact person for this project proposal: Ralf Ramsauer, ralf.ramsauer at oth-regensburg.de

==== Handling Complex Types and Attributes in Coccinelle ====

Coccinelle, developed by Julia Lawall and her group, is a program matching and transformation engine which provides the language SmPL (Semantic Patch Language) for specifying desired matches and transformations in C code.
The GSoC project proposal would be to improve the management of complex types and attributes (const, __user, etc) in the program matching and transformation tool Coccinelle.
Currently, complex types are represented incorrectly, which makes it impossible to match against
them in a general way.  Various kinds of attributes are increasingly used in Linux kernel code, and it is important to be able to check these annotations and add them where they are missing.
This project is relevant to Linux, Zephyr and many more applications.

Main contact person for this project proposal: Julia Lawall, julia.lawall at lip6.fr

==== Develop Methods for Tracking Tool Analysis Findings over Time ====

We use a number of tools, checkpatch.pl, coccinelle scripts, sparse, etc. and these tools report certain findings.
While the valid ones are addressed by the kernel developers, the invalid tool findings are manually assessed and not acted upon. Over time with addressing the valid findings, the proportion of invalid findings increase compared to newly appearing valid findings, as invalid findings of those tools are not marked and tracked over the various versions.

In this GSoC project, the student should work out methods and tools to track the tool findings and make these tools useful in the Linux kernel community.
 
Required Knowledge:
  - Required: Very good knowledge of C, skill to READ AND UNDERSTAND source code in the Linux kernel in independent work
  - Required: Very good knowledge of python
  - Required: Good understanding of git
  - Recommended: Some understanding of static analysis tools
  - Recommended: Some understanding of coccinelle

Main contact person for this project proposal: Lukas Bulwahn, lukas.bulwahn at gmail.com

==== Apply Facebook Infer to Linux kernel source code ====

Task: Run Facebook Infer on the Linux kernel source code, write models in Facebook Infer to improve the analysis.

This is a quite challenging project; in the application, we expect that you have proved that you can run Facebook Infer on the complete Linux kernel source code and you obtained a first analysis result.

If you cannot run Facebook Infer on the complete Linux kernel source, you should prove that you understand why Facebook Infer fails on certain parts, suggest different alternative work arounds and solutions, and already applied the work arounds, so that you can run Facebook Infer on the kernel source code with a fully known, understood and limited number of work arounds.

The project proposal should include first technical steps that show how you write models in Infer.

Required Knowledge:
  - Required: Very good understanding of static analysis
  - Required: Very good knowledge of C, skill to READ AND UNDERSTAND source code in the Linux kernel in independent work
  - Required: Very good knowledge of make and python
  - Required: Good knowledge and practical experience with OCaml
  - Required: good analytical skills to understand why static analysis reports findings in certain source code parts, solid documentation skills, good English writing skills with clear precise style
  - Desired: Basic knowledge of the kernel build system

==== Develop Methods for Tracking Tool Analysis Findings over Time ====

We use a number of tools, checkpatch.pl, coccinelle scripts, sparse, etc. and these tools report certain findings.
While the valid ones are addressed by the kernel developers, the invalid tool findings are manually assessed and not acted upon. Over time with addressing the valid findings, the proportion of invalid findings increase compared to newly appearing valid findings, as invalid findings of those tools are not marked and tracked over the various versions.

In this GSoC project, the student should work out methods and tools to track the tool findings and make these tools useful in the Linux kernel community.
 
Required Knowledge:
  - Required: Very good knowledge of C, skill to READ AND UNDERSTAND source code in the Linux kernel in independent work
  - Required: Very good knowledge of python
  - Required: Good understanding of git
  - Recommended: Some understanding of static analysis tools
  - Recommended: Some understanding of coccinelle

==== Make Linux kernel community aware of tool findings ====

The Linux kernel community has a number of tools to ensure the quality of the continuous kernel development. Among these tools are coccinelle, sparse, checkpatch.pl, lock dependency validator, KASAN, syzkaller and many more.

In the GSoC project, the student should find suitable ways to make the Linux developers aware of the tools' findings. There are various way in which this could be implemented, e.g.:

  - Setting up an infrastructure that runs those tools on patches provided on the mailing list and reports the findings back to the patch authors
  - Including the tool findings in the elixir development service
  - Providing means to tag and comment on tool findings in the distributed Linux kernel development

This project idea is quite wide and we expect the student to provide a more specific description of the task to tackle with some evidence that he/she will be able to implement the proposal.

Required Knowledge:
  - Required: Very good knowledge of a suitable programming language, e.g., python
  - Required: Good understanding of git
  - Required: Good knowledge of C
  - Recommended: Basic understanding how the kernel community works
  - Recommended: Basic understanding of the kernel tools
Wiki

User Tools

Site Tools

Page Tools
