- Spectrum Discuss - spectrum-os.org

I'm on a panel at the NGI Forum tomorrow
by Alyssa Ross 29 May '21

29 May '21

Tommorow (2021-05-19) at 7:30 UTC, I'm going to be part of a panel discussion at the NGI Forum. NGI is the EU initiative that funds my work on Spectrum. The topic of the panel is "Internet of Trust", and it'll be streamed here: https://2021.ngiforum.eu/ There's a bit more information about the panel in the agenda here: https://prod5.assets-cdn.io/event/6431/assets/8379007230-30f8d8b6fb.pdf

3 4

Proxying Wayland for untrusted clients
by Alyssa Ross 25 May '21

25 May '21

I've been thinking a lot about this for a while, thanks to conversations with Thomas and Puck, CCed here. I think it's time to put it into words properly and start working towards making it happen. One of the benefits that Wayland is supposed to have over X11 is security. A Wayland application isn't supposed to be able to record the screen without user permission, for example. But in most compositors, it can, with no restrictions. Existing Wayland compositors are monolithic, and each one would have to implement its own access controls. (Mutter already does this to some extent, at least for screen sharing, I believe.) The popular Wayland compositors are largely focused on being feature-complete reimplementations of their X11 equivalents, and so taking advantage of the security features and access controls the Wayland protocol makes possible hasn't been a priority for them. Additionally, every popular Wayland compositor is written in a memory-unsafe language, and this combined with the complexity of the Wayland protocol, with all the extensions involved, presents a serious concern to applications of Wayland that involve untrusted clients. To solve these problems, I propose a proxy program that sits between Wayland clients and the compositor, in the same privelege domain as the compositor. The proxy would decode and re-encode every Wayland request (client->compositor message), and would discard any request it didn't understand. This would mitigate the problem of a large, privileged program written in a memory-unsafe language being exposed to untrusted inputs. Additionally, the proxy would support a plugin interface, through which the user of the proxy (or their distributor) could configure custom behaviour. This could be used to prompt the user for confirmation before allowing a screen capture request, or even to implement a similar thing for e.g. clipboard access, for which there is no support in the Wayland protocol. It could even be used to modify surfaces, to implement things like Qubes-style unspoofable coloured window borders. This approach would allow permissions systems and other custom Wayland behaviour to be implemented in a compositor-independent manner. Distributions which suppor tseveral compositors could implement customisations in a single place, and users of compositors which lack security features and the assurances memory-safety can provide against untrusted input would gain access to those things. I'd like to hear feedback here, but I think early in the life of this idea we should also reach out to the broader Wayland community. I think there's a lot of potential for this idea beyond Spectrum, and it would be great if it could be something developed with input from a big breadth of Wayland users. If we can do that, it might be sensible for it to live at freedesktop.org? I'm not sure how that works. Let me know what you all think. :)

4 8

Re: Proxying Wayland for untrusted clients
by Josh DuBois 22 May '21

22 May '21

On May 22, 2021, at 8:05 AM, Alyssa Ross <hi(a)alyssa.is> wrote: > > One of the benefits that Wayland is supposed to have over X11 is > security. A Wayland application isn't supposed to be able to record the > screen without user permission, for example. But in most compositors, > it can, with no restrictions. <snip> > > To solve these problems, I propose a proxy program that sits between > Wayland clients and the compositor, in the same privelege domain as the > compositor. <snip> > If we can do that, it might be sensible for > it to live at freedesktop.org? I'm not sure how that works. I am curious, if you have time, to hear more on why the approach of a proxy vs picking a compositor and implementing security there. If the problem is that the Wayland community so far has not considered security a priority, it seems that a security proxy may suffer from those same forces. Basically, will it be easier to attract developers or gain widespread adoption of a proxy as opposed to getting buy-in to do security directly in a compositor? You mention writing in a memory safe language and having a compositor neutral solution as technical advantages. Do you think a proxy is a good choice primarily because it can achieve a better technical result, or is the choice of a new component more a matter of difficulty getting community buy-in from a popular compositor and doing security there? How would you weigh the upsides of a new project against the difficulties of getting a new thing off the ground and adopted? (This is really just curiosity on my part and my $0.02 from the outside. You may have already had a lot of discussions about that, or even already tried talking to compositor folk and not gotten traction. Seems worth some explicit consideration.)

2 1

[DEMO] virtio-vhost-user between QEMU and crosvm
by Alyssa Ross 13 May '21

13 May '21

