The Kry10 Secure Platform

The Kry10 Secure Platform is a new Operating System, management service, and hardware (future) aimed directly at Connected Devices. This post focuses on the Operating System and lightly touches on the direction of the services and the hardware.

These devices (sometimes called IoT, although that is a name we dislike) could be one or more of the computers in your car. They could be on a satellite, pumping water to your neighborhood, or running devices in a factory. They could be on construction equipment, running remote fish farms, or conditioning the air in a commercial building.

The common point is that all these devices perform a job that is worth more than the device itself. Accessing the device is either difficult or expensive, and the device (or rather the job it does) is a tempting and valuable target for attackers.

Unlike PCs and Servers, Connected Devices are typically deployed in the field, meaning that they are difficult to access (if you have to roll a truck or work beneath the ground) and most times have little or zero strict physical security. Either way, the attacker isn’t trying to hold the device for ransom, they want to capture your physical plant.

Each layer of the Kry10 Secure Platform is designed to operate in this environment. All the parts assume the minimum amount of trust between them. Everything is restartable and updatable. Where possible, mathematical proofs or correctness are used, as we will see in the main subject of this post - the Kry10 Operating System.

Kry10 Operating System (KOS)

The first major component of the platform is the Kry10 Operating System (KOS). This is a new Operating System built on the formally proven, seL4® Microkernel. The seL4 Microkernel is the right starting place for any system that needs high levels of assurance and is currently in use in military and critical infrastructure use cases.

Even with seL4 as a starting point, it is no small feat to set about building a new Operating System. They are complicated, need to support a diverse set of hardware and software, and are often taken for granted by the layers above. The good news is that by focusing on a smaller set of scenarios, the complexity can be reduced as long as you remain clear about what are your goals and non-goals.

KOS Goals

There are more goals, but those are the biggest and central to all of our thinking.

KOS Non-Goals

It is also important to know your non-goals.

The Operating System

Once you understand your goals and non-goals, designing and building the project can begin. We are hard at work building a usable Operating System that enforces strong application isolation via seL4 policies, while maintaining runtime flexibility, maintenance, and performance.

One way to think about KOS is that we use the seL4 policy enforcement to set up application secure domains that effectively have each app and/or driver running on its own virtual computer. We don’t have to do full OS-style virtualization to achieve this as we can use the formally proven seL4 policy enforcement. This gives us both very good isolation and performance at the same time.

System Layers

KOS effectively runs as three layers. At the bottom is the unmodified seL4 Microkernel. This provides formally proven policy enforcement of hardware resources, scheduling, thread contexts and more.

The middle layer is a set of KOS services that manage the policies that are enforced by seL4 and provides other services such as inter-application communications, virtualized networking, storage and more.

The third layer are the optional applications and drivers. These are the applications that make the machine do the job it does. Some of these applications will be provided by Kry10, but most will be written by the device makers. See the Application Environments section below.

Application Environments

There are two main, first-class environments for applications written for the Kry10 Operating System. The first is direct APIs for drivers or highly performance sensitive applications written in C or Rust. There are a robust set of kos_* APIs that provide low level access to hardware and system services.

kos_status_t status = kos_thread_create(
  thread_fn,                // IN kos_thread_fn thread_fn,
  my_parameter,             // IN seL4_Word param,
  true,                     // IN bool passive,
  &thread_record            // OUT kos_thread_t* p_thread

The above example gives an introductory feel for the low-level APIs. It is subject to change before general availability.

The second, and perhaps main application environment is the Erlang BEAM. We are big believers in the robustness provided by OTP Supervision trees and fully endorse it as the right model for applications that need to keep working in the face of adversity. BEAM applications naturally scale across cores with a natural concurrency programming model and know how to restart portions of an app when errors occur.

There are many resources available to learn and use Elixir, Erlang and other BEAM languages. Many of these resources are oriented toward servers, but subjects about OTP supervision and high-availability are why it works so well for connected devices.

There are other application environments we are looking at for first-class support, but for now, the main two are direct APIs and the BEAM.

Management Service

As much as we enjoy talking about Operating Systems, we always have to come back to the job that a device performs.

Connected Devices are deployed in fleets ranging from 1 to millions of units and perform jobs that are more valuable than the devices themselves. The Kry10 Management Service is designed for the professional deployment manager and provides tools to manage part of or all of a fleet, monitor health, watch for attack patterns, collect data, and more.

There will be more to say about the Management Service, and developer tools as well, as we approach general availability.


Security is no longer a question of good software or hardware design. They must be designed together, with knowledge of each other.

This lesson was taught to the world by the Meltdown and Spectre attacks in 2018. While both of these are hardware attacks in their nature, the best solutions require action from both the hardware and OS designers.

This is the new frontier in security and requires communication and cooperation between hardware and software vendors. While we are not saying anything specific about our work in this space at this time, we are well aware of this reality and working with our partners on really interesting solutions.


Screen Capture of KOS Elixir Hello World

There is a lot going on in the above image. Amongst other things, seL4 brings up hardware in a qemu VM, KOS then boots and starts the core system services as isolated applications, inter-app communications are established, the Erlang BEAM (an unmodified OTP 23.1) is started in its own secure domain, and Elixir is in interactive mode responding to commands. There is quite a bit more than that, as anyone who has had to write their own threading library from scratch knows.

Progress is moving ahead at speed and we are now working closely with a few early partners on real-world devices. General Availability will still be a while as the tools and other components are still coming together. If you have a project that is a good fit and you understand that building on a platform that is also coming together requires cooperation and can be a lot of “fun”, then please let us know.