Background

This page is a work in progress, summarising the background and motivations for the OSEP working group, including some of the (currently unpublished) provisional conclusions from previous work and discussions in ELISA, and in this working group.

Development-Process working group

OSEP's predecessor in ELISA, the Development-Process working group examined may of the topics that have informed OSEP's approach. The results of this work are available on Google Drive (see Outputs below), but the analysis was incomplete and has not yet been written up in a form suitable for wider publication.

Ouputs

Some of the key outputs (all in draft form) are as follows:

1. An (incomplete) report on the work of the Development Process WG
2. A set of software quality process requirements, which map to clauses in ISO 26262 and IEC 61508
3. A set of documents examining different topics from the reference process (2):
   • Of these, one of the most complete is Testing
4. An assessment of the Testing Process requirements focussing on ISO 26262

A decision was taken to shelve this work and branch the WG into OSEP and LFSCS, because the Dev Process WG contributors were finding it increasingly difficult to make meaningful progress.

The intention with OSEP was to build on what we had learned as part of this Dev Process work, but to approach the problem from a different angle: by examining specific aspects of Linux (both its functionality and its development practices) and investigating specific methods of identifying or producing related evidence, which might then be used in a specific safety application context.

Provisional conclusions

1. We cannot certify the Linux kernel

   As noted in the introduction to the Glossary

   "We do not expect to certify the Linux kernel according to any available standard. Full testing is not feasible, and in any case the vanilla kernel image by default supports unsafe features."

2. Most criteria cannot be applied to the kernel community

   As Lukas noted in a post on the management aspects, "most objectives are not for the kernel and the kernel community but for the Downstream Integrator". The way that the Linux community is organised makes it effectively impossible to apply the management criteria identified in the standards.

   This conclusion was further supported by the Testing Process Assessment, which noted (in column D) that for the vast majority of the criteria "This is the responsibility of the integrator".