Introduction ------------ Virtio-vhost-user[1] is a promising virtualisation technology that allows virtual devices that are exposed to VMs to themselves be implemented in VMs. Let's break down its name a bit to understand how it works: * Virtio[2] is a standard driver interface for virtualisation. Interfaces are available for all sorts of types of virtual devices, e.g. virtio-net, virtio-blk, and virtio-scsi. Typically, virtio devices are implemented by a virtual machine monitor (VMM). * Vhost[3] is kernelspace implementation of virtio virtual devices, created for their performance benefit. Instead of implementing the virtual devices itself, the VMM talks to the kernel implementation of them using a special ioctl protocol. * Vhost-user[4] allows another process to implement the vhost protocol, instead of the kernel, by using a UNIX socket instead of ioctls on a special character device. This doesn't provide the raw performance of vhost, but it serves a different purpose -- it allows virtual devices to be implemented by external programs, in a standardised way so they're portable between VMMs. Virtio-vhost-user allows the program implementing the virtual device to run in a VM of its own, by having the VMM for that VM create the vhost-user socket, and transferring messages over it to its guest using virtio. This is exciting for Spectrum, because it would mean that the host system doesn't have to interact with physical hardware directly beyond the PCI level, and can instead pass it through to a VM, which is responsible for implementing the virtual device backed by that physical hardware, which can be exposed to other VMs. Last year I spent a while looking into virtio-vhost-user[5][6][7]. It's a long way from being ready to use, and it seems to be maturing very slowly. It might be useful to us eventually for driver isolation, or something else might come along. My conclusion from my research was that we should decide later, once the ecosystem has had a chance to develop. But I wanted something to come out of the research I did anyway, and so I've prepared a demonstration. [1]: https://wiki.qemu.org/Features/VirtioVhostUser [2]: https://docs.oasis-open.org/virtio/virtio/v1.1/virtio-v1.1.html [3]: https://blog.vmsplice.net/2011/09/qemu-internals-vhost-architecture.html [4]: https://qemu.readthedocs.io/en/latest/interop/vhost-user.html [5]: https://spectrum-os.org/lists/archives/spectrum-devel/87pn8rezqn.fsf@alyssa… [6]: https://spectrum-os.org/lists/archives/spectrum-devel/87blk1pwph.fsf@alyssa… [7]: https://spectrum-os.org/lists/archives/spectrum-devel/87wo2glkg0.fsf@alyssa… What the demo does ------------------ Using any sort of non-host-based virtual device implementation is going to have to start with taking the virtual device implementation out of the VMM running an application VM, and vhost-user the clear solution to this. Vhost-user isn't supported by crosvm -- its focus is on doing all the virtualisation required by Chromium OS, so there's no need for it to allow other programs to provide virtual device implementations. So another part of the research I did was to try to port the vhost-user implementation from cloud-hypervisor to crosvm, which I was able to do successfully[8]. This has implications beyond vhost-user, and even beyond crosvm, because it demonstrates that it's practical to port features between rust-vmm[9] VMMs, which means we don't have to worry about finding one that provides every feature we need (which is just as well, because there isn't one). So here I demonstrate not just a "standard" virtio-vhost-user setup (to the extent that such a thing can exist at this early stage), but also that my patched crosvm with vhost-user support is capable of interoperating with the experimental virtio-vhost-user implementation for QEMU, because both are speaking the standardised vhost-user protocol. The demo sets up two VMs. One is run with my patched crosvm, and expects a virtual ethernet device to be provided by a vhost-user socket. When it boots, it brings up its network interface, tries to run a DHCP client, and then exits. The other VM is run with Nikos Dragazis and Stefan Hajnoczi's experimental virtio-vhost-user implementation in QEMU[10]. It gets a standard virtual ethernet device (backed by a TAP device on the host), and the virtio-vhost-user device hooked up to the socket that crosvm will be connecting to. Inside the VM, a userspace networking stack (DPDK, again modified to support virtio-vhost-user by Nikos Dragazis[11]) implements the device side of virtio-vhost-user, and forwards packets sent by crosvm's guest to the virtual ethernet device backed by the host TAP. +-----------------------------------------------------------------------------+ | | | +------------------------+ +------------------------+ | | | | | | | | | +----------------+ | | +----------------+ | | | | | | | | | | | | | +-----+ | | +--------+ | | | | | | | | | TAP +------+---+---+ DPDK +---+---+------+---+ | | | | +-----+ | | +--------+ | | | | | | | | | | | | | | | | | | | | Linux | | | | Linux | | | | | +----------------+ | | +----------------+ | | | | | | | | | | QEMU | | crosvm | | | +------------------------+ +------------------------+ | | | | Linux | +-----------------------------------------------------------------------------+ A complicating factor is that the virtio-vhost-user implementation for DPDK only supports outgoing traffic[12]. So packets coming from crosvm will be relayed to the TAP, but not the other way around. This means that we can't just use ping inside the crosvm VM to verify that the connection is working. Instead, we have to tcpdump on the host and verify that the packets the DHCP client inside the crosvm VM is sending are arriving on the TAP. For this to be useful for our intended purpose of isolating drivers for physical devices, we'd pass through the device here rather than using a TAP. It would otherwise work exactly the same, but it's more difficult to test it's working correctly. (I have tested it though -- for the first version of this I got working last year, I verified it worked by checking the logs of my local network's DHCP server.) [8]: https://spectrum-os.org/lists/archives/spectrum-devel/20210512170812.192540… [9]: https://github.com/rust-vmm [10]: https://github.com/ndragazis/qemu/tree/virtio-vhost-user [11]: https://github.com/ndragazis/dpdk-next-virtio/tree/virtio-vhost-user [12]: https://github.com/ndragazis/dpdk-next-virtio/blob/2d60e63/drivers/virtio_v… Running the demo ---------------- First, create a TAP device for QEMU to use: # ip tuntap add qemutap mode tap # ip link set qemutap up Start tcpdump, so we can see if packets arrive on the TAP: # tcpdump -i qemutap Start the QEMU VM: $ $(nix-build -A qemuVm /path/to/demo.nix) When you see "Press enter to exit", DPDK is ready to receive a virtio-vhost-user connection. Start the crosvm VM: $ $(nix-build -A crosvmVm /path/to/demo.nix) Once that VM boots, you should see some "BOOTP/DHCP" lines in the tcpdump output. This demonstrates that traffic from the crosvm guest has been relayed over virtio-vhost-user to DPDK, and then to the TAP on the host over virtio-net. You'll want to press enter to shut down the QEMU VM now, because DPDK pegs a CPU core (for reasons[*] unrelated to virtio-vhost-user that are out of scope here). Then you can remove the TAP device: # ip link delete qemutap Nix expression for the demo --------------------------- # SPDX-License-Identifier: MIT OR Apache-2.0 # SPDX-FileCopyrightText: 2021 Alyssa Ross <hi(a)alyssa.is> let pinned = builtins.fetchTarball { url = "https://github.com/NixOS/nixpkgs/tarball/b14062b75c4e8ef4dd4110282f7105be87…"; sha256 = "1hzs0w6pcwwbzl2gkqyk46yrzizzm03mph4kggws02a6vlwphsib"; }; in { pkgs ? import pinned {} }: with pkgs; rec { linux = pkgs.linux.override { structuredExtraConfig = with lib.kernel; { "9P_FS" = yes; NET_9P = yes; NET_9P_VIRTIO = yes; PACKET = yes; VFIO = yes; VFIO_NOIOMMU = yes; VFIO_PCI = yes; VIRTIO_NET = yes; VIRTIO_PCI = yes; }; }; dpdk = stdenv.mkDerivation { name = "dpdk-virtio-vhost-user"; src = fetchFromGitHub { owner = "ndragazis"; repo = "dpdk-next-virtio"; rev = "0a46582dc1d02c0dc5069347ffff1a64239385f2"; sha256 = "169cxdps9k764jj420q44262x3291h2jcqsbrh7038hqjczjkgif"; }; buildInputs = [ numactl ]; configurePhase = '' runHook preConfigure make $makeFlags defconfig runHook postConfigure ''; enableParallelBuilding = true; RTE_KERNELDIR = "${linux.dev}/lib/modules/${linux.modDirVersion}/build"; NIX_CFLAGS_COMPILE = [ "-Wno-error=implicit-fallthrough" "-Wno-error=incompatible-pointer-types" ]; makeFlags = [ "RTE_OUTPUT=$(out)/lib" "kerneldir=$(out)/lib/modules/${linux.modDirVersion}/build" "prefix=$(out)" ]; inherit (pkgs.dpdk) meta; }; # DPDK is huge! We just need one program from it. testpmd = runCommandNoCC "testpmd" {} '' mkdir -p $out/bin cp ${dpdk}/bin/testpmd $out/bin ''; # qemu has changed build system since the virtio-vhost-user branch # was last updated, so it's simpler to just make a new derivation # and inherit the bits that are the same than to override the # existing one. qemu = stdenv.mkDerivation { name = "qemu-virtio-vhost-user"; src = fetchFromGitHub { owner = "ndragazis"; repo = "qemu"; rev = "f9ab08c0c8cfc58036ed95b895f9780397448071"; sha256 = "0p6v4i7gj70d6x7s28x3i3x9z8vlswcbbqdwfbhlx87bbnxjrn3b"; fetchSubmodules = true; }; enableParallelBuilding = true; nativeBuildInputs = lib.subtractLists [ ninja meson ] qemu_kvm.nativeBuildInputs; postPatch = '' sed -i '/$(INSTALL_DIR) "$(DESTDIR)$(qemu_localstatedir)/d' Makefile # The virtio-vhost-user implementation tries to allocate a huge # PCI bar, that's bigger than some CPUs can support! If you see # a kernel panic in vp_reset(), lower this further. substituteInPlace hw/virtio/virtio-vhost-user-pci.c \ --replace '1ULL << 36' '1ULL << 34' ''; inherit (qemu_kvm) buildInputs configureFlags meta; }; qemuInitramfs = makeInitrd { contents = [ { symlink = "/init"; object = writeScript "init" '' #!${busybox}/bin/sh -eux export PATH=${busybox}/bin mkdir -p /nix/store /run /var mount -t sysfs none /sys mount -t proc none /proc mount -t tmpfs none /run mount -t devtmpfs none /dev mkdir /dev/hugepages mount -t hugetlbfs none /dev/hugepages ln -s /run /var # Unbind the virtio-net (host TAP) and virtio-vhost-user devices # from their default drivers, since we'll be passing them # through to DPDK. echo 0000:00:04.0 > /sys/bus/pci/devices/0000:00:04.0/driver/unbind echo 0000:00:05.0 > /sys/bus/pci/devices/0000:00:05.0/driver/unbind # Tell the vfio-pci driver it can support virtio-net and # virtio-vhost-user devices. Since our devices are not # bound to any driver at the moment, doing this will bind # them to vfio-pci automatically. echo 1af4 1000 > /sys/bus/pci/drivers/vfio-pci/new_id echo 1af4 1017 > /sys/bus/pci/drivers/vfio-pci/new_id echo 256 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages ${testpmd}/bin/testpmd \ -l 0-1 \ -w 0000:00:05.0 \ --vdev net_vhost0,iface=0000:00:05.0,virtio-transport=1 \ -w 0000:00:04.0 poweroff -f ''; } ]; }; qemuVm = writeShellScript "qemu-vm" '' exec ${qemu}/bin/qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 1G \ -M q35,kernel-irqchip=split \ -initrd ${qemuInitramfs}/initrd \ -netdev tap,id=net0,ifname=qemutap,script=no,downscript=no \ -device virtio-net-pci,netdev=net0,addr=04 \ -chardev socket,id=chardev0,path="$XDG_RUNTIME_DIR/vhost-user0.sock",server,nowait \ -device virtio-vhost-user-pci,addr=05,chardev=chardev0 \ -kernel ${linux}/${stdenv.hostPlatform.linux-kernel.target} \ -append "console=ttyS0 vfio.enable_unsafe_noiommu_mode=1" \ -nographic ''; # Can't use overrideAttrs because of cargoSha256. crosvm = rustPlatform.buildRustPackage rec { name = "crosvm-virtio-vhost-user"; src = fetchFromGitiles { url = "https://chromium.googlesource.com/chromiumos/platform/crosvm"; rev = "8a7e4e902a4950b060ea23b40c0dfce7bfa1b2cb"; sha256 = "1lm6psp0xakb66nhgmmh94valc4wzbb967chk80msk8bcvsfpdn4"; }; unpackPhase = let origSrc = pkgs.crosvm.passthru.src; in builtins.replaceStrings [ "${origSrc}" origSrc.name ] [ "$src" src.name ] pkgs.crosvm.unpackPhase; cargoPatches = [ (fetchpatch { url = "https://spectrum-os.org/lists/archives/spectrum-devel/20210512170812.192540…"; sha256 = "0yzqrpgq35s9wxvbf9s3dgs5cpyxgdc5hr14hsdjr0gd18a6camg"; }) ]; patches = pkgs.crosvm.patches ++ [ (fetchpatch { url = "https://spectrum-os.org/lists/archives/spectrum-devel/20210512170812.192540…"; sha256 = "0g2rvqqa4lvq7bjq0s1ynsjx7lmrxql7lsdv8wyzb7d2z9j6mj13"; }) (fetchpatch { url = "https://spectrum-os.org/lists/archives/spectrum-devel/20210512170812.192540…"; sha256 = "051sz87i8kzc5sbygk2bpiqp4g32y9fxswg2yax1nd3lg4rxh43r"; }) (fetchpatch { url = "https://spectrum-os.org/lists/archives/spectrum-devel/20210512170812.192540…"; sha256 = "1jpas65masn2xg9jxha16vi0y7scarzhl221y9wxh4chi4aa4m3f"; }) ]; cargoSha256 = "07yizbhs64jrb05fq5g7sx812xbz2989bsficacq5l19ziax5164"; passthru = pkgs.crosvm.passthru // { inherit src; }; inherit (pkgs.crosvm) sourceRoot postPatch nativeBuildInputs buildInputs preBuild postInstall CROSVM_CARGO_TEST_KERNEL_BINARY meta; }; crosvmInitramfs = makeInitrd { contents = [ { symlink = "/init"; object = writeScript "init" '' #!${busybox}/bin/sh -eux export PATH=${busybox}/bin mount -t sysfs none /sys mount -t proc none /proc ip link set eth0 up udhcpc -n || : reboot -f ''; } ]; }; crosvmVm = writeShellScript "crosvm-vm" '' # In our patched crosvm, suppling --mac without --host_ip or # --netmask will put it into vhost-user mode. exec ${crosvm}/bin/crosvm run \ --mac 0A:B3:EC:FF:FF:FF \ -i ${crosvmInitramfs}/initrd \ ${linux}/${stdenv.hostPlatform.linux-kernel.target} ''; }

1 0

Git server issues?
by Jamie McClymont 01 Apr '21

01 Apr '21

Hello, Cloning the spectrum nixpkgs repo seems to consistently fail, after downloading all the objects, with: fetch-pack: unexpected disconnect while reading sideband packet fatal: early EOF fatal: fetch-pack: invalid index-pack output Have confirmed this across a couple of networks. Relatedly, the git web interface seems to always 504 Gateway Timeout while a clone is in progress. I wonder if the git server is configured to only handle one thread/request at a time, and the clone process involves 2 concurrent requests? (either that, or the server is actually overloaded). fyi, as a workaround: clone nixpkgs from elsewhere, then add the spectrum nixpkgs remote and fetch - it will also be much faster :) Thanks - Jamie McClymont

2 1

This Week in Spectrum, 2021-W10
by Alyssa Ross 14 Mar '21

14 Mar '21

Surprise! I sent the last This Week in Spectrum in August. Since then, it's been pretty quiet. What happened? Towards then end of last year, I was aggressively pushing to achieve a funding milestone, but was starting to struggle to keep myself going. After that last TWiS, I decided to stop posting them for a while to fully concentrate on the push. I continued like that for two more months, before getting to the point where I was so burned out I just couldn't keep going, with the milestone still not done, the work I had done so far on it unpublished (and not in a good state to be published), and time running out. Fortunately, I was able to talk to NLnet, and they agreed to extend my funding deadlines and renegotiate the milestones. With that sorted out, in late November I began a hiatus from Spectrum to allow myself to recover from the burnout. I'm very grateful to my GitHub Sponsors, thanks to whom I was able to take this time to recover. I tried to come back at the end of January, but after a single day of Spectrum work I was feeling much the same as I had been in November. This week, though, something changed! I've been working on Spectrum again for the last week, and I've been feeling great about it! Now, there were three months of work between the last TWiS in August, and the start of my hiatus. That's a lot of work I haven't written about. But I think the only way this is really going to work is if I leave that largely unwritten about for now, because TWiS tends to be thousands of words long even when it's covering a single week of work. So I'm just going to talk about what I've done in the last week, explaining context from previous work as necessary. With all that in mind, here we go! "Qubes-lite with KVM and Wayland"[1] ------------------------------------ First up is something somebody else did, which is always nice! Thomas has been doing his own great work replacing his Qubes system with a system built on NixOS, using KVM and Wayland. Thomas got in touch on the Spectrum discuss mailing list in January[2] asking some questions about how some things were implemented, and we went back and forth a bit then (although not as much as I'd have liked, due to my burnout :/). Since then, he's come up with some awesome stuff, like an OCaml implementation of a virtio-wayland proxy (equivalent to Sommelier in Chromium OS). In our further conversation prompted by Thomas's article, Thomas raised a further interesting idea[3] -- what if we had a Sommelier-like Wayland proxy, but that ran in the same security domain as the compositor. That way, we could filter to allow only the protocol extensions we want to. We could implement our own permissions when the compositor doesn't. This code would be responsible for securely handling Wayland messages from an untrusted guest, which would be beneficial because it would be a lot less code to audit, and because it could be written in a memory-safe language. This would avoid the need to write or find a secure Wayland compositor, and would in fact allow us to use virtually any compositor without having to worry nearly as much about its security credentials. I'm very excited by that idea, and I've been asking myself for the past few days why I didn't think of it before! I've thought several times "it's quite nice that Sommelier gives us a known subset of Wayland, but it's a shame we can't rely on it since it runs inside a application guest". But for some reason it just never occurred to me to follow that idea one step further, to "what if we had a similar program that run in the compositor's security domain". [1]: https://roscidus.com/blog/blog/2021/03/07/qubes-lite-with-kvm-and-wayland/ [2]: https://spectrum-os.org/lists/archives/spectrum-discuss/CAG4opy_hz_ESEpY0Tq… [3]: https://spectrum-os.org/lists/archives/spectrum-discuss/CAG4opy_JztAH3tD+ZU… uscpi-vsock ----------- ucspi-vsock[4] is a program I started writing in September. VSOCK[5] is a special Linux socket type that allows for communication between VMs, and I'm using it to allow services running in VMs (a USBIP daemon, for example), to notify the host (and by extension other VMs), when the service in the VM becomes ready to accept connections. USCPI[6] is a standard command interface for making it easy to do socket communication using standard IO primitives, without having to teach programs how to do socket connections for every kind of socket. There are several UCSPI implementations for common socket types like Internet and Unix domain sockets, but until now there was not one for VSOCK. So, for example, in a VM we can do: vsockclient 2 $port sh -c 'echo >&7' Which will connect to the host over VSOCK (in VSOCK the host is always address 2), write a newline, and close the connection. UCSPI lets us implement this with standard shell tools. There's an equivalent "vsockserver" program for the other end, that will run a command whenever a connection is received. Anyway, this week I went back to ucspi-vsock to fix some bugs[7][8][9][10]. As usual, (although I'm happy to realise this is still the case after all these months!) Cole was kind enough to review my patches. [4]: https://spectrum-os.org/git/ucspi-vsock/ [5]: https://man7.org/linux/man-pages/man7/vsock.7.html [6]: https://cr.yp.to/proto/ucspi.txt [7]: https://spectrum-os.org/lists/archives/spectrum-devel/20210309154048.14474-… [8]: https://spectrum-os.org/lists/archives/spectrum-devel/20210309171816.8589-1… [9]: https://spectrum-os.org/lists/archives/spectrum-devel/20210310204516.20041-… [10]: https://spectrum-os.org/lists/archives/spectrum-devel/20210310204555.20725-… Interguest networking --------------------- The bulk of my work this week has been in Spectrum's Nixpkgs, which is where (for now, at least) all the VM definitions and stuff live. Mostly, I've been trying to clean up months of frantic work into something I can actually publish as a series of patches, so it's out there instead of just on my computer! My focus at the moment is on doing this with the interguest networking implementation I wrote last year. The plan for this remains the same as last year: have a VM that manages all network hardware access and acts as a router for other VMs that need to talk to the outside world. Eventually, this will hopefully use virtio-vhost-user[11], which will allow us to avoid going through a networking stack on the host at all (or even having one), but until virtio-vhost-user is further along, we'll use bridge devices on the host to connect client VMs to the router. A very basic version of the latter is implemented and working for me locally -- I can run an application VM, and have it connect to another VM which runs the drivers for my ethernet port using VFIO (PCI passthrough). This code was a big ball of mud, and I'd also subtly broken it when I moved on from interguest networking last year to try to get a proof of concept going for another form of interguest communication. So I spent this week trying to page all the context I'd lost in the last few months back into my brain, making lots of partial git commits, writing commit messages, and fixing it up so that it works again. I think what I have is about ready to publish -- hopefully you'll see some patches next week. But what exists at the moment is still very limited -- the biggest limitation is that the router VM doesn't support hotplugging, so a VM that wants to connect to it actually has to be started first, before the router VM. Not good for something that should be run as a system service and likely started on boot! To overcome this limitation, I'll probably have to add support in crosvm for adding network devices at runtime using the control socket. I think this should be easy enough, and I haven't looked at what's happened in crosvm + rust-vmm since I've been away, so it's even possible somebody else will have done this already. [11]: https://wiki.qemu.org/Features/VirtioVhostUser So, the todo list for next week is getting the initial interguest networking PoC patchset posted. That'll come with a nice little demo other people will be able to try out if they want to. And then, I'll work on improving it further to the point where it's actually practical. I don't want to spend /too/ much time on this, since ultimately I do want to be using a virtio-vhost-user stack, which is quite different, but it's important to have an implementation of this so there's something to test further development (that doesn't care about the implementation details) against. My biggest worry at the moment is burning out again. Working in moderation isn't easy for me (I tend to get very sucked into things), but it's important for the project that I find a way to keep my work sustainable, so we don't lose time like this again. I'm still a little hesitant to say "this is it, I'm back for real". But the signs are looking good. Thank you for sticking with me through this.

1 0

This (and Last) Week in Spectrum, 2020-W34 & 2020-W35
by Alyssa Ross 26 Aug '20

26 Aug '20

Last week I wasn't feeling well, so there was no This Week in Spectrum. crosvm ------ Where we left off, I had been attempting to port vhost-user-net support from cloud-hypervisor to crosvm. I'd been trying to port the first incarnation of the code in cloud-hypervisor to the contemporary version of crosvm from when it was added, thinking that that would be easier because the two codebases together. But I ran into the problem that this earliest incarnation of the vhost-user-net code from cloud-hypervisor didn't actually work (at least with the backend I was attempting to test it with). I'd been attempting to figure out exactly which changes were required to make it work, but hadn't been successful with that yet, and I thought I'd probably need to start the port over, from the latest cloud-hypervisor and crosvm code. The next day, I decided to give my previous strategy one more try, though, and an hour or two later, I found the required cloud-hypervisor change, applied it to crosvm, and it worked! So I now have a crosvm tree capable of vhost-user-net[1]. This means that it's looking good for my plans for inter-guest networking, and network hardware isolation. With that in place, I decided to start thinking about other kinds of hardware isolation and inter-VM communication, and that's what I did for most of the last two weeks. Let's go through them: Files will be shared between VMs using virtio-fs. This has the unique feature of (soon) being able to bypass guest page caches, and have only a single shared cache between VMs. This brings a performance improvement, but as I understand it, should also reduce memory consumption because each VM won't have to maintain its own copy of a disk-backed page. Of course, this feature (DAX) is also a big side channel, so it won't be appropriate for all use cases. But I think for some things people want to do with Spectrum, this will be very important. The problem with this is that, because it uses the page cache of the host kernel, the host has to know about the filesystem that's being shared -- there's no running virtiofsd in a VM if we want DAX. But I'd really like it if a (non-boot) block device could be used as a filesystem without the host having to actually talk to the device. I was stuck here, but edef pointed out to me that we could use the kernel's 9P support to attach the block device to a VM, and then mounting the filesystem in the host over 9P, either over a network connection or (ideally) vsock. It looks like the kernel should be able to handle 9P over vsock, but I haven't tested yet. We can use existing virtiofsd and 9P software (there are promising Rust implementations of each), and harden them against potential vulnerabilites like directory traversals using kernel features like RESOLVE_BENEATH and RESOLVE_NO_XDEV. For the boot device, maybe there's no reason not to just mount it using the host kernel, or maybe there's something to be gained by just reading a small bootstrap payload into memory from the start of the disk once, and then making all future communication go via a VM. I'm not really sure yet. But the important thing is we'll have mechanisms for all this in place. Maybe we'll decide that non-boot devices should just go over inter-VM 9P, but in any case, we'll still need all these pieces. GPU isolation should be possible by forwarding the GPU to a VM, but there are a few problems here. The first is that it would mean rendered surfaces have to be copied via shared memory to the VM with the GPU, before being sent to the GPU. Additionally, sharing the GPU between VMs for rendering at all would require significantly more work. The result of this is that graphics performance using an isolated GPU will probably be poor, at least for now. The final problem is that passthrough of integrated GPUs seems to be very difficult to get right. I will probably need to acquire some hardware that I've sene a report of this working on, so I can figure out what I've been doing wrong on the two computers I've tried it on so far. I suspect that I will get GPU isolation working, but I'm not sure how reliable or performant it will be. For generic USB devices, I expect to be able to take an approach similar to Qubes[2], having a VM to handle interactions with the hardware USB controller, and exposing individual USB devices over USB/IP to other VMs. It would be nice if I could use vsock for this too. [1]: https://spectrum-os.org/git/crosvm/?h=vhost-user-net [2]: https://www.qubes-os.org/doc/usb-devices/ spectrum-os.org --------------- Philipp registered a Matrix room and bridged it to the #spectrum IRC channel. I'm told that this should make it easier for Matrix users to join the room, since some bug in Matrix's IRC bridge prevents people from joining from Matrix the usual way. Philipp also sent a patch[3] to improve the instructions for Matrix users joining the channel on the website. Thanks Philipp! [3]: https://spectrum-os.org/lists/archives/spectrum-devel/87wo247zu7.fsf@alyssa… QEMU ---- I sent the previously requested patch[4] to resolve ambiguities in the vhost-user spec. No response yet, though. I'll probably resend it some time soon. [4]: https://lore.kernel.org/qemu-devel/20200813094847.4288-1-hi@alyssa.is/ I'm finding it hard to keep going at the moment. The stuff I'm doing now is probably the hardest part of implementing Spectrum, and it's frustrating to realise that not everything I want to do is going to be possible. So much of the KVM ecosystem assumes that things will be host<->guest, and there's not always an easy solution. But, whatever we end up with, it's going to be a lot better than what I'm using today, and what lots of other people are using today. I think I'm going to be able to deliver a good experience with a fairly high degree of protection against malicious hardware. But it's not going to be perfect. I'm pushing quite hard to make it over the line with my hardware isolation funding milestone. I'm so close, and I'm about to need the money. But once I've hit that, I think I'm going to need a break. This stuff is gruelling.

2 1

This (Last) Week in Spectrum, 2020-W32
by Alyssa Ross 11 Aug '20

11 Aug '20

Last week, I'd just finished getting the cloud-hypervisor vhost-user-net frontend code to build as part of crosvm, and the next step was testing it. crosvm ------ I wrote some hacky code that replaced the virtio-net device creation in crosvm with an instance of the ported vhost-user-net code. When I booted crosvm, there were some of the expected simple oversights of mine that needed to be addressed, but once those were taken care of, it still didn't quite work. The VM boots, sees a network interface, and even communicates with the vhost-user-net backend! But, it doesn't quite work. The vhost-user-net code never realises/gets told that it has traffic, and so it's never processed. Unsure of what to do about this, I decided to turn to cloud-hypervisor and look at how the code ran there. cloud-hypervisor ---------------- I wanted to try running the cloud-hypervisor v-u-n backend I was using for testing (because it's much simpler than DPDK -- it just sends traffic to a TAP device) with QEMU as the frontend, because QEMU is a VMM I'm familiar with (much more so than cloud-hypervisor as the frontend), and I thought it would be useful to have a working frontend/backend combination to compare to. I had some problems, though, because apparently nobody had ever wanted to use QEMU with the cloud-hypervisor vhost-user-net backend before -- or if they had, they hadn't wanted to enough to make it work. The cloud-hypervisor backend didn't implement the vhost-user spec correctly in a few subtle ways that made it incompatible with QEMU. I won't explain every subtle issue, but I ended up writing a few patches[1][2] for cloud-hypervisor and the "vhost" crate it depends on (that is in the process of being moved under the rust-vmm umbrella). One interesting issue I will go into a little detail of was that the wording in the spec was a little unclear, and QEMU interpreted it one way, and cloud-hypervisor the other. I ended up sending an email[3] to the author of the spec asking for clarification. He answered my question, and we discussed how the wording could be improved. He liked my second attempt at improving my working, and asked me to send a patch, but preferably not right now, because QEMU is currently gearing up for a release, scheduled for next week if everything goes well. Since I wrote these cloud-hypervisor patches, and had to test them, I ended up having to learn how to use cloud-hypervisor anyway to make sure I hadn't broken it in fixing the backend up to work with QEMU. Oh well. Once this was done, I could use both QEMU and cloud-hypervisor with the backend, but not crosvm. But it was a little more complex than that. When I ported the v-u-n code to crosvm, I ported the first version of it that was added to the cloud-hypervisor tree, rather than the latest version. The theory here was that the earlier version would be closer to crosvm, because cloud-hypervisor would have had less time to diverge. Then, once I had that working, I could add on the later changes gradually. What I didn't account for here is that the initial version of the v-u-n frontend in cloud-hypervisor didn't really work properly, and needed some time to bake before it did. So having now had this experience I think it might be better to try to port the latest version, and accept that porting might be a bit harder, but the end result is more likely to work. [1]: https://github.com/cloud-hypervisor/vhost/pull/22 [2]: https://github.com/cloud-hypervisor/cloud-hypervisor/pull/1565 [3]: https://lore.kernel.org/qemu-devel/87sgd1ktx9.fsf@alyssa.is/ libgit2 ------- While bisecting cloud-hypervisor to see if I could figure out when the v-u-n frontend started working properly, I encountered a large section of commits that I couldn't build any more, because Cargo couldn't resolve a git dependency. The dependency was locked to a commit that was no longer in the branch it had been in when the cloud-hypervisor commit was from. Despite knowing the exact commit it needed, Cargo fetched the branch the commit used to be on. This is because it is generally not possible to fetch arbitrary commits with git. Some servers, like GitHub, do however allow this, and I wondered why Cargo wouldn't at least fall back to trying that. As it turns out, it actually couldn't do that, though! Cargo uses libgit2, and libgit2 doesn't support fetching arbitrary commits. So I wrote a quick patch to libgit2 to support this[4]. It's only a partial implementation, though, because I don't find libgit2 to be a particularly easy codebase to work in (although it's better than git!). So I'm hoping somebody who knows more about it than me will help me figure out how to finish it. [4]: https://github.com/libgit2/libgit2/pull/5603 Next week, I'm hoping that I'll be able to get to vhost-user-net in crosvm working. I think this will probably mean porting the code again, using the latest version. Which is a bit of a shame, but at least I have an idea of what to do next. I am, overall, feeling pretty optimistic, though. I'm pretty confident that we can get some sort of decent but imperfect network hardware isolation even though virtio-vhost-user might not be ready yet, which was something I was worried about before. I don't want to really go into detail in that now though because this is already a long email and it's already a day late because I was tired yesterday, but essentially, we could forward the network device to a VM that would run the driver, and forward traffic back to the host over virtio-net. The host could handle this either in kernelspace or userspace with DPDK, but the important thing is that the only network driver it would need to support would be virtio-net. No talking to hundreds of different Wi-Fi cards and hoping that none of the drivers have a vulnerability. So, not perfect compared to proper guest<->guest networking, but a step in the right direction, and one that should be as simple as possible to upgrade to virtio-vhost-user once that becomes possible.

1 0

This Week in Spectrum, 2020-W31
by Alyssa Ross 02 Aug '20

02 Aug '20

DPDK ---- Last week, I'd just figured out how to do a normal vhost-user setup with a QEMU VM connected to DPDK. This week, I wanted to try to move DPDK into another VM using the experimental virtio-vhost-user driver, taking the host system out of the networking equation altogether. In theory this should have been a very simple change, but I couldn't get it to work. DPDK claimed to be forwarding packets to the ethernet device I'd attached to the backend VM (the one running DPDK), but networking in the frontend VM (what you might think of as the application VM) didn't work at all. It tried and failed to do DHCP, and so couldn't progress beyond that. A breakthrough came when I thought to look at the logs of my local DHCP server. I saw that it was actually receiving requests from the VM, and assigning it an IP address. Once I realised this, I hypothesised that outgoing traffic was working, but not incoming. Finally having something to look for, I had a look through the DPDK virtio-vhost-user driver[1], and my suspicion was confirmed in an unexpected way. It looks like incoming traffic (from the perspective of the virtio-vhost-user frontend) is not actually implemented at all! But with outbound traffic working, this means that I'm confident enough I understand virtio-vhost-user enough to be able to leave this here for now. From Spectrum's side, I can now be pretty sure that everything should be workable, so we can just wait a bit for virtio-vhost-user to get a bit further along and then revisit it. And since the frontend has no idea it's talking to virtio-vhost-user instead of normal vhost-user, we can use normal (host-based) vhost-user for now, and drop virtio-vhost-user in down the line. A couple of outstanding questions I still don't know the answer to about DPDK are: - How will routing work if I have multiple frontend VMs with multiple virtio-vhost-user connections all wanting to use the same network device? Will I want to use something like Open vSwitch[2] for that? - DPDK by default uses a busyloop to check for data to process, for efficiency. This is obviously not appropriate for a workstation-focused operating system. There is an interrupt-based mode, though, but I don't know how to use it yet. Since I consider the concept proven, though, I'm going to punt on these for now. The longer I leave these questions, the more likely it is that a kernel driver for virtio-vhost-user will emerge and we can use that instead. That's not to say I want to leave inter-guest networking hanging forever, but I have other inter-guest networking bits I can switch focus to for now, and once those are down I can revisit the virtio-vhost-user backend situation. [1]: https://github.com/ndragazis/dpdk-next-virtio/blob/2d60e63/drivers/virtio_v… [2]: https://www.openvswitch.org/ crosvm ------ I started integrating the vhost-user-net code from Cloud Hypervisor into crosvm. I'm at the point where I can get all the copied Cloud Hypervisor code to compile in crosvm, which is pretty good! I have not yet written the code to actually start one of these devices yet, though, so I haven't been able to test it yet. It's been interesting to look at Cloud Hypervisor because it's a codebase that is heavily based on crosvm (even more so than Firecracker is), but that has also evolved and diverged from it. It's especially interesting to see stuff where parallel evolution occurred between the crosvm and Cloud Hypervisor codebases, or when Cloud Hypervisor changed how some crosvm code worked, and then later changed it back again. The codebases were still similar enough that I could have the cloud-hypervisor device integrated into the crosvm codebase in a day, although there's lots of code duplication that will have to be dealt with -- I copied over a bunch of supporting code rather than trying to integrate it into the crosvm equivalents to get the code running for the first time in an environment as similar as possible to the one it was designed for. I expect that when I test the device in crosvm it'll probably work fairly quickly if not first try. The more complicated part will be a bit of a change to how crosvm does guest memory that isn't strictly necessary but is important for security. crosvm allocates all guest memory in a single memfd. This means that, to share guest memory with another process, like when using vhost-user, the only option is to share all of guest memory. This would sort of defeat the purpose of hardware isolation in Spectrum! But from what I could tell -- I'm not 100% on this -- the guest memory abstraction in cloud-hypervisor is more advanced, and I think it might support multiple memfds backing guest memory for this sort of thing. I'll have to adapt crosvm to that model to be able to use vhost-user securely. website ------- The new "Bibliography" page is up[3]! Lots of links to relevant resources about concepts important to Spectrum. :) [3]: https://spectrum-os.org/bibliography.html It's a bit of a relief to have returned from the uncertain world of DPDK to the familiar territory of crosvm. I'm confident that the next bit of work here (vhost-user in crosvm) won't be that much of a big deal. Hopefully, we'll have at interim networking to a reasonable degree fairly soon. After that, I plan to look at file sharing, possibly with vhost-user-fs (virtio-fs over vhost-user), which I noticed cloud-hypervisor implements today. That should be pretty similar to the networking stuff, although I don't think any virtio-fs virtio-vhost-user code exists at the moment.

1 0

This Week in Spectrum, 2020-W30
by Alyssa Ross 27 Jul '20

27 Jul '20

Feels like there's a pretty clear path forward. Nice feeling. :) QEMU ---- Last week, as I wrote TWiS, I had just discovered virtio-vhost-user, which looked like a very promising mechanism for getting a VM to take care of networking for other VMs. This week, I've been researching it further, and trying to test and evaluate it. The first thing I tried to do, naturally, was to build the patched QEMU tree and boot a VM with a virtio-vhost-user device attached. This was not as easy as I'd hoped, because adding the virtio-vhost-user device to my QEMU command line made the VM kernel panic at boot, with an error message about an invalid memory access. I spent most of the week trying to figure this out -- I wasn't doing anything different to the example[1] on the QEMU wiki, so it should have worked, and it felt like if I could just get past whatever was going wrong here, it would be worth it, because virtio-vhost-user otherwise seems so suited for what we need here. I emailed the patch author[2], but he didn't know what was up either. An early breakthrough came when I got frustrated with kernel builds taking hours on my 8-year-old laptop, and so decided to work on a more powerful computer instead. Once I got everything set up on that computer, I started up the VM, and it worked. Perhaps in setting it up over here I'd done something different? I copied over the exact VM disk/kernel/initrd/command line that I was running on my laptop, and the other computer booted it just fine. I had -cpu host in the QEMU command line, so I thought maybe the different kind of virtual CPU was causing it. Tried setting it to a specific value on both machines, and still the laptop VM panicked and the other didn't. So it sounded like whether it worked or not depended on the host hardware. I put together a Nix derivation that would automatically build the custom QEMU and output a script that would run a VM, and then asked people in #spectrum to test it out on various computers. After getting some further data, a pattern started to emerge, where Intel processors Ivy Bridge and older would fail, and Skylake and newer would succeed (I didn't encounter any AMD processors that failed, nor did I have data at the time for generations between Ivy Bridge and Skylake). This theory had a convenient explanation for why nobody else had seen this problem -- I doubt people at Red Hat are working on 7-year-old hardware. This was a good clue, but still didn't put me much closer to having a working system. I do have a more recent laptop around, but for reasons that are out of scope here it would be very inconvenient to decide to just move over to it. I could see that the kernel was panicking the first time it tried to access the PCI BARs of the virtio-vhost-user, which led me to believe that the problem was probably in how that memory was being set up. I found the function that did that[3], and stared at it for a long time. I tried to read the rest of the QEMU code, but it became clear that my domain knowledge here isn't good enough to be able to keep track of what's meant to be happening. I added some debug prints, which were vaguely helpful in making that understanding a little better. I was hoping to find the guest address each PCI BAR was mapped to so that I could check the kernel was trying to write to the right location, but didn't manage to do that. While attempting to, though, I did add a debug print that printed the size of each PCI bar as it was allocated. I noticed that most were small -- 16 MiB at most, but one was huge, at 64 GiB! The code that allocated this BAR was part of the function I'd been staring at. As far as I could tell, the choice of size was pretty arbitrary -- this big memory region was used as backing memory for all sorts of small objects on the fly. On a whim, I tried changing the BAR size from 1ULL << 36 to 1ULL << 26, and recompiled QEMU. The VM booted. The comment above the bar_size definition that I'd been looking at for so long said: /* TODO If the BAR is too large the guest won't have address space to map * it! */ I don't know if that's exactly what went wrong here, though. I suspect it's more like the host architecture doesn't have enough address space? The affected machines all reported 36 bit physical address size, and 48 bit virtual address size. So maybe what's happening is that the processor interprets PCI addresses in the hardware-assisted VM as physical addresses, and therefore runs out of space because all of it is taken up by this one PCI bar? I'm not really sure. Lowering the bar size to 2^35 or 2^34 (has to be a power of two) depending on the QEMU version made the problem go away, and that's good enough for now. I'm not very enthusiastic about this up-front allocation of a huge amount of memory that might not even fit in the available address space. I don't know if there's a better way of doing it in this case, but I certainly hope so. In general I think this perhaps demonstrates why this code is not considered suitable for "production" yet. The bet I'm taking here is that by the time Spectrum is further along, things will have moved on for virtio-vhost-user too. As I said, at some point we will want to implement it in crosvm to avoid having QEMU in the TCB, but it would be a bad idea to do that now while virtio-vhost-user is still going through the back-and-forth of making its way into the Virtio spec. [1]: https://wiki.qemu.org/Features/VirtioVhostUser [2]: https://lore.kernel.org/qemu-devel/87h7u1s5k1.fsf@alyssa.is/T/#u [3]: https://github.com/ndragazis/qemu/blob/f9ab08c0c8/hw/virtio/virtio-vhost-us… DPDK ---- Once I was able to boot a VM with the virtio-vhost-user device, I tried to connect another QEMU VM to it through vhost-user -- I'll want to have this working first as a reference before I start porting Cloud Hypervisor's vhost-user implementation to crosvm. But the "frontend" (vhost-user) QEMU process hung waiting for a reply on the vhost-user socket from the backend one. Not really knowing what to do about this, I decided that maybe I'd been a bit too ambitious in going straight for vhost-user <-> virtio-vhost-user when I'd never actually used vhost-user before, so maybe I should try a more conventional vhost-user setup first. As far as I can tell, vhost-user is usually used for connecting a VM to a userspace networking stack. And usually, this networking stack is DPDK, the "Data Plane Development Kit"[4]. DPDK was also used in the virtio-vhost-user examples, so I figured my next step would be to try it there as well, and therefore it was worth the time in learning how to do a very basic setup with it. Quick start -style documentation for this was pretty lacking, but I did eventually manage to make this work. Here's what I did, for my own future reference as much as anything else: (1) Make some hugepages available. 1GiB for DPDK and 1GiB for QEMU: echo 1024 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages (2) Take my ethernet interface offline so it could be used with DPDK: nmcli d disconnect enp0s25 (3) Load the vfio-pci module, which allows PCI devices to be exported to userspace rather than managed by the kernel: mobprobe vfio-pci (4) Export the ethernet interface: usertools/dpdk-devbind.py -b vfio-pci enp0s25 (5) Run testpmd, a program that comes with DPDK mostly used for debugging and tracing it seems, but that with no special arguments acts as a simple packet forwarder. Here I create a vhost-user socket, and forward traffic between vhost-user and my ethernet interface: build/app/dpdk-testpmd -l 0,1 -w 00:19.0 \ --vdev net_vhost0,iface=/run/vhost-user0.sock The -w value is the PCI address of the ethernet interface. Note how "00:19" corresponds to "p0s25". (19 in hex is 25 is decimal.) (6) Start a VM. The relevant QEMU flags appear to be: -chardev socket,id=char0,path=/run/vhost-user0.sock \ -netdev type=vhost-user,id=net0,chardev=char0,vhostforce \ -device virtio-net-pci,netdev=net0 \ -object memory-backend-file,id=mem0,size=1024M,mem-path=/dev/hugepages,share=on \ -numa node,memdev=mem0 \ -mem-prealloc I figured this all out mostly from a guide for a DPDK benchmark[5]. I have not yet experimented with variations on the QEMU flags yet. I'm not sure if all the memory flags are required -- -mem-prealloc might just be there because it was important for a benchmark, for example. So this is the point I'm at with this exploration. Next up, I'll be trying with DPDK inside a VM with a virtio-vhost-user device. I think that maybe, despite the virtio-vhost-user device showing up as an ethernet device inside the VM, it needs some special support which is available for DPDK as a patchset, but that has not been written for the kernel yet. I was a bit worried about this, because unlike the kernel, DPDK isn't going to have things that Wi-Fi drivers for all sorts of different hardware, and so using DPDK instead of the kernel network stack would be a problem. But then I learned that DPDK has a component called the Kernel Native Interface (KNI) which allows it to use network interfaces from the kernel, so a hybrid approach would be possible, and is what I think we'll end up using for now. Then, once virtio-vhost-user is a bit more mature, a kernel driver will probably show up, and we can use that instead and drop DPDK. [4]: https://dpdk.org/ [5]: https://doc.dpdk.org/guides/howto/pvp_reference_benchmark.html?highlight=pvp Website ------- I was having a conversation about Spectrum yesterday, and I found myself sending over a bunch of links to articles and papers that I often find myself referring to when talking to somebody about Spectrum. This made me think that maybe there should be some place where we keep all these relevant articles. So I mined the IRC logs, the TWiS archive, and my blog, and added whatever I could pull from my brain, and wrote a Spectrum bibliography, containing 27 links to interesting articles and papers that are particularly relevant to Spectrum. This isn't on the website quite yet, but I did sent this as a patch[6] to the mailing list, if you want an early look. I also posted a patch to fix a minor issue where I'd mistakenly used ".." instead of "." as href values, to no user-visible effect[7]. [6]: https://spectrum-os.org/lists/archives/spectrum-devel/20200726045701.32259-… [7]: https://spectrum-os.org/lists/archives/spectrum-devel/20200726055410.20641-… Documentation ------------- On Monday, I had a call with the Free Software Foundation Europe. They're a part of NGI Zero (where my funding comes from), and they are promoting their new "REUSE" specification[8] for license information in free software projects to NGI Zero projects. It basically covers standardised per-file license and copyright annotations, and a standard way of including license texts. I think this is really cool! It's something I've been unsure of how to handle because it's all vague conventions that are different in different circles, and it's nice to see something formalised about it. They also have an automated tool[9] for checking compliance and semi-automatically adding license information, which is great! So I'm enthusiastically adopting the REUSE specification. I decided that our smaller, first-party repositories (the documentation, the website, etc.) would be a good place to get started, and so I posted a patch[10] that makes the documentation repository REUSE-compliant. [8]: https://reuse.software/ [9]: https://git.fsfe.org/reuse/tool [10]: https://spectrum-os.org/lists/archives/spectrum-devel/20200726105527.27432-… mktuntap -------- I posted a patch[11] to make mktuntap REUSE-compliant. [11]: https://spectrum-os.org/lists/archives/spectrum-devel/20200726110123.30159-… The thing that's most on my mind this week is the extent to which I'm learning about and working on software like QEMU and DPDK that I don't see having a place in Spectrum in the long run. It's counterintuitive, but this is definitely worth it. There's no point writing a kernel driver for virtio-vhost-user (should such a thing be required) right now, because if I use DPDK for now instead, at some point either virtio-vhost-user will end up not being the thing that gets adopted by the ecosystem and we'll have to move to something else, or (more likely) it gets widely adopted and somebody else writes a kernel driver. Similarly, using QEMU for network VMs is the smart choice even though I don't want it to end up in the TCB, because even though I'm probably going to end up implementing virtio-vhost-user in crosvm later, swapping out QEMU is going to be so easy later that it would be a very bad idea to implement that now in case virtio-vhost-user doesn't take off. But it still /feels/ weird to be using QEMU for this stuff, you know?

1 0