diff options
author | Alyssa Ross <hi@alyssa.is> | 2019-12-23 00:38:38 +0000 |
---|---|---|
committer | Alyssa Ross <hi@alyssa.is> | 2019-12-23 00:39:56 +0000 |
commit | 7557138bad3f3284dba1bdf0f6e00305b4a63a33 (patch) | |
tree | 927d18e721f31cbe9d2d0fb739ac227dbe54338f | |
parent | d3ad1952235f01e351ca3ecb52c45563ac849591 (diff) | |
download | www-7557138bad3f3284dba1bdf0f6e00305b4a63a33.tar www-7557138bad3f3284dba1bdf0f6e00305b4a63a33.tar.gz www-7557138bad3f3284dba1bdf0f6e00305b4a63a33.tar.bz2 www-7557138bad3f3284dba1bdf0f6e00305b4a63a33.tar.lz www-7557138bad3f3284dba1bdf0f6e00305b4a63a33.tar.xz www-7557138bad3f3284dba1bdf0f6e00305b4a63a33.tar.zst www-7557138bad3f3284dba1bdf0f6e00305b4a63a33.zip |
design: expand on inter-VM communication
-rw-r--r-- | design.html | 91 |
1 files changed, 60 insertions, 31 deletions
diff --git a/design.html b/design.html index b927bea..ca70c01 100644 --- a/design.html +++ b/design.html @@ -28,42 +28,71 @@ 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-wayland feature, or failing that -through <a href="https://xpra.org/">Xpra</a>. 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. +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, and will have a -completely immutable root file system. Persistent storage will be -provided by virtual block devices, that arbitrary paths on the system -can be mapped to from the host. 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. +a <a href="https://nixos.org/nix/">Nix</a> derivation. System and +user files within a VM will be shared, to reduce overhead. 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> -Virtual block devices will also be defined in Nix, and block devices -and applications will be <var>m</var>:<var>n</var>. Some virtual -machines may have no persistent storage, or even write access to a -disk, at all. In other cases, it might be desirable for multiple -applications to be able to access the same device, such as a local -mail store being shared by two mail clients. 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), 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. +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 |