<!doctype html>
<!-- SPDX-FileCopyrightText: 2019-2020, 2022, 2024 Alyssa Ross <hi@alyssa.is> -->
<!-- SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-or-later -->
<!-- SPDX-License-Identifier: GPL-3.0-or-later -->
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<link rel="icon" href="logo/logo_html.svg">
<link rel="stylesheet" href="style.css">
<title>Spectrum Design</title>
<body>
<nav>
<a href=".">Spectrum</a>
</nav>
<h1>Spectrum Design</h1>
<p>
Spectrum will, for now, be a Linux-based system, with packages from
Nixpkgs but not derived from NixOS. This gives us an
actively-developed base with good hardware support, powerful and
optimised compartmentalization primitives in KVM, and the reproducible
packaging and configuration system that
is <a href="motivation.html">important</a> for a maintainable
compartmentalized system.
<p>
The current plan is to implement compartmentalization in Spectrum by
running each application
inside <a href="https://cloudhypervisor.org">Cloud Hypervisor</a>, a
KVM virtual machine monitor implemented in Rust. Qubes-style
isolated, composited windowing is provided via virtio-gpu cross-domain
Wayland forwarding, with Cloud Hypervisor
being <a href="https://spectrum-os.org/git/spectrum/tree/pkgs/cloud-hypervisor">lightly
patched</a> to enable this. Using a full virtual machine for each
application might come with high resource requirements at first, but
over time we should be able to optimise this, for example by doing
clever tricks like <a href="https://lwn.net/Articles/610174/">DAX</a>
to a read-only storage device shared by multiple guests to save on
duplicated memory. In the short term, it might be prudent to allow
multiple applications to run in a single KVM instance, but our
long-term focus should be on one per application instance.
<p>
Ideally, virtual machines will be created on the fly, and be mostly
transparent to the user, with access controls handled dynamically
where possible. For example, a VM might be created when the user
chooses to open an application, having no access to user files in the
beginning, but with access able to be granted seamlessly using the
File
Chooser <a href="https://flatpak.github.io/xdg-desktop-portal/">XDG
Desktop Portal</a> — the application could prompt the host or a VM
with full filesystem access to display a dialog inviting the user to
select a file that will be made available to the application VM, for
the application to open.
<p>
Where it is necessary to configure VMs statically, doing so should be
easy to do, and easy to maintain and reproduce across Spectrum
installations.
<p>
Spectrum will have a single, global filesystem for user data, with VMs
granted access to subsets of the filesystem as required. This is a
different model of data storage than has been used in previous
implementations of security through compartmentalization. In Qubes
OS, user data in each VM is stored in its own virtual block device.
This works fine when multiple applications run in a single virtual
machine, but would be unmanageable in Spectrum's VM-per-application
model. As long as appropriate precautions are taken, Spectrum's
persistent model should be secure, while providing a more familiar and
easier to understand model for users used to a single directory tree.
<p>
Spectrum currently aims to support x86_64 and aarch64, but it is
important for Spectrum users to have the choice of as much hardware as
possible, including among as many architectures as possible. The
mainstream architectures have various problems with regards to freedom
and trustworthiness, and so it's important for Spectrum to support
other architectures as well, where feasible. Currently, those two
architectures are the only ones supported by Cloud Hypervisor, but if
that were
to <a href="https://github.com/cloud-hypervisor/cloud-hypervisor/issues/5902">change</a>,
additional architectures could be supported.
<p>
Ideally, it will be possible to build Spectrum reproducibly, across a
diverse range of hardware, to verify that the images correspond to the
source code, and are free of tampering. Work
like <a href="https://nix-community.github.io/trustix/">Trustix</a>
will be important to reaching this goal.
<p>
<small>Permission is granted to copy, distribute and/or modify this
document under either the terms of the
<a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative
Commons Attribution-ShareAlike 4.0 International License</a>, or the
<a href="https://www.gnu.org/licenses/fdl-1.3.html">GNU Free
Documentation License, Version 1.3</a> or any later version published
by the Free Software Foundation; with no Invariant Sections, no
Front-Cover Texts, and no Back-Cover Texts.</small>
<p>
<a href="impressum.html" lang="de"><small>Impressum</small></a>