Getting started with seL4, CAmkES, and L4v: Dependencies

We have found in Trustworthy Systems that a big hurdle for new people coming to work on the seL4 ecosystem is setting up the dependencies. Setting up a machine with all that’s required to build seL4, CAmkES, and L4v is no simple task, particularly if you intend to target multiple platforms.

This blog post will take you through how we have setup our software dependencies in Trustworthy Systems, and how we built it to make it much easier and cleaner for anyone to get starting with seL4, CAmkES, and L4v.

Some history

Approximately a year and a half ago, the regression testing setup in Trustworthy Systems was migrated from a bare-metal server to running within a Docker container. This transition was motivated by two main factors:

Containers allow the regression system to be isolated from the server itself, meaning no unintentional OS upgrades or software changes can affect it,

Docker uses Dockerfiles (simple text files) to build containers, which means we could use version control to observe, track, and modify the dependencies.

After the initial transition from bare-metal to container was complete and tested, we were able to start organising the Dockerfiles into a hierarchy that reflected the implicit dependency structure more clearly.

Hierarchical representation of the Trustworthy Systems Dockerfiles

By doing this, we get a number of benefits:

Dependencies: we are able to isolate the important dependencies that are relevant to each part of our software stack

Regression testing flexibility: the regression software is a leaf, and so can be swapped out or modified easily (no need to rebuild the whole stack). In our current setup, this is used to ensure Bamboo and its Agents share the same environment, but also allows for switching Bamboo to Jenkins or some other CI very easily.

Reproducibility: the images we share are the literal basis of our regression testing system, so by sharing them, people can reproduce our steps and verify it’s all OK.

Usability: The most relevant bits can be released externally to users for them to use!

Helping users get started

Making the seL4, CAmkES, and L4v Docker images available was a good first step to helping users, but still represents a potentially off-putting first step into something unknown (“What the hell is Docker, and how do I use it?”). To mitigate this, a small wrapper Makefile is provided with the Dockerfiles, which enables users to get going as smoothly and quickly as possible.

To demonstrate, these are the steps to go from a fresh Mint/Ubuntu/Debian machine to one ready to build seL4/CAmkES:

The image has been generates in the ~/dev/sel4test/images directory on your host machine, and has all the right permissions for you.

If you are ready to start doing some development, we recommend you do that outside the Docker container, since it does not have common tools like vim or emacs – and you probably have your own comfortable environment setup. When you want to compile, use the container alias to boot into Docker and use make, or simply have the Docker container running in another terminal.

Verifying seL4

Formal verification is major part of the appeal of using seL4. To verify it yourself, we need to do a little bit more setup.

First, we should add another bash alias to make things easier:

user@my_machine:~/dev/sel4test$ echo $'alias containerl4v=\'make -C ~/dev/seL4-CAmkES-L4v-dockerfiles user_l4v HOST_DIR=$(pwd)\'' >> ~/.bashrc # open a new terminal for this to take effect

You will have to open up a new terminal for this command to take effect (or run source ~/.bashrc).

Now we can run the command:

user@my_machine:~/dev/sel4test$ containerl4v

It might take a little while to download the new files. Once it’s done, exit the container by running:

Changing the build environment

Since almost anything could potentially be build on top of the seL4 ecosystem, we cannot include all the possible dependencies that may be required. However, we wanted to make it easy to add additional software.

Let’s say we needed the program “Cowsay” as a build dependency. Currently in the build environment:

Docker will detect the changes in extras.dockerfile and build them into a local image that sits on top of the container Trustworthy System distributes. Now you can run cowsay inside the build environment:

Any command can be run after a RUN statement (for example: apt, curl, dpkg, ln, etc.), so you should be able to configure it to your needs. See the other Dockerfiles in the repository for a reference.

Cleanup

The Docker images, and running the L4v regression, can end up taking up a bit of room on your hard disk. If you need to clear them out, you can run a few different cleaning commands:

user@my_machine:~/$ make -C ~/dev/seL4-CAmkES-L4v-dockerfiles clean_isabelle # Remove the L4v regression heaps (usually quite large)
user@my_machine:~/$ make -C ~/dev/seL4-CAmkES-L4v-dockerfiles clean_home_dir # Remove the home directory for the container (usually relatively small)
user@my_machine:~/$ make -C ~/dev/seL4-CAmkES-L4v-dockerfiles clean_data # Do both of the above
user@my_machine:~/$ make -C ~/dev/seL4-CAmkES-L4v-dockerfiles clean_images # Remove all of the images downloaded and created from trustworthysystems
user@my_machine:~/$ make -C ~/dev/seL4-CAmkES-L4v-dockerfiles clean # Do all of the above

“But I don’t want Docker!”

For all the people interested who can’t or don’t want to install Docker, having access to the Dockerfiles provides a good step in figuring out what you’ll need to install on your own machine. However, in the future to make this a bit easier, we’ll be including a basic script to transform the Dockerfiles into a bash script that strips out any of things you wouldn’t want to do to your real machine (like running the && rm -rf /var/lib/{apt,dpkg,cache,log}/ commands!)

Moving forward

We welcome any feedback on our dependency systems, so feel free to give them a try and let us know! Some plans for the near future are:

Document each dependency more clearly within the Dockerfiles so it’s clear what they’re for and what uses them,

Getting the dockerfile2bashscript converter working and useful,

Migrate more commonly used dependencies from our TS_tools.dockerfile to the externally released files,

Build parallel stacks of Dockerfiles based on other popular distros, such as Ubuntu or CentOS, which can run as build agents in our CI.