1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
|
<!doctype html>
<!-- SPDX-FileCopyrightText: 2019-2020, 2022 Alyssa Ross <hi@alyssa.is> -->
<!-- SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-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, 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://chromium.googlesource.com/chromiumos/platform/crosvm/">crosvm</a>,
the hypervisor used by ChromiumOS. Qubes-style isolated, composited
windowing for applications can hopefully be provided through its
virtio_wl, which
transports <a href="https://wayland.freedesktop.org/">Wayland</a> over
the <a href="https://www.ozlabs.org/~rusty/virtio-spec/virtio-paper.pdf"
title="virtio: Towards a De-Facto Standard For Virtual I/O
Devices">virtio</a> protocol. 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>
Each virtual machine will be generated by
a <a href="https://nixos.org/nix/">Nix</a> derivation. System and
user files within a VM will be shared, to reduce overhead and allow
the same files to be worked on from multiple VMs. An isolated VM will
read a directory tree from its on-disk representation, and expose it
to other VMs over a protocol chosen for simplicity to reduce attack
surface. The server inside this VM will be written in a memory-safe
language, to mitigate potential memory unsafety exploits. Ideally,
this server program would not rely on Unix filesystem code, but would
implement its own simplified file system logic, to interact with and
expose a file system as a directed acyclic graph, preventing the
possibility of a
<a href="https://en.wikipedia.org/wiki/Directory_traversal_attack">directory
traversal attack</a>. In simpler terms, this means that there should
be no concept of <code>..</code> anywhere inside the filesystem VM in
relation to the exposed data.
<p>
There may be other writable mount points inside the virtual machine,
but these will not persist between reboots of the VM. Using Nix to
generate virtual machines allows them to be reproducibly built, rolled
back, edited, and migrated as source code, rather than large, opaque
virtual machine images.
<p>
This is a different model of data storage than has been used in
previous implementations of security through compartmentalization. In
Qubes, 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 the appropriate precautions are taken, as described
above, 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>
Which files and directories a VM should be able to access will be
defined in Nix. Other resources and permissions, such as network
cards and USB controllers, will similarly be defined in Nix. There
are three logical sections for the Nix configuration -- applications,
which are just packages, resources (virtual or physical devices, files
and directories), and <i>application instances</i>, which are mappings
between applications and accessible resources. This structure allows
users to have multiple instances of the same application, with
different permissions. It should be possible to grant additional
permissions on a temporary basis at runtime, either through Spectrum
system management UI, or through integrations into emerging standards
for compartmentalized desktop computing
like <a href="https://github.com/flatpak/xdg-desktop-portal">XDG
Desktop Portals</a>, which allow applications to ask for additional
privileges through a standard interface, which must be confirmed by
trusted user input before being granted.
<p>
Initial versions of Spectrum will have the user be responsible for
writing Nix code for each application and resource, and the
combinations they make between them. In future, it would be good if
this could be handled by a graphical interface and a data file for
simple cases, with Nix importing the data file and using it as input
for the standard functions that would be called in a Nix-language
configuration file. This use case should be kept in mind when writing
the Nix API for Spectrum.
<p>
Spectrum is expected to largely run on personal computers, most of
which will almost certainly use the x86_64 or aarch64 architectures.
Unfortunately, these common architectures are the most lacking in
terms of trustworthiness. All require unauditable proprietary blogs
to boot, and
the <a href="https://en.wikipedia.org/wiki/Intel_Management_Engine">Intel
Management
Engine</a>, <a href="https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor">AMD
Platform Security Processor</a>,
and <a href="https://en.wikipedia.org/wiki/ARM_architecture#Security_extensions">ARM
TrustZone</a>, all of which are constantly running highly privileged,
unauditable code. A backdoor or compromise in any of this code could
give complete access to the system, invisibly to running the operating
system. As more functionality is moved into these environments, the
attack surfaces grow larger and larger, and
already <a href="https://en.wikipedia.org/wiki/Intel_Management_Engine#Security_vulnerabilities">many
vulnerabilities</a> have been demonstrated in the most studied of
these systems, Intel's Management Engine. Fears of backdoors are not
unjustified either — VIA C3 x86 CPUs used in personal computers have
been found to contain
a <a href="https://i.blackhat.com/us-18/Thu-August-9/us-18-Domas-God-Mode-Unlocked-Hardware-Backdoors-In-x86-CPUs-wp.pdf">hardware
backdoor</a> allowing local privilege escalation.
<p>
I would like Spectrum to additionally have first class support for at
least ppc64le. This is the only other architecture that can come
close to the sheer performance x86_64 can offer at the high end, and
in stark contrast to x86_64, it is possible to buy a new ppc64le
(POWER9) system that does not require any proprietary firmware that
cannot be inspected and audited. One of the advantages of Spectrum's
Linux base is the extremely wide hardware support that Linux offers,
so the only blocker for POWER9 support is support in crosvm for
virtualizing that architecture, which is outside the expertise of
anybody currently working on Spectrum but would be a very welcome
contribution.
<p>
Ideally, all Spectrum packages, for all architectures, would be built
on diverse hardware including a platform with POWER9's level of
openness. Even if a user has to trust the x86_64 computer available
to them, anti-freedom firmware, undocumented backdoors and all, they
would be able to benefit from binary packages that were built on
trustworthy hardware without these limitations. Unfortunately,
preliminary research has shown that x86_64 virtualization on POWER9 is
not currently sufficiently performant for this to be feasible.
<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>
|