TRENTOS – A secure operating system on top of seL4 & CAmkES

Sebastian Eckl, Senior Software Engineer at HENSOLDT Cyber

This blog post marks the third article in a series of six and will explain the architecture of TRENTOS®, a novel secure embedded operating system developed by HENSOLDT Cyber, which is built on top of the seL4® microkernel and the CAmkES framework. By seamlessly continuing the abstraction approach of CAmkES, TRENTOS alleviates the entry to the quite complex area of developing secure embedded systems.

TRENTOS – Utilizing seL4 and CAmkES underneath

With the Trusted Entity Operating System (TRENTOS), HENSOLDT Cyber addresses secure IT right from the start, by building upon the proven seL4 software ecosystem and consequently relying on trusted open-source components. Utilizing both seL4 and CAmkES underneath, TRENTOS is the actual environment a developer can interact with. Therefore, developers can fully focus on creating secure applications without having to worry about lower-level details of the underlying architecture.

 

The TRENTOS Architecture

TRENTOS consists of a set of building blocks provided by a typical embedded OS in order to ease the development of custom applications. TRENTOS’ modular structure is hereby reflected by its set of libraries, written in the C programming language. They provide all the required core OS features (e.g. networking and storage facilities), security primitives (e.g. cryptography), logging capabilities and additional helper functionality (e.g. data structure implementations). As TRENTOS leverages the component character of CAmkES, concise interface definitions are mandatory for being able to interact with the OS. Hence, TRENTOS provides both a dedicated C API and a set of standardized interfaces created with the help of the CAmkES IDL. A typical TRENTOS component can then adhere to the TRENTOS API (e.g. the storage API) and either provide or use respective functionality via a RPC interface. Since a TRENTOS component basically behaves like a CAmkES component, it internally also utilizes the CAmkES ADL and requires additional programmer-provided component code. To avoid recurrent work, TRENTOS already provides a set of standard components, which internally utilize specific TRENTOS libraries to provide a reference implementation for typical OS functionality that is accessible via the TRENTOS API. An example can be seen in platform specific device drivers (e.g. a network or SD card driver) for the Raspberry Pi 3 B+ (RPi 3 B+) and intermediate layers (e.g. a network stack or a partition manager).

Figure 1: a TRENTOS application that utilizes storage support on the Raspberry Pi 3 B+ hardware platform

Providing a small TRENTOS example

Figure 1 shows the graphical representation of a small TRENTOS example, depicting a system that can store data using file system functionality on top of the RPi 3 B+ hardware platform. The setup hereby consists of 

  • a SPI-based NOR Flash memory chip (W25Qxx IC Family), which is connected to the OS via a dedicated storage driver (RPi_SPI_Flash Driver) in order to provide a persistent storage backend
  • a partition manager (StorageServer), which splits the physical storage into several segments
  • a test application (TestApp), which uses the partitions to initialize several FAT file system instances

When we have a closer look at the setup, we can see that the system consists of a layered approach, containing several components that interact with each other by using interfaces defined within the TRENTOS API. As we don’t want to implement the actual device driver logic as well as the partition manager functionality ourselves, we simply reuse the respective TRENTOS standard components. This allows focusing solely on the development of the actual application (TestApp).

On the lowest level, the TRENTOS RPi_SPI_Flash Driver standard component provides access to the actual NOR Flash hardware device, internally utilizing the SPI protocol. Access to the underlying physical storage backend is then provided to the upper layer via the TRENTOS storage interface (if_OS_Storage). As we can see, the same interface is implemented by both the partition manager (StorageServer) and our own component (TestApp). The StorageServer therefore acts as an intermediate layer, which can be omitted easily in case no support for partitions is required. Before we are now able to manage actual files, we first have to create a file system instance on one of the provided partitions. Therefore, we use the FAT library from TRENTOS file system libraries (FAT FileSystem library) directly from within the TestApp component.

As the TRENTOS standard components already contain their respective CAmkES declarations and corresponding C code, we have to focus on providing the same building blocks for our TestApp component. After instantiating and connecting our components, TRENTOS is ready to rely on the existing CAmkES facilities in order to generate a complete, platform-specific, bootable system image. This has to be deployed to the RPi 3 B+ in our example. An exemplary hardware setup is depicted in figure 2, having the NOR Flash memory adapter connected to the RPi 3 B+ via SPI (see the multicolored wiring). Nevertheless, for both building and deploying the TRENTOS image on the board, further tooling support is required, which comes with the TRENTOS SDK. So, stay tuned for the upcoming blog post, which will provide an overview of the SDK’s content and explain the steps required for finally executing our application on the RPi 3 B+.

Figure 2: TRENTOS on RPi 3 B+ (Attribution: this image was created with Fritzing)

READ MORE
Share on facebook
Share on linkedin
Share on email
Share on whatsapp
Share on twitter
Share on reddit

Leave a Reply

Your email address will not be published. Required fields are marked *