[tech] [part 1] Pantera OS : A Financial Operating System

This post is an early investigation into the topic of unikernels.

By the end of this entry, you will be able to understand unikernels and the logic behind architecture, before studying the use-case of an application such as Bitdinar, and finally test a small MirageOS webserver implementation.

For a detailed technical description of Pantera OS in its latest stage, it is possible to jump to part 2, where we discuss the Rust implementation.  

Pantera OS

Our software product is the Pantera Operating System, or Pantera OS for short, an exceptionally secure software intended for critical financial operations.

Pantera OS is named after an exceptional animal, the Pantera, to outline its stealth abilities and speed of execution.

To mimic the predator in code, our software proposal is a custom and minimal container, for which internal computation can be tightly restricted, and its exposure to the internet highly limited if not completely disconnected, without affecting its performance.

Critical Security by Design

In this section, we will discuss if a unikernel Operating System satisfies the conditions of security and performance aforementioned, and if it is possible for a unikernel to operate as reliable banking software.

Requirements

Critical infrastructure, as in the banking sector, implies the need for a minimalist architecture, and a better compartmentalization of its critical components. Equally so, a physical bank would be harder to manage if it had non-existent, or extremely complex, security infrastructure.  

To support these propositions, the minimal approach has been adopted by several stacks and Operating Systems such as Qubes OS, to emtnion a single example, so we do not have the burden of reinventing the wheel.

Nevertheless, we have been motivated by such innovations, seeing a substantial benefit for our audience and customers.

We will discuss in the following post such stack, or in other terms the implementation of a Mirage OS virtual machine, to demonstrate the traits that embody at best our development philosophy, and apply it to the container logical component.

For the more technically involved audience, it is possible to read about Mirage OS project here.

Architecture Overview

The overview below provides an idea of how unikernels would fit within the landscape of containers in the wild.

The purpose of this architecture is to expose a reduced attack vector for external attackers, and limit the scope of actions of internal hostile actors, while increasing the intrusion monitoring capacity.

The possibility of using shared memory resources is drastically limited at low level. As we see in the overview, and for a similar application size, unikernels combine the benefits of containerization, with the flexiblity of hypervisor orchestration. Kernel resources (Memory) are not shared, and interactions with the hardware go through the unified hypervisor API, regardless of the kernel in-use.

Such systems can be configured to not include any accessible user interface, e.g. operate headless. However, such modular systems can be adapted to desktop environments. For instance, at User Interface level, like in Qubes OS, the clipboard (copy / paste) workflow is set at a sane but secure mode, where taking files from one container to another requires an additional step.  

More closely into the internals, we can expect an enhanced security as the result of refactoring the necessary software libraries, in a more compact fashion, and in a relatively safer language.

Comparison

For instance, we can proceed to a trivial but visually significant comparison. Let's count the lines of code of the regular Linux Kernel usually written in C and C++, against the Mirage OS kernel written in Ocaml.

For the the Kernel and the Cryptography primitives, we can see below the difference between the regular Linux kernel size, against the size of the Mirage OS implementations:  

(the following numbers are in thousands of lines of code - k LOC)

And if we combine all required components to build a full kernel, we get the following total:

When we combine this programming paradigm, with the safety features of the OCaml language, we can obtain the type safety, gain in performance and reduction in attack surface.

Unikernels

A "Unikernel" Operating System operates as a functioning software container, computing a compact kernel, which runs directly on a hypervisor or hardware without an intervening OS such as Linux or Windows.

I came up with this less-than-scientific definition for the sake of clarity, but the wikipedia entry covers well the topic.

Nevertheless, our commercial objective is to provide our customers with the most relevant custom software stack, that lives on custom hardware, to satisfy strict requirements.

Real World Applications

Pantera OS is intended as a banking Operating System that runs a custom financial logic, while containing its dependencies and its content in a specific layout.  

It can operate as an algorithmic trading engine for a trading firm, or operate as a digital vault (Hardware Security Module) for a bank that requires a Public Key Infrastructure for example.

Our go-to example application will be running the necessary stack, to properly operate the Bitdinar software.

La Poste Tunisienne

Pantera OS can be deployed as the core back-end of a digital bank.

We are refactoring the kernel itself, to interpret the specific business processes of the bank, into algorithmic processes. Specifically, we are refactoring the network stack, to establish secure connections to-and-from the contained kernel.

Under the Hood

To capture a large scope of business requirements, we will assume that our system will need the following objects to function properly:

• Business logic: Custom and off-the-shelf software libraries.
• Cryptographic artifacts, functions and primitives, when intended for key storage.
• Networking logic, when intended to serve files on network.
• Configuration files.

In this context, our system follows a software containment paradigm, as a minimal library unikernel system, by removing all unnecessary components in a modular fashion.

Kernel Application

We will not cover the details of the kernel in this post, as it is still work-in-progress.

However to provide some context, for the following technical demonstration we can assume that access to the container is constrained, and specific kernel components are re-factored for specific needs, upstream at host hypervisor level, and downstream for internal components such as the networking stack.

For this demonstration, we test an implementation of a Mirage OS based webserver, which is a installed and mounted the same way any other kernel application would be.

MirageOS is a library operating system that constructs unikernels for secure, high-performance network applications across a variety of cloud computing and mobile platforms. Mirage OS is a serious contender to become the target stack for Pantera OS

Installation

To download Mirage OS on Debian:

$ sudo apt update
$ sudo apt install opam
$ opam init
$ opam install mirage

By porting our kernel to Mirage OS, we will guarantee that our software is running under restrictive conditions.

For this example, we will use a ported webserver, that runs on a Xen Hypervisor.

Performance

Let us see what gains are expecting in terms of boot process speed.

Here is a comparison between a Mirage Firewall AppVM vs a Minimal-Fedora Firewall AppVM, performed on a Lenovo C1X1 machine running a Xen hypervisor:

• Debian based firewall or sys-firewall

[user@dom0 ~]$ \time -f "Program: %C\nTotal time: %E\nUser Mode (s) %U\nKernel Mode (s) %S\nCPU: %P" qvm-start sys-firewall

Output:

Total time: 0:09.21User 
Mode (s) 0.04
Kernel Mode (s) 0.01
CPU: 0%

Mirage OS based Firewall or mirage-firewall

[user@dom0 ~]$ \time -f "Program: %C\nTotal time: %E\nUser Mode (s) %U\nKernel Mode (s) %S\nCPU: %P" qvm-start mirage-firewall

Output:

Total time: 0:01.71
User Mode (s) 0.05
Kernel Mode (s) 0.00
CPU: 3%

Here we notice a substantial gain in speed in the boot process, from 0:09.21 seconds for the Debian VM, to 0:01.71 seconds for the Mirage OS VM.

In terms of CPU usage, the CPU consumption of the Mirage OS test machine peaks at of 3%, and null % for the other machine.  

Conclusion

Thank you for making so far in the post, hoping it was informative without getting into too much details.

The Mirage OS stack is a serious stack to consider for critical infrastructure. It provides a ground to optimal programming, and provides an infinity of possibilities to satify stricter requirements.  

Stay tuned, for the second part of this post, where we will take another turn and implement a similar approach to compact kernels.

Note: For the fans of generative art, the first picture is the flyer for a Refik Anadol exhibition back in 2018. I chose it because it depicts well the contemplation process.