diff options
| author | Alyssa Ross <hi@alyssa.is> | 2024-01-14 12:57:48 +0100 |
|---|---|---|
| committer | Alyssa Ross <hi@alyssa.is> | 2024-01-14 12:57:48 +0100 |
| commit | 1e10721674d20a0a64b3affe97965a9dc12bb9f8 (patch) | |
| tree | 93a47151129a7abd347b3fa8e971ede2429988a9 | |
| parent | fe48604d82067271e2b109afae4e37456b588f53 (diff) | |
| download | www-1e10721674d20a0a64b3affe97965a9dc12bb9f8.tar www-1e10721674d20a0a64b3affe97965a9dc12bb9f8.tar.gz www-1e10721674d20a0a64b3affe97965a9dc12bb9f8.tar.bz2 www-1e10721674d20a0a64b3affe97965a9dc12bb9f8.tar.lz www-1e10721674d20a0a64b3affe97965a9dc12bb9f8.tar.xz www-1e10721674d20a0a64b3affe97965a9dc12bb9f8.tar.zst www-1e10721674d20a0a64b3affe97965a9dc12bb9f8.zip | |
Update descriptions of the project and system
There hasn't been a This Week in Spectrum email in ages, but there are now the regular development streams, so it makes more sense to point there as a way to follow current developments in the project. The descriptions of the system had become very out of date, having mostly been written during preliminary stages before I even began putting the Spectrum system together, and at the same time, were very specific in how they envisaged the system working in ways I'm no longer sure about. So I've updated those descriptions to reflect current reality, and reduced the focus on things that are not implemented (or at least designed) yet. Signed-off-by: Alyssa Ross <hi@alyssa.is>
| -rw-r--r-- | design.html | 161 | ||||
| -rw-r--r-- | index.html | 32 |
2 files changed, 67 insertions, 126 deletions
diff --git a/design.html b/design.html index 07fd280..51e0b77 100644 --- a/design.html +++ b/design.html @@ -1,5 +1,5 @@ <!doctype html> -<!-- SPDX-FileCopyrightText: 2019-2020, 2022 Alyssa Ross <hi@alyssa.is> --> +<!-- 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"> @@ -23,24 +23,23 @@ <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 +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://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 +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> @@ -50,115 +49,53 @@ 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. +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> -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. +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> -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. +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 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. +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> -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. +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> -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. +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 diff --git a/index.html b/index.html index 11fa6ca..5e59911 100644 --- a/index.html +++ b/index.html @@ -1,5 +1,5 @@ <!doctype html> -<!-- SPDX-FileCopyrightText: 2019-2020, 2022 Alyssa Ross <hi@alyssa.is> --> +<!-- 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"> @@ -36,13 +36,14 @@ managed as a whole, rather than mixed up in several dozen virtual machines. <p> -The host system and isolated environments will all be managed -declaratively and reproducibly -using <a href="https://nixos.org/nix/">Nix</a>, a purely functional -package manager. This will save the user the burden of maintaining -many different virtual computers, allowing finer-grained resource -access controls and making it possible to verify the software running -across all environments. +Spectrum is an upstream-first project. Wherever possible, we aim to +participate in cross-project collaboration to move the entire free +desktop ecosystem forward, rather than desgining Spectrum-specific +solutions. This reduces the amount of software that Spectrum as a +small project is solely responsible for maintaining, and it derisks +the project — even if Spectrum does not achieve all its goals, our +efforts will have resulted in improvements across the board of free +desktop systems. <p> Spectrum is free software, currently under active development. If you @@ -51,10 +52,12 @@ in <a href="https://spectrum-os.org/doc/contributing/communication.html">partici we'd love to have you. <p> -Funding for Spectrum is provided +Spectrum is mostly funded through individual donations +on <a href="https://github.com/sponsors/alyssais">GitHub Sponsors</a> +and <a href="https://liberapay.com/qyliss">LiberaPay</a>. Additional +funding is provided by <a href="https://www.ngi.eu/about/ngi-zero/">NGI Zero</a>, an -initiative by the Digital Single Market of the European -Commission. +initiative by the Digital Single Market of the European Commission. <nav> <h2>Further reading</h2> @@ -68,9 +71,10 @@ Commission. <h2>Development progress</h2> <p> - Occasional detailed updates are - <a href="https://spectrum-os.org/lists/hyperkitty/search?q=This+Week+in+Spectrum&page=1&mlist=discuss%40spectrum-os.org&sort=date-desc">posted</a> - on the “discuss” mailing list. + There are regular <a href="https://live.qyliss.net/">Spectrum + development streams</a>, + with <a href="https://diode.zone/c/spectrum/videos">recordings</a> + available. <h2>Getting involved</h2> |