Cyberus Technology welcomes students and encourages them to work on research related topics. Our software stack is a good research base, as it resides in the field of operating systems (OS) and virtualization. One example is my journey at Cyberus. I am Philipp Schuster, a former student and now full-time employee. From October 2021 to April 2022, I wrote my thesis (Diplomarbeit) at TU Dresden in cooperation with Cyberus Technology. It has the title A Policy-Free System-Call Layer for the Hedron Microhypervisor and covers multiple interesting aspects of OS development and integrates into our existing technology stack. Instead of focusing on the virtualization part of our stack (see our SVP product), the thesis focuses on applications running directly on top of Hedron. We call them Hedron-native applications or hyperapps. Hedron is the kernel (Hypervisor) that builds the secure base of our SVP stack.
In this blogpost, I am going to outline a few exciting key aspects of the thesis and provide links to dig further into the topic, in case you are interested.
By policy-free, we refer to the terminology of microkernels. Microkernel architectures strive to add as little policy as possible into the kernel and instead only provide mechanisms. Hence, user space applications can implement decisions in a more secure way than monolithic systems, such as Linux, do.
Developing for non-standard targets, such as the Hedron microkernel, is associated with lower productivity, since typical toolchains have to be adapted. For example, the standard library is not available on the target system or a special version is required. Developing for established standard targets without adapting a toolchain, on the other hand, is known to a large number of developers. Toolchains that deviate from a standard target must be adapted and maintained for each software project. The experience over the last decades has shown that this process ties up many resources.
The thesis presents modifications to Hedron and an associated runtime system. Together, these components enable the concurrent execution of Hedron-native applications and unmodified foreign applications using Linux programs as an example. This allows to reuse the established toolchains and developing new software for Hedron with them. Furthermore, Linux programs are supported that contain additionally Hedron-native system calls. I call them hybrid applications. This mechanism enables to communicate directly with interfaces of Hedron’s runtime environment from foreign applications.
Foreign applications run as first-class citizens, i.e., side-by-side with hyperapps. This is in contrast to solutions such as L4Linux, which enable binary compatibility via a (para-)virtualized guest. In this work, binary compatibility is reached via an emulation of the foreign system-call interface in user space. This allows a tight, functional, and productive integration of existing software created by established toolchains into the existing runtime system, such as access to existing file and memory management services.
The thesis shows that the solution enables high developer productivity and that the cost of the emulation layer can keep up with Linux, for example, when large file-system throughput operations are made.
Reaching Binary Compatibility
For a comprehensive write-up of the design, please refer to the thesis PDF file, which is linked at the end of this page. In the next section, we summarize relevant key aspects on how to reach binary compatibility with the solution proposed by my thesis.
The proposed design is generic in that it allows for arbitrary applications. For the sake of simplicity, we only discuss Linux as an example in this article. I decided to run foreign applications in their original, unmodified state. Thus, applications do not have or need knowledge during build time or runtime whether they execute on top of Linux or Hedron. As a consequence, they will expect a typical Linux environment. This includes for example the initial stack layout, which holds environment variables and program arguments. The startup routine of the C runtime and the Linux binary itself are going to trigger regular Linux system calls.
Hedron’s system call handler will also catch foreign system calls. If a foreign system call is detected, Hedron forwards it to the Linux OS personality that is running in user space. This switch in the kernel is what the title describes as policy-free system-call layer. Hedron only decides who is responsible but does not handle foreign system calls directly. The modifications to Hedron were possible with less than 30 source lines of code.
The Linux OS personality is a component running in user space that is the shepherd for all Linux applications. It is also responsible for starting them. Using existing Hedron mechanisms, the Linux OS personality can access and alter the whole CPU state of the application. While handling a foreign system call, the OS personality translate between the foreign world and the Hedron world. This includes mapping requests to available runtime services and to translate capability/security models between Linux and Hedron.
In the figure above, we can see that a Linux application executes its natural system call to write to a file. This system call is then transparently redirected to the OS personality that can process the request.
With a few additional adjustments to Hedron, I also enabled hybrid applications. During each system call, a special flag set by the caller is used so that Hedron recognizes these system calls as native, even if it comes from a foreign application. Thus, a new hybrid application can be created as follows: The regular Linux toolchain of Rust or C can be used and an additional library that covers the hybrid part may be included to use this functionality.
Adding a library is a relatively small adjustment to the build process compared to replacing a standard library or not having it at all. The mechanism introduced by my thesis enables to create new software for Hedron with existing Linux tooling and additionally, developers can directly talk to native interfaces of the runtime environment.
I created a working proof-of-concept with reasonable performance and a mechanism that, once implemented into the product, enables developers as well as customers to develop applications for Linux by reusing existing toolchains for Rust programs, C programs, and more.
We still have a strict isolation between native applications and foreign applications. However, a Linux OS personality is the shepherd of all foreign application in its responsibility and thus, must be trusted by foreign Linux applications.
Please head to the thesis linked down below if you would like to know more details.