Vasum demo - Fedora 22 Desktop running in Linux container on youtube.
Vasum is an environment separation mechanism based on Linux Containers (LXC). The idea behind the project is to easily create separate environments (for example Tizen operating systems) running on one physical device. What differs Vasum from other currently available environment separation mechanisms is its ease of use - Vasum comes with pre-defined templates to easily create new environments, and high configurability.
Vasum defines concepts of Host and Zone in order to work properly:
- Host - an environment on which Vasum Server is running. In most cases, this is the Linux-based operating system on which Vasum packages are installed. All Vasum-related and Zone-related management happens inside Host.
- Zone - an environment created by Vasum. It is a separated instance of operating system on which Vasum Server is running. One Zone cannot modify, nor affect other Zones and Host.
Currently the project provides:
- Vasum Server - main daemon used to manage and communicate with Zones.
- Vasum Client - library used to control Vasum Server.
- Vasum CLI - CLI tool allowing to control Vasum Server from terminal.
Our goal is to provide fast and easy to use set of tools to create new, fully functional Zones.
There are numerous ways in which we can use Zones created by Vasum:
- A test separated environment for applications we're not completely sure of - such apps can be launched with guaranteed safety for our critical data kept inside our system.
- Temporary environments used for development, where we have very specific requirements of what is installed.
- A guest environment, when we want to lend our device to someone.
The year is 2014. The idea of lightweight virtualization on Linux systems was developing. In order to create a separated environment, users had to rely on either existing LXC libraries, or Libvirt virtualization toolkit, which handled multiple separation mechanisms like KVM, QEMU, LXC, Hyper-V and others. Both of these frameworks needed vast configuration files and many hours spent in order to work correctly and create a safe, separated environment for its user. Not long did it take to figure out, that these tools used only by system administrators could benefit also other, less experienced user. What we needed is a daemon, a set of tools which would make virtualization process easy for its user...
Thus, Vasum project was born.
At the beginning Vasum was designed as a high-level wrapper for Libvirt. Since the project relied only on LXC part of Libvirt, a switch to pure LXC libraries occured. This allowed us to reduce overhead coming from Libvirt and remove dependencies, which were required by Libvirt, but not by pure LXC.
Right now the project supports dynamic creation and management of separated environments using lightweight virtualization methods provided by LXC libraries. Our main test environment is Tizen OS Common Profile with Wayland support and latest Fedora images.
Vasum is a highly experimental feature of the Tizen, so it is not present in the Tizen Image. To get the instructions how to download Vasum sources, how to use Vasum and what bugs are known, follow our guide
Any matters related to Vasum are discussed on official Tizen.org Dev mailing list. If a bug is discovered, it should be submitted through the Tizen.org Dev mailing list.
To fully complement Vasum for Tizen we must introduce several Tizen specific solutions. Having two or more UI based secure operating systems on an embedded device differs slightly from running several server operating systems on one machine, which today is the most common usage for all kinds of virtualizations.
In order to properly handle running applications on Tizen, Vasum must communicate with multiple services running on the OS. An example of such services are Tizen Security modules - Security Manager and Cynara. Such integration is provided by Vasum with the use of Provisioning - a mechanism allowing to mount files, sockets, etc. to allow communication with services running in host.
A simple example of Provisioning is used with Cynara - Vasum redirects Cynara socket to allow applications inside Zone to perform permission checks:
Integrating Vasum with application installation and launch process is a more sophisticated task, which requires deeper changes to the system. Both installation and launch of an application require some capabilities, which are accessible only inside Host. We need those capabilities to set up security features of Tizen, such as SMACK. Zones run mostly unprivileged, and have no influence on Tizen security mechanisms.
On Tizen 3.X, the installation process is performed through Installation Service, known as Security Manager. An application installer communicates with the service to set up all security features of Tizen. To ensure that application installation inside Zone is performed correctly, Security Manager was split into two modes - Master, running in Host, and Slave, running inside Zone. Installer running inside Zone communicates with Slave instance of Security Manager, Slave redirects some privileged operations (like setting SMACK labels) to Master instance.
In order to properly communicate user about an event happening inside a Zone, Vasum integrates with Tizen notification services. This way we are able to implement cross-zone notifications that tell the user a background zone asks for attention (for example, an information about received email coming from a Zone running in background).
Finally, Vasum requires an interface to communicate with user and allow for Zone management. This requires an UI application to manage zones, to create, destroy them and set their privileges.
Non functional requirements
Vasum contains its own "tests" sub-package, which provides unit tests for Vasum components. For Vasum user it is not mandatory to install it, however during development process it is a must-have. Each module of Vasum is tested and 100% pass ratio is kept throughout the development process.
Vasum is a highly fault-tolerant tool - every API returns errors in case provided input is incorrect. In case of crash, Vasum Server does not damage currently running Zones in any way. Launching new Vasum instance after crash will result in reconnection to existing Zones. Additionally, Vasum provides a functionality supporting update of its packages - whenever an update occurs, the Server will detach from running Zones, shut down and reload its updated binary automatically. That way every running Zone is independent of Vasum Server and its eventual bugs.
Vasum's response time is near-instant at start-up. However, different API calls might take different amount of time to process, depending not only on request type, but whether the call is synchronous, or asynchronous.
Vasum C API performs synchronous calls - all these wait until requested call is finished before exiting the function. Their response time might vary - minor tasks, like listing available Zones, will produce the result at instant, whlist creating new Zones takes undetermined time and depends on used Zone template.
In order to use Vasum API asynchronously, user must communicate with the Server without Vasum Client library (that is, using DBus or UX Sockets directly). The API requests a function to call and immediately exists, processing the request on a separate thread. User of the API must assure synchronization is kept when using async calls.
On the lowest level, Vasum is implemented using kernel containment features in Linux systems. This is currently the best mechanism available for Linux to achieve virtualization level separation that does not require a separate kernel for the guest's operating systems, and it's free of an overhead typical for a full virtualization hypervisors like QEMU, KVM and others. It's completely implemented in the upstream kernel and does not require additional patches to be maintained. It comprises the following main features:
- Namespaces make it possible to isolate processes, or groups of processes, from each other giving them complete separation in the following areas:
- Inter-process communication using signals, poll memory, sockets or file descriptors (IPC)
- mount points/filesystem (MNT)
- network interfaces (NET)
- process IDs (PID)
- user and group IDs (USER)
- hostname/domainname (UTS)
- SMACK labels (see SMACK namespace).
- For more info about Namespaces, check its LWN Article
- Control Groups / CGroups
- CGroups provide hardware resources isolation and their management. They make it possible to assign, reassign and sometimes throttle resources like: CPU, memory, block I/O, other devices represented as /dev nodes.
To control Namespaces and CGroups from userspace, LXC libraries are used. These provide a low-level API for Namespaces management and their resource control using CGroups. Vasum wraps LXC libraries and provides a high-level, easy to use interfaces to control LXC, together with a lightweight daemon managing the entire process and created environments.
To get detailed information on our API, visit its dedicated Wiki page.
Building Vasum produces following packages:
- vasum - main package with Vasum Server and its configuration files.
- vasum-cli - Command Line Interface tool for Vasum.
- vasum-cli-completion - enables completion for vasum-cli in Bash.
- vasum-client - Vasum Client library.
- vasum-devel - development package with headers for Vasum Client.
- vasum-tests - Vasum Unit Tests and Integration Tests.
- vasum-zone-daemon - Vasum daemon running inside Zones
- vasum-zone-support - support package with DBus configuration files for zone-daemon.
Most recent project packages built by CI tool: CI: last successful build artifacts
Running the project
All information regarding how to launch Vasum can be found on our guide.
High Level Architecture
Vasum has a main process, called vasum-server. For the project to work correctly, it is required to have it running on the system. Additionally, Vasum uses LXC to create new Zones. When there is a Zone running in the system, LXC creates a lxc-monitord daemon used to handle zones and launch new ones. This is another key process for Vasum in order to work properly.
The overall design, and how Vasum relates to other part of the system, is described on following diagram:
Vasum has two communication methods used to transfer data between Server and Client library. One, and default, is communication through DBus, the other one uses UNIX Sockets. Both API descriptions can be found on our API description page.
Vasum contains its Unit and Integration tests inside the repository. For more info about these, visit Tests description.
Default configuration files, written with JSON, are kept in /etc/vasum directory. SQLite3 database keeping dynamic configuration files is kept there as well, in vasum.db file. For more information about the configuration files (both static and dynamic), visit configuration files description page.