Everything is a KAB
“KAB” stands for “KOS Archive Bundle” and is the primary file format used within KOS. A discussion about file formats may seem an odd place to start learning about KOS but it plays such a central role in how both KOS and KOS Studio function, it’s important to have some understanding of what a KAB file is so future concepts make sense.
To understand where the KAB file originated, we start with three key design goals for KOS: security, immutability and determinism. These are commonly used terms that are applied to range 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 has to do with detection of corruption or tampering of files and is typically performed by cryptographic hash verification. While many systems perform integrity checks during install, convenient while files are still packaged together in a way that they can be checked as a collection, it is considerably more complex to verify every component on every boot.
-
Source verification has to do with chain of trust. This includes the ability to verify who built a component and whether the source is trusted even if the component passes integrity checks.
-
Mode refers to test vs production operation. Developers have test keys and production keys are generally restricted. Mode support allows developers easy access to devices for testing but puts restrictions on what a device can run in production. This is used to balance developer convenience with production supply chain security.
-
-
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 a number of 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 to allow for incremental updates.
-
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.
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, all of which should also be subject to the goals outlined above.
With all of this in mind, KOS has defined the KAB file format that is used to package every component of the operating system, from the Linux kernel up through user applications and data. A KAB is conceptually similar to a zip file in that it is a file that contains other files. Every KAB has a standard header that includes various fields, including a type and a UUID. Every KAB is digitally signed using KOS developer keys which captures information about the source of the KAB.
A common refrain in KOS is that “everything is a KAB”, and 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, meaning a release is really just collection of KABs and nothing else. These KABs aren’t even packaged together, as a release is defined by a manifest which contains a list of KAB UUID’s. The manifest itself is also packaged as a KAB. All parts of the operating system, from the kernel to filesystems to apps are KABs which are captured in one or more manifest KABs .
-
The UUID of a KAB is equivalent to the KAB. 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 are able to describe an exact KAB in the universe.
-
The type of a KAB is often used to determine how the KAB is to be used. Certain KAB types are defined by KOS 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 on a 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 using the KAB viewer tool in KOS Studio.
As will become apparent, KOS Studio is designed around a sophisticated artifact registry system that catalogs and indexes KABs such that they become transparent to the development process. Users simply point KOS Studio at a device and hit run. KOS Studio will download all the KABs and perform the install automatically.
