Everything is a KAB

“KAB” stands for “KOS Archive Bundle” and is the primary file format used within KOS. A KAB file can be thought of as an uncompressed zip file with a custom header and digital signature. Within KOS, everything is packaged as a KAB file. Even the Linux kernel is packaged in a KAB, and the KOS bootloader boots directly from KAB files.

A discussion about file formats may seem an odd place to start learning about KOS, but it plays a central role in how both KOS and KOS Studio function; it’s essential to understand what a KAB file is so future concepts make sense.

The KAB file format was designed with three key design goals: security, immutability, and determinism. These are commonly used terms that are applied to a range of topics, so in the context of this document, they are defined as follows:

  • Security: The ability to verify the integrity, source, and mode of everything installed on the device:
    • Integrity relates to the detection of corruption or tampering. This is performed using digital signature verification. Since KOS never expands the contents of KAB files, integrity checks of KAB files are allowed on every boot.
    • Source verification relates to the chain of trust. This includes verifying who built a component and whether the source is trusted even if the component passes integrity checks. Every KAB contains a certificate from the developer keys used for signing. This allows KOS to verify trust between organizations for every installed KAB file.
    • Mode refers to test vs production operation. Each KAB file is marked as either test or production mode based on the type of developer key used to sign it. This allows developers to run locally built code on test mode equipment but ensures that production systems can only run trusted production releases.
  • Immutability: An operating system that is effectively read-only and cannot be modified by user code. Standard desktop Linux distributions are not immutable, as a root user can delete any file and corrupt the operating system. There are several strategies for making an immutable Linux distribution, ranging from installing all packages and making the resulting filesystem read-only to creating a master squash filesystem. KOS uses a granular approach to immutability, constructing the entire operating system from a series of stacked layers where each layer is stored in a KAB file. This allows KOS to perform incremental updates by replacing only changed layers.
  • Determinism: The ability to ensure that a device only runs in a known, tested state. If it is unable to run in a known state, it reverts to a previously known state. An operating system that performs updates based on add/remove scripts is not deterministic, as a single update failure leaves the device in an unknown state that has never been tested or verified to work. This type of system also provides no way to get back to a guaranteed known state in the future, resulting in all future updates running in a non-tested configuration. KOS uses a manifest of KAB files to guarantee that what is running on the device is precisely what is expected.

On top of these goals, KOS is an application-based platform. This means that a running system is not a monolithic software image but a collection or federation of components that work together to make the device function. These applications may be bundled with data, content, and so on, which should also be subject to the goals outlined above. With this in mind, the KAB file format is designed to package every operating system component, from the Linux kernel to user applications and data.

A common refrain in KOS is that “everything is a KAB,” this is generally an accurate statement because of how KABs are used within both KOS and KOS Studio. Here are some examples of KAB characteristics and why KABs are so universal within KOS:

  • KOS is an assembly-based operating system. A release is a collection of KABs and nothing else. These KABs aren’t even packaged together, as a release is defined by a manifest that contains a list of KAB UUIDs. The manifest itself is also packaged as a KAB. All parts of the operating system, from the kernel to filesystems to apps, are KABs captured in one or more manifest KABs.
  • The UUID of a KAB is equivalent to the KAB itself. The filename of a KAB is meaningless to KOS, and all KABs are referenced entirely by UUID. If you have the UUID of a KAB, you can describe the exact KAB in the universe.
  • The type of a KAB is often used to determine how the KAB is to be used. KOS defines certain KAB types and have specific semantics, while others are defined by developers who are free to use them as they see fit.
  • KABs support internal public/private key encryption per-file basis, allowing sensitive information to be packaged in KAB files.
  • KAB files can be created using command line tools that ship with KOS Studio, via the KOS maven plugin, or programmatically using the KOS SDK. KAB files can be viewed using command line tools or the KAB viewer tool in KOS Studio.

KOS Studio is designed around a sophisticated artifact registry system that catalogs and indexes KABs, allowing developers to work with logical components instead of individual KAB files. This also allows KOS Studio to download and install KAB files on devices without developers needing to interact directly with KABs, greatly simplifying and streamlining the development process.