2022 April release

This release is for version 0.10.0 of the KOS platform. This release is one of the 2 remaining minor releases scheduled before the first major release, 1.0.0, is delivered around the end of 2022.

The goal for this release is to add additional features required for our initial set of demonstration projects.

Highlights

Secure communications

A KOS device requires communication with remote endpoints to implement features such as remote upgrade, command and control functionality and reporting of telemetry and health data. Communication across a public network is always at risk of interception or interference.

A secure tunnel component is added that allows private communication across a public network. Private messages are encapsulated inside public messages and sent across a public network where a remote endpoint is able to decapsulate the public messages to reassemble the private messages.

Cryptographically secure pseudorandom number generator (CSPRNG)

Introduces a new KOS core application - rng_server. The RNG server facilitates a primitive API to request random byte streams of arbitrary lengths. This being served over the message server protocol kos_rng_protocol. The RNG server initializes a ChaCha20 cipher stream (Author: D. J. Bernstein, Reference: chacha-merged.c version 20080118) with a private seed/key and nonce.

Visible upstream changes include:

• Introduces a new client library kos_rng_client
  • Provides a simple RNG client API to interact with the RNG server through its message server protocol. This mainly introduces the kos_request_rng_stream API call, allowing an application to request an arbitrary length stream of random bytes from the RNG server.

Secure boot

The i.MX8MM can now be booted with images that are signed with device registration certificates generated from OpenSSL. This allows deployment owners to be certain that images loaded onto the board have not been tampered in any way.

This is still an experimental feature and is more of a proof-of-concept rather than a production-ready feature. The specifics are still being worked out and the procedures are being streamlined.

See the imx8mm secure boot guide for more information.

Verified kernel configurations

It is possible to configure KOS to run on a version of seL4 that has proofs of functional correctness, and check those proofs. The only platform on which this is currently supported is nitrogen6sx, with MCS disabled, FPU enabled, debug printing disabled, and a single scheduling domain.

Multiple BEAM instances

Better support for multiple BEAM instances is achieved by reducing the required memory footprint of each instance heap memory requirements down to about 24-32MiB for small applications. This is possible via using more embedded-friendly system allocator settings for a beam emulator. The emulator options that we currently recommend are:

Multiple network client support

Multi-networking allows multiple KOS applications to communicate with endpoints over the public internet. It is possible to assign a separate IP address to each KOS application if it is allowed to communicate with a remote endpoint. With the use of the secure tunnel, these IP addresses exist in a private network and an application is prevented from sending or receiving messages with a non-trusted endpoint.

Rust language support

Support for building rust libraries on KOS. Custom rust targets that support KOS application environments mean rust libraries can be linked into KOS applications. The no_std crate attribute is supported and can be used for libraries that only require the core rust standard library. Libraries that wish to use std libraries are able to do this when using the KOS hosted environment but should be aware that std libraries depend on a full hosted C environment, while only a partial one is provided by the KOS hosted environment.

Orbit

Orbit is the new service that devices can communicate with to perform certain operations like upgrade the system, restart, etc. It can also receive input and render Scenic scenes remotely from any application.

Device registration

Devices can be registered on Orbit to be able to receive commands and stream Scenic scenes. A public/private key pair is used to authenticate devices.

Scenic relay

Added support for the Scenic remote driver to communicate with Orbit.

Command and control interface

A basic command and control (CnC) interface has been added to Orbit. It communicates with the Device Admin component through a WebSocket connection that is authenticated using a public/private key pair. From this interface commands can be issued to the Device. The following commands are available:

• Ping
• System restart
• System upgrade

The system upgrade command accepts a compressed tarball (.tar.gz) consisting of the manifest and the compiled apps can be uploaded to Orbit which in turn sends a command to the Device Admin component which performs the upgrade.

Device admin component

The admin component is an Elixir KOS app that connects to Orbit to send and receive data. It keeps a persistent WebSocket connection. The admin component processes Orbit commands and communicates with appropriate system servers to execute them (currently it communicates with the _root server to implement restart and upgrade).

Device alive status

Orbit can list which devices are alive.

Device upgrade

Orbit can send an upgrade command which provides all resources that are needed to perform such upgrade. Device downloads the new version and restarts the applications.

Remote device restart

Orbit can send a restart command to restart all applications.

KOS System tracing

Introduction of an initial system-wide tracing framework. Provides developers with the capability to collect monitoring data about a device’s system services/drivers for development, debugging and diagnostic purposes.

Visible upstream changes pertaining to tracing include:

• Introduces new library kos_trace_runtime :
  • Provides a C API that allows users to instrument static tracepoints in application and driver sources.
• Introduces tracing configuration sub-node in the manifest:
  • Users can configure tracing on a per-application basis by implementing a tracing sub-node inside an application’s manifest node.

I2C

Introduces an I2C server (with driver for the I2C controller on the BeagleBone Black) and a client library for interacting with the server. The weatherstation application has been refactored to make use of this I2C server and the client library.

MacOS development environment

This release includes improved support for development on macOS:

• The Nix build environment supports building and testing on Apple Silicon hardware. Cross compilers currently run under Rosetta 2.
• QEMU simulation helper scripts (simulate-macos) include limited networking support, using the QEMU user-mode network driver. QEMU provides DHCP, DNS relay, and TFTP server, and NAT-based forwarding to the host’s network. This means that outgoing connections from the simulated device are functional, but the simulated device is not reachable from the host.

Up-coming

These items are likely to appear in future point releases associated with this release

CAN driver

Support for the CAN controller on the Beaglebone Black has been implemented. The driver still requires some testing to ensure that it is working as intended.

An application called the can_server has also been introduced. This multiplexes the CAN controller over multiple clients and provides an abstraction over the CAN controller. A sample application demonstrating the use of the can_server APIs can be located in kos_testbed/can_example .

Multiple message servers

For systems that require applications to be grouped into multiple zones operating at different security levels, KOS will include support for multiple message server instances. The configuration for each app will specify which message server instances the app can connect to.

This will be a breaking change to the manifest configuration structure. The likely changes are as follows:

• The FDT manifest will include a new msg_servers top-level node, whose sub-nodes will specify the message server instances in the system.
• Each message server instance configuration will contain its own dir_access_control sub-node describing that instance’s access control matrix. There will no longer be a top-level dir_access_control node.
• Each app that needs to connect to one or more message server instances will require a msg_servers property explicitly listing those message server instances. Any app that does not have a msg_servers property will not be connected to any message server instance.

The release will fully document the new manifest format, and will include an example system.

Existing apps that are only intended to connect to a single message server will be source compatible with the new release. New APIs will be made available for apps that need to connect to multiple message servers.

‍