Processes

Documentation relating to development processes and how to get help or get involved in seL4 can be found on this page. Note that these are generalizations and may be different for a particular project/repository.

Development processes

Developing trustworthy systems requires identifying critical, trusted, system components and ensuring that they:

  • are isolated from non-critical, untrusted, components
  • have assurance of their trustworthiness

Determining appropriate system designs that clearly separate trusted from untrusted components and using this separation to achieve security and safety properties is beyond the scope of this section. However, given such a design, the seL4 ecosystem tries to provide components, infrastructure, and tools to implement it in a trustworthy way.

What we work on

As a microkernel, seL4 intends to provide the smallest amount of mechanisms required to enable securely multiplexing hardware. A full system requires many more components than only the microkernel. We typically try and reuse existing components when possible, but below is a list of projects that are currently maintained to support the seL4 ecosystem:

Supported platforms

This all needs to be deployed on hardware components. The Supported Platforms page has a list of currently supported platforms.

How we choose what we work on

Primarily, what we work on gets prioritised by externally funded projects and what is long-term strategic. The strategic roadmap can be found on the seL4 development and verification roadmap page.

Some priority is also given to maintaining all of the maintained projects and repositories which involves responding to breakages and reported issues as they arise. Raising a GitHub issue on a relevant repository is the best way to get an issue acknowledged. Alternatively, the devel mailing list or the seL4 Mattermost can be used to ask about potential issues.

Additionally, the RFC process is intended as a way for external input to be provided on longer-term priorities as well as a way to promote a collaborative design process on externally contributed features before excessive effort is invested into their development. More information is provided on the RFC page above.

Where we work on things

We try and release all sources onto GitHub under either of the two organizations:

Each project has a list of which repositories it contributes to on its documentation home page. Alternatively, the README.md of each repository should indicate what its purpose is.

Communication about what is being developed can occur on any of the channels listed below. In particular:

  • Discussions can occur on the Mailing list, seL4 Mattermost or seL4 Discourse.
  • Discussions about proposed changes can reach a point where an RFC is created. Further discussion then happens on the RFC site.
  • GitHub issue and Pull-request comment sections can also be used.

Documentation about proposed changes such as roadmaps can be found on this Docsite, or on the seL4 development and verification roadmap page.

Contact

We use the following communication mechanisms:

  • Mailing lists: For email-based discussions, for asking for help, reporting issues or general seL4 communication.
  • seL4 Discourse (seL4um): Forum for seL4. Attempting to build up useful knowledge-base.
  • seL4 Mattermost. seL4 chat platform (Signup link can be found on seL4 Discourse with a valid account).
  • GitHub issues: Reporting issues or creating pull requests on repositories located at seL4 or seL4Proj organisations.
  • IRC: #sel4 room on freenode.
  • seL4 Jira: Currently for reading and creating RFCs
  • Websites: Websites containing information about seL4.

Contributing

We welcome your contributions to the source code and this website. To ensure a collaborative environment, we expect all contributions and interactions to fall within our Code of Conduct. For some repositories, such as the main seL4 kernel repository, we require a contributor license agreement(CLA).

In addition to following the development process that is outset below, most of the software projects generally follow the following conventions:

Additionally, each project may have a slightly augmented processes for contributing